下载掌阅APP，畅读海量书库
立即打开
软件架构是指建立软件组件之间的结构、操作和交互的所有基本部分。本书解释了如何创建一个微服务架构，该架构由松耦合的软件服务组成，这些软件服务执行少量定义良好的任务，并通过网络使用消息进行通信。我们首先考虑一下微服务和其他一些常见架构之间的区别。
一种常见的企业架构类型是多层或 n 层架构。通过这种设计，应用程序被划分为多个层，每个层都有自己的职责和功能，如用户界面（UI）、服务、数据、测试等。例如，当你创建应用程序时，你先为UI创建一个特定的项目或解决方案，然后为服务创建一个项目或解决方案，再为数据层创建一个项目或解决方案，以此类推。最后，你将拥有几个项目，将这些项目组合起来，创建一个完整的应用程序。对于大型企业系统， n 层架构应用程序有许多优点，包括：
● n 层架构应用程序提供了良好的关注点分离，使得人们可以分别考虑用户界面、数据和业务逻辑等领域；
● 团队很容易在 n 层架构应用程序的不同组件上独立工作；
● 因为这是一个易于理解的企业架构，所以为 n 层架构项目找到熟练的开发人员相对容易。
n 层架构应用程序也有缺点，例如：
● 当你想要进行更改时，必须停止并重新启动整个应用程序；
● 消息往往在各层之间上下传递，这可能是低效的；
● 一旦部署，重构一个大型的 n 层架构应用程序可能会很困难。
虽然我们在本书中讨论的一些主题与 n 层架构应用程序直接相关，但我们将更直接地关注微服务与另一种常见架构（通常称为单体架构）的区别。
许多中小型基于Web的应用程序都是使用单体架构风格构建的。在单体架构中，应用程序作为单个可部署的软件制品交付。所有用户界面、业务和数据库访问逻辑都打包到一个唯一的应用程序中，并部署到应用程序服务器。图1-1显示了这个应用程序的基本架构。
虽然应用程序可能是作为单个工作单元部署的，但经常会有多个开发团队在一个应用程序上工作。每个开发团队负责应用程序的不同部分，并且他们经常用自己的功能部件来服务特定的客户。例如，想象一个场景，我们有一个内部定制的客户关系管理（CRM）应用，它涉及多个团队之间的合作，包括UI/UX团队、客户团队、数据仓库团队以及金融从业者等。
尽管微服务架构的支持者有时会否定单体应用程序，但单体应用程序通常是一个很好的选择。与 n 层或微服务等更复杂的架构相比，单体应用程序更容易构建/部署。如果用例定义良好并且不太可能改变，那么从单体应用程序开始可能是一个很好的决定。
然而，当应用程序的规模和复杂性开始增加时，单体应用程序可能会变得难以管理。对单体应用程序的每一个更改都可能对应用程序的其他部分产生级联效应，这可能会使应用程序变得耗时且代价高昂，特别是在生产系统中。我们有的第三个选择——微服务架构，提供了更大的灵活性和可维护性。
图1-1 单体应用程序强迫多个开发团队同步他们的交付日期，因为他们的代码需要被
作为一个整体单元进行构建、测试和部署
微服务的概念最初悄悄蔓延到软件开发社区中，是作为对尝试（在技术上和组织上）扩大大型单体应用程序所面临的诸多挑战的直接回应。 微服务 是一种小型的、松耦合的分布式服务。微服务允许你将一个大型的应用分解为具有狭义职责定义的便于管理的组件。微服务通过将一个大型代码库分解为多个精确定义的小型代码库，帮助解决了大型代码库中传统的复杂问题。
对微服务的思考需要围绕两个关键概念展开： 分解 （decomposing）和 分离 （unbundling）。应用程序的功能应该完全彼此独立。如果我们以前面提到的CRM应用程序为例，将其分解为微服务，那么它看起来可能像图1-2所示的样子。
图1-2 使用微服务架构，CRM应用将会被分解成一系列完全独立的微服务，
让每个开发团队都能够按各自的步伐前进
图1-2显示了每个团队是如何完全拥有自己的服务代码和服务基础设施的。他们可以彼此独立地去构建、部署和测试，因为他们的代码、源代码控制存储库和基础设施（应用服务器和数据库）现在是完全独立于应用的其他部分的。总的来说，微服务架构具有以下特征。
● 应用程序逻辑被分解为具有定义明确的、协调的职责边界的细粒度组件。
● 每个组件都有一个小的职责领域，并且完全独立部署。单个微服务对业务域的某一部分负责。
● 微服务采用HTTP这样的轻量级通信协议和JSON（JavaScript Object Notation，JavaScript对象表示法），在服务消费者和服务提供者之间进行数据交换。
● 服务的底层采用什么技术实现并没有什么影响，因为微服务应用程序始终使用技术中立的格式（JSON是最常见的）进行通信。这意味着使用微服务方法构建的应用程序能够使用多种编程语言和技术进行构建。
● 微服务利用其小、独立和分布式的性质，使组织拥有具有明确责任领域的更小型开发团队。这些团队可能为同一个目标工作，如交付一个应用程序，但是每个团队只负责他们在做的服务。
图1-3对比了一个典型的小型电子商务应用程序的单体设计和微服务设计。
图1-3 单体架构和微服务架构对比
习惯于为当地市场服务的公司突然发现，他们可以接触到全球的客户群，不过，更大的全球客户群也带来了全球竞争。更多的竞争影响了开发人员构建应用程序的方式。
● 复杂性上升。 客户期望一个组织的所有部门都知道他们是谁。与单个数据库通信并且不与其他应用程序集成的“孤立的”应用程序已不再是常态。如今，应用程序需要与多个服务和数据库进行通信，这些服务和数据不仅位于公司数据中心内，还位于外部互联网服务供应商内。
● 客户期待更快速的交付。 客户不想再等软件包的下一个年度版本了。相反，他们期望一个软件产品中的各个功能是分开的，以便新功能在几周（甚至几天）内即可快速发布。
● 客户还要求可靠的性能和可伸缩性。 全球性的应用程序使预测应用程序能处理多少事务以及何时会到达该事务量变得非常困难。应用程序需要跨多个服务器快速扩大，然后在事务量高峰过去之后无缝收缩。
● 客户期望他们的应用程序可用。 因为客户与竞争对手之间只有点击一下鼠标的距离，所以企业的应用程序必须具有高度的弹性。应用程序中某个部分的故障或问题不应该导致整个应用程序崩溃。
为了满足这些期望，作为应用开发人员，我们不得不接受这样一个不可思议的的东西：要构建高度可伸缩的高度冗余的应用程序，我们需要将应用程序分解成可以互相独立构建和部署的小型服务。如果将应用程序“分解”为较小的服务，并将它们从单体制品中转移出来，那么就可以构建具有下面这些特性的系统。
● 灵活性 ——可以将解耦的服务进行组合和重新安排，以快速交付新的功能。一个正在使用的代码单元越小，更改越不复杂，测试部署代码所需的时间越短。
● 有弹性 ——解耦的服务意味着应用程序不再是单个“泥浆球”，其中一部分应用程序的降级会导致整个应用程序失败。故障可以限制在应用程序的一小部分中，并在整个应用程序遇到中断之前被控制。这也使应用程序在出现不可恢复的错误的情况下能够优雅地降级。
● 可伸缩性 ——解耦的服务可以轻松地跨多个服务器进行水平分布，从而可以适当地对功能 / 服务进行伸缩。单体应用程序中的所有逻辑是交织在一起的，即使只有一小部分应用程序是瓶颈， 整个 应用程序也需要扩展。小型服务的扩展是局部的，成本效益更高。
为此，当我们开始讨论微服务时，请记住：
小型的、简单的、解耦的服务 = 可伸缩的、弹性的、灵活的应用程序
系统和组织本身可以从微服务方法中获益——理解这一点是很重要的。为了在组织中获益，我们可以反向应用 康威定律 （Conway’s law）。这个定律指出了几点可以改善公司内部沟通和结构的措施。
康威定律（由Melvin R. Conway在1968年4月的文章“How do Committees Invent”中首次提到）指出“设计系统的组织其产生的设计等价于组织间的沟通结构”。基本上，它所表明的是，团队内部以及与其他团队之间的沟通方式直接反映在他们生产的代码中。
如果我们反向应用康威定律，也称为 逆康威策略 （inverse Conway maneuver），并基于微服务架构设计公司结构，那么通过创建松耦合的自治团队来实现微服务，就能改善应用程序的通信、稳定性和组织结构。