微服务的一些基本概念

目录

• 1 概述
• • 1.1 微服务架构的特征
  • 1.2 微服务架构示例
• 2 微服务与单体式架构
• • 2.1 什么是单体式架构？
  • 2.2 单体式架构的优点
  • 2.3 单体式架构的缺点
• 3 什么是微服务？
• • 3.1 微服务的优点
  • 3.2 微服务的缺点
• 4 如何构建微服务
• • 4.1 从单体式开始
  • 4.2 以正确的方式组织团队
  • 4.3 拆分单体式结构，构建微服务架构
• 5 什么是分布式系统
• • 5.1 分布式计算系统的特点
  • 5.2 集中式系统与分布式系统有何区别？
  • 5.3 分布式系统是否与微服务相同？
  • 5.4 什么是分布式跟踪？
  • 5.5 分布式系统的优缺点和风险
  • 5.6 分布式系统的架构
  • • 5.6.1 客户端-服务器
    • 5.6.2 多层
    • 5.6.3 点对点
    • 5.6.4 面向服务的体系结构
    • 5.6.5 分布式系统用例
• 6 SOA 与微服务
• • 6.1 面向服务的体系结构 (SOA)
  • 6.2 微服务架构
  • 6.3 SOA 和微服务之间的区别

从https://www.atlassian.com/zh/microservices/microservices-architecture转载。

1 概述

在当今世界，应用现代化通常意味着迁移到以微服务形式构建的云原生应用。然后使用 Docker 和 Kubernetes 等容器技术进行部署。究其原因，微服务架构可以提高可扩展性、加快开发速度和服务迭代。微服务架构将应用拆分为一系列可独立部署的服务，并通过 API 进行通信。这样，每个服务都可单独部署和扩展。这种方法允许快速、频繁地交付庞大且复杂的应用。与单体式应用不同，微服务架构允许团队更快地实施新功能并进行更改，并且大部分现有代码均无需重写。

1.1 微服务架构的特征

• 1. 多个组件服务 。微服务由单独的、松散耦合的组件服务构成，这些服务均可单独开发、部署、运营、更改和重新部署，而不影响其他服务的功能或应用的完整性。如此一来，便可快速、轻松地部署应用的各项功能。
• 2. 高度可维护性和可测试性。借助微服务，团队可试验新的功能，并在出现状况时回滚。这样，代码更新变得更加轻松，新功能的面市时间也得以加快。此外，隔离和修复单个服务中错误和漏洞的过程也得以简化。
• 3. 由小型团队负责。小型独立团队通常会在微服务内构建服务，鼓励敏捷实践和 DevOps。团队可以独立工作和快速行动，从而缩短开发周期。
• 4. 根据业务能力进行组织。微服务方法根据业务能力来组织服务。各个团队均为跨职能团队，且具备开发所需的全部技能，从而努力实现某一职能。
• 5. 自动化基础架构。构建和维护微服务的团队通常使用基础架构自动化实践，例如持续集成 (CI)、持续交付 (CD) 和持续部署（也简称为 CD）。这样，团队便可独立构建和部署每项服务，而不影响其他团队。它还允许团队将新版本的服务与先前的版本并行部署。

1.2 微服务架构示例

举例来说，有一个电子商务软件项目，所述电子商务站点包含与多个微服务交互的 Web 应用和移动应用，且每项微服务都为一个领域提供特定的功能。现代 Web 应用在浏览器中运行，且通常由内容分发网络 (CDN) 提供。CDN 的优势在于可将 Web 应用分发到世界各地的服务器，让 Web 浏览器提供快速下载。CDN 还用于提供图像、音频和视频等媒体资产。例如，在此系统中，在售商品的图像和视频由 CDN 提供。这个项目中的微服务包括：

• 1. 帐户服务。帐户服务提供与顾客帐户相关的信息，例如地址和付款信息。
• 2. 库存服务。提供最新库存信息，方便顾客购买商品。
• 3. 购物车服务 。顾客使用该服务从库存中挑选他们想购买的商品。
• 4. 付款服务。顾客为购物车中的商品付款。
• 5. 配送服务。此服务负责安排所购商品的包装与发货。

应用通过各个微服务发布的 REST API 与微服务进行交互。API 网关允许应用依赖微服务所提供的 API，也允许将这些微服务交换为使用相同 API 的其他微服务。
每项微服务均由服务和数据库构成。这些服务负责处理 REST API、实现业务逻辑，并将数据存储在数据库中。对于微服务，可按照 12 Factor App 协定将它们的资源（如数据库和队列）彼此分离。

2 微服务与单体式架构

单体式应用是作为单个统一单元来构建的，而微服务架构是规模较小且可独立部署的服务集合。

2.1 什么是单体式架构？

单体式架构是一种传统的软件程序模型，它作为独立自主且不依靠其他应用的统一单元来构建。“单体”一词通常被认为源于冰川这种庞然大物，而这与软件设计中单体式架构的本质也颇为接近。单体式架构是一种单一大型计算网络，它具有一个可将所有业务问题耦合在一起的代码库。要对此类应用进行更改，需要访问代码库并构建和部署服务端接口的更新版本来更新整个堆栈。如此一来，更新便会受限，且较为耗时。
在项目的早期阶段，单体式架构在代码管理、认知开销和部署等方面非常便利。单体式架构中的所有内容均可一次性全部发布。

2.2 单体式架构的优点

组织可以从单体式架构或微服务架构中受益，具体取决于多个因素。采用单体式架构进行开发，其主要优点是开发速度快，因为应用是基于一个代码库，比较简便。单体式架构的优点包括：

• 1. 易于部署。只有一个可执行文件或目录，部署更加简便。
• 2. 开发。使用一个代码库构建应用时，开发难度较低。
• 3. 性能。在集中式代码库和存储库中，一个 API 通常可以执行微服务架构中由多个 API 执行的相同功能。
• 4. 测试简单。由于单体式应用是一个集中式单元，因此端对端测试的执行速度比分布式应用的测试速度更快。
• 5. 调试轻松 。所有代码均存放于一处，因而可以更轻松地跟踪请求并查找问题。

2.3 单体式架构的缺点

单体式应用可能会非常有效，直至它们变得过于庞大并且难以扩展。单一功能中的细微更改也需要编译和测试整个平台，这与当今开发人员热衷的敏捷方法背道而驰。单体式架构的缺点包括：

• 1. 开发速度较慢。庞大的单体式应用会使开发复杂度上升、速度减慢。
• 2. 可扩展性。您无法扩展个别组件。
• 3. 可靠性。如有任何模块出现错误，整个应用的可用性就可能会受到影响。
• 4. 阻碍技术采用 。框架或语言的任何变动都会影响整个应用，从而使更改常常变得既昂贵又耗时。
• 5. 缺乏灵活性。 单体受到其本身已用技术的局限。
• 6. 部署。对单体式应用的细微更改需要重新部署整个整体架构。

3 什么是微服务？

微服务架构（也可简称为微服务）是一种依赖于一系列可独立部署服务的架构方法。这些服务有自己的业务逻辑和数据库，并负责实现特定的目标。更新、测试、部署和扩展都在每一项服务中进行。微服务可将特定于领域的主要业务问题分解为单独的独立代码库。微服务不会降低复杂性，但它们可将任务划分成彼此独立运行且对整体有益的较小流程，从而使任何复杂情况都变得一目了然且更易管理。
微服务通常与 DevOps 并驾齐驱，因为它们是持续交付实践的基础，可让团队快速适应用户需求。

3.1 微服务的优点

微服务架构由独立运行的单元构成，因此可在不影响其他服务的前提下开发、更新、部署和扩展各项服务。软件更新可以更为频繁，从而提升可靠性、正常运行时间和性能。微服务的优点包括：

• 1. 敏捷。提倡通过小型团队进行敏捷开发，频繁地进行部署。
• 2. 灵活扩展 。如果某一微服务达到负载容限，可将该服务的新实例快速部署到相关集群，以帮助缓解压力。可采用多租户和无状态结构，让客户分散在多个实例上，而且也能支持规模大得多的实例。
• 3. 持续部署。可实现频繁且更快的发布周期。
• 4. 高可维护性和可测试性 。可以试验新的功能，并在出现状况时回滚。这样，代码更新变得更加轻松，新功能的面市时间也得以加快。此外，还可以轻松隔离和修复各项服务中的错误和漏洞。
• 5. 独立部署。由于微服务是单独的单元，因此能够快速、轻松地独立部署各个功能。
• 6. 技术灵活 。微服务架构允许团队*选择所需的工具。
• 7. 高度可靠。可以为特定服务部署更改，而不必担心要关闭整个应用。

3.2 微服务的缺点

从少量单体式代码库转变为更多分布式系统和服务为微服务后，出现了意想不到的复杂性。微服务可能会使复杂性上升，从而导致开发蔓延或增长加快且无法管理。确定不同组件之间的关系、特定软件组件的负责人，或者如何避免干扰依赖组件，这些都可能非常棘手。微服务的缺点可能包括：

• 1. 开发蔓延。与单体式架构相比，微服务会导致复杂性上升，因为多个团队会在更多地方创建更多服务。开发蔓延若管理不当，则会导致开发速度减慢和运营绩效降低。
• 2. 基础架构成本呈指数级增长。每项新的微服务都有自己的成本，例如在测试套件、部署手册、托管基础架构和监控工具等方面。
• 3. 组织开销增多。团队需要额外的通信和协作来协调更新和交互。
• 4. 调试挑战。每个微服务都有自己的一组日志，从而使调试变得更加复杂。此外，单个业务流程可能会在多个计算机上运行，从而进一步加大调试复杂度。
• 5. 欠缺标准化。若无一个通用平台，语言、日志记录标准和监控手段便可能会激增。
• 6. 缺少明确责任。当推出的服务增多后，运行这些服务的团队数量也会增加。随着时间推移，便难以清晰掌握团队有哪些服务可供使用，以及与谁联系来获得支持。
     

4 如何构建微服务

假设应用是基于一种代码构建的大型单体式应用。该应用一直运行良好，直到后来出现问题。您希望能改进该应用，提高应用弹性、可扩展性并实现独立部署。为此，需要在微服务的粒度级别上重新考虑该应用的结构。
随着应用的分散程度和复杂性不断加剧，微服务也越来越受欢迎。微服务的指导原则是：通过将应用的业务组件拆分为可相互独立部署和运行的小型服务来构建应用。服务之间关注点的分离被定义为“服务边界”。
服务边界与业务需求以及组织层次结构边界紧密相关。个别服务可能与独立的团队、预算和路线图相关联。部分示例服务边界可能包括“支付处理”和“用户身份验证”服务。微服务不同于传统的软件开发实践。在传统软件开发实践中，所有组件都捆绑在一起。
这里引用一家名为“Pizzup”的虚构披萨初创公司来说明微服务在现代软件企业中的应用。

4.1 从单体式开始

微服务的第一个最佳实践是：可能不需要这些服务。如果应用没有任何用户，那么在构建 MVP 时，业务需求可能会迅速发生变化。这仅仅是由于软件开发的性质以及在确定系统需要提供的关键业务功能时需要依据的反馈周期。微服务会使开销和管理复杂性呈现指数级增长。因此，对于新项目而言，将所有代码和逻辑保存在一个代码库中的开销要小得多，因为这样可以更轻松地移动应用中不同模块的边界。
例如在 Pizzup，将从一个待解决的简单问题开始：希望客户能够在线订购披萨。

当开始思考订购披萨的问题时，会确定在应用中要实现该需求所需的不同功能。需要管理可制作的不同披萨的清单，允许顾客挑选一个或多个披萨，办理支付，安排配送时间等。可能会决定让客户创建一个帐户，以便在下次使用 Pizzup 时再次下单。在与第一批用户沟通之后，可能会意识到，实时跟踪配送和移动支持可让我们占据竞争优势。

最初的简单需求很快就变成了一系列新功能。
如果对系统所需的不同服务有了深入了解，微服务就能很好地发挥作用。但是，如果没有明确定义应用的核心需求，微服务则很难发挥作用。在微服务中重新定义服务交互、API 和数据结构的成本相当高，因为这通常需要协调更多的灵活因素。这里建议是，收集到足够的用户反馈且有足够的信心掌握客户的基本需求并为之进行规划之前，请务必让一切都保持简单。
需要注意的是：单体式构建可能会导致代码复杂性立马加剧，难以分解成更小的部分。因此，最好能确定清晰的模块，以便后续可将这些模块从整体中提取出来。您也可以一开始就将逻辑与 Web UI 分离，并确保逻辑通过 HTTP 上的 RESTful API 与后端进行交互。这样，当 API 资源移动至其他服务时，便可更轻松地过渡到微服务。

4.2 以正确的方式组织团队

到目前为止，构建微服务似乎主要是一项技术工作。需要将代码库拆分为多个服务，实现正确的模式以允许优雅降级，并从网络问题中恢复，处理数据一致性，监控服务负载等。这其中涉及许多需要掌握的新概念。但最重要且不容忽视的一点是，需要重构团队的组织方式。
康威定律是真实存在的，并且适用于所有类型的团队。如果一个软件团队由一个后端团队、一个前端团队和一个独立工作的运营团队组成，这个软件团队将提供独立的前端和后端单体，而这些单体会被扔给运营团队随后投入生产。此类团队结构并不适合微服务，因为每项服务都应被视为自己的产品，需要独立于其他服务进行交付。
相反，应该创建规模较小的 DevOps 团队，这些团队具备所有开发和维护的能力以满足他们所负责的服务。以此方式组织您的团队大有益处。首先，开发人员可以更好地理解他们的代码在生产中所产生的影响，这有助于他们开发出更好的版本，并降低客户发现问题的风险。其次，部署成为每个团队的第二天性，因为他们会共同改进代码，并实现部署管道的自动化。

4.3 拆分单体式结构，构建微服务架构

• 1. 使用 RESTful API 简化服务之间的通信 。微服务架构力求使操作尽可能简单，从而避免组件的紧密耦合。在某些情况下，可能正在使用事件驱动的架构，而该架构是基于异步消息的通信。但是，可以再次研究 RabbitMQ 一类的基本消息队列服务，并避免增加通过网络传输的消息的复杂性。
• 2. 将数据划分为带边界的上下文或数据域 。单体式应用使用单个数据库来存储该应用的所有业务功能。由于单体被分解为微服务，该单一数据库可能不再具有意义。*数据库可能会成为流量扩展的瓶颈。如果某一特定服务在高负载下访问数据库，则可能会中断其他服务对数据库的访问。此外，如果有多个团队试图同时修改该架构，单个数据库可能会成为这些团队开展协作的瓶颈。这可能需要拆分数据库或添加其他数据存储工具来支持微服务数据需求。
• 3. 构建微服务架构以应对故障 。微服务体积更小，专业程度高，这使它们更易于理解。微服务处于解耦状态，这意味着您可以重构服务，而不必担心破坏系统的其他组件或妨碍其他团队的开发速度。微服务还为开发人员提供了更大的灵活性，因为他们可以在需要时选择不同的技术，而不会受到其他服务需求的限制。
• 4. 重视监控以简化微服务测试。与单体式系统相比，微服务的另一个缺点是测试。作为单个代码库所构建的应用不需要太多就能让一个测试环境启动并运行。大多数情况下，需要启动后端服务器以及配套数据库以运行测试套件。
• 5. 采用持续交付，减少部署摩擦。手动将单体式系统发布到生产环境是一项繁琐且冒险的工作，虽然也可以实现。不建议使用这种方法，而是鼓励每个软件团队都采用持续交付来进行所有类型的开发。但在项目开始时，可能需要通过命令行自行进行首次部署。

5 什么是分布式系统

分布式系统是计算机程序的集合，这些程序利用跨多个独立计算节点的计算资源来实现共同的目标。分布式系统旨在消除系统的瓶颈或中心故障点。应用构建成一个可部署的单元，尽管运行良好，但规模和复杂性随着时间推移会加剧，这会导致什么情况？它往往会变得更难维护，而且开发速度会变慢，故障风险也会上升。在此情况下，进化之路是让整体架构演变为分布式系统，通常则是采用微服务架构。

5.1 分布式计算系统的特点

分布式系统是计算机程序的集合，这些程序利用跨多个独立计算节点的计算资源来实现共同的目标。它也被称为分布式计算或分布式数据库，并依靠不同的节点通过公共网络进行通信和同步。这些节点通常代表独立的物理硬件设备，但也可代表单独的软件进程或其他递归封装的系统。分布式系统旨在消除系统的瓶颈或中心故障点。分布式计算系统具有如下特点：

• 1. 资源共享。分布式系统可以共享硬件、软件或数据
• 2. 并行处理。多台机器可以同时处理同一功能
• 3. 支持扩展。当扩充到其他计算机时，计算和处理能力可以按需进行扩展
• 4. 错误检测。可以更轻松地检测故障
• 5. 公开透明。节点可以访问系统中的其他节点并与之通信

5.2 集中式系统与分布式系统有何区别？

所谓集中式计算系统，是指所有计算都由位于同一位置的单台计算机来执行。集中式和分布式系统的主要区别在于系统节点之间的通信模式。集中式系统的状态控制在*节点内，客户端以定制方式访问此节点。集中式系统的各个节点都要访问此*节点，因此可能会导致网络拥塞和速度缓慢。集中式系统存在单点故障，而分布式系统则没有单点故障。

5.3 分布式系统是否与微服务相同？

微服务架构是一种分布式系统，因为它会将应用分解为单独的组件或“服务”。例如，微服务架构可能具有与业务功能（支付、用户、产品等）相对应的服务，其中各个对应组件负责相关职责的业务逻辑。因此，系统拥有服务的多个冗余副本，服务便不会出现集中故障点。

5.4 什么是分布式跟踪？

分布式跟踪是一种用于分析或监控分布式系统中执行的请求结果的方法。监控分布式系统可能颇具挑战性，因为每个节点各自有一组独立的日志和指标。要准确观察分布式系统，需要将这些单独的节点指标汇总到一个整体视图中。
对分布式系统的请求通常不会访问系统内的完整节点集，而是访问一部分节点或节点的一条路径。分布式跟踪可以明确分布式系统中经常访问的路径，并允许团队分析和监控这些路径。分布式跟踪安装在系统的各个节点中，之后团队便可通过查询系统来获取有关节点运行状况和请求性能的信息。

5.5 分布式系统的优缺点和风险

分布式系统通常有助于提升系统的可靠性和性能。消除中心故障点和瓶颈，从而提高可靠性。分布式系统的节点提供冗余能力，如有任何节点出现故障，其他节点会准备好接管和替换故障节点。由于节点能够轻松地进行水平和垂直扩展，因此性能可以得到提升。如果系统的负载过大，可以添加额外节点来帮助消化负载。也可以通过提高单个节点的容量来应对大量负载。
但是，对这些好处做出权衡取舍可能导致“开发蔓延”，系统会变得过于复杂，维护也将更具挑战性。随着系统越来越复杂，团队可能难以有效地组织、管理和改进这些系统。其中的部分原因可能在于：需要了解不同组件之间的关系，或者由谁来负责特定的软件组件。这样一来，便很难搞清如何对组件进行更改，最大限度改善运行状况并避免对依赖组件和客户造成负面影响。

5.6 分布式系统的架构

分布式系统有众多类型。以下是最常见的几种：

5.6.1 客户端-服务器

客户端-服务器架构将主要职责一分为二。客户端负责用户界面呈现，并通过网络与服务器连接。服务器则负责处理业务逻辑和状态管理。如果服务器没有冗余功能，客户端-服务器架构很容易退化为集中式架构。在真正的分布式客户端-服务器设置中，有多个服务器节点来分散客户端连接。大多数现代客户端-服务器架构都是多个客户端连接到服务器上封装的分布式系统。

5.6.2 多层

多层架构在客户端-服务器架构的基础上进行了扩展。多层架构中的服务器进一步分解为更细化的节点，以便将数据处理和数据管理等其他后端服务器职责分离出来。这些额外节点被用于异步处理长时间运行的作业，并释放其余的后端节点，使其专注于响应客户端请求并与数据存储交互。

5.6.3 点对点

在点对点分布式系统中，每个节点都包含应用的完整实例。界面呈现与数据处理不存在节点分离。节点包含呈现层和数据处理层。对等节点可能包含整个系统的全部状态数据。
点对点系统具有极高的冗余能力。当点对点节点初始化并联机时，它会发现并连接其他对等节点，并将其本地状态与更大系统的状态同步。此特性意味着，点对点系统中一个节点发生故障不会导致任何其他节点中断。这也表示点对点系统将持续存在。

5.6.4 面向服务的体系结构

面向服务的体系结构 (SOA) 是微服务的前身。SOA 与微服务的主要区别在于节点作用域，即微服务节点在功能层面上存在的范围。在微服务中，一个节点封装被用来处理特定功能集的业务逻辑，例如支付处理。微服务包含多个迥然不同的业务逻辑节点，这些节点会与独立的数据库节点进行交互。相比之下，SOA 节点会封装整个应用或企业部门。SOA 节点的服务边界通常包括节点内的整个数据库系统。
鉴于其优势，微服务已成为 SOA 的一种更受欢迎的替代方案。微服务更具组合性，团队可以重复利用小型服务节点提供的功能。微服务更加稳健，可实现更灵活的的垂直和水平扩展。

5.6.5 分布式系统用例

许多现代应用都采用分布式系统。高流量 Web 和移动应用属于分布式系统。用户以客户端-服务器的方式进行连接。其中，客户端为 Web 浏览器或移动应用，服务器则是其自身的分布式系统。现代 Web 服务器遵循一种多层系统模式。使用负载平衡器将请求委派给众多服务器逻辑节点，这些界节点通过消息队列系统进行通信。
Kubernetes 是分布式系统的常用工具，因为它可通过一组容器来创建分布式系统。容器生成分布式系统的节点，然后 Kubernetes 会编排各节点之间的网络通信，并处理系统中节点的动态水平扩展和垂直扩展。
分布式系统的另一个例子是比特币和以太坊等加密货币，它们都是点对点分布式系统。加密货币网络中的每个节点都是货币账本完整记录的独立副本。当货币节点上线时，它会通过连接其他节点并下载账本的完整副本来进行引导。此外，加密货币具有客户端或“钱包”，它们通过 JSON RPC 协议连接到账本节点。

6 SOA 与微服务

软件应用选择正确的体系结构至关重要。有两种比较著名的模型，即面向服务的体系结构 (SOA) 和微服务体系结构，它们是开发人员社区中最常用的模型。这两种体系结构有一个共同的目标，即创建模块化和灵活的软件。但是，它们在方法和结构上有所不同。

6.1 面向服务的体系结构 (SOA)

SOA 倡导松散耦合的独立服务，彻底改变了软件设计。这意味着，服务彼此之间的依赖性最小，因此更易于开发、部署和维护。
服务也可以在许多应用中重复使用。这些服务通过标准化协议进行通信，从而实现不同系统之间的顺利集成和互操作性。SOA 非常适合大型的复杂企业。
SOA 的模块化和标准化协议使服务能够有效通信，从而提高可重用性、互操作性和可扩展性。这些关键优势可以转化为切实优势：

• 1. 可重用性：重复使用现有服务可以减少开发时间和降低开发成本，并提高一致性和质量。公司可以加快开发周期并提高整体效率。
• 2. 互操作性：服务可以通信和交换数据，无论采用何种底层技术或编程语言。这促进了企业范围内的数据集成和协作。互操作性可以简化业务流程，帮助公司适应不断变化的技术。
• 3. 可扩展性：SOA 的模块化设计允许根据不断变化的需求独立扩展服务。它可确保应用能够在不影响性能或稳定性的情况下应对流量激增或不断扩大的用户群。公司可以使其基础架构适应不断变化的需求，而无需投入大量资金重新编写或重新设计。

6.2 微服务架构

微服务体系结构采用更精细的方法。它将应用分解为较小的独立服务。每项服务都是独立的，侧重于特定的任务或功能。每项微服务还包含所有必要的代码和数据，无需依赖其他组件即可运行。微服务通过 HTTP 和 REST 等轻量级协议进行通信，从而提高敏捷性和弹性。
微服务体系结构最显著的优势是可实现顺利集成和可重用性。这使其成为快速发展的动态应用的理想选择。
微服务的精细体系结构和轻量级通信协议可实现无缝集成和可重用性。这可以转化为几项主要优势：

• 1. 可扩展性：微服务是可扩展的。它们可以扩展或收缩以满足不断变化的需求。每项微服务负责特定的业务功能，并且可以独立于其他微服务进行扩展。Docker 和 Kubernetes 通过提供管理和编排微服务容器的工具和基础架构，在该可扩展性方面发挥至关重要的作用。
• 2. 灵活性：微服务的技术独立性使开发人员能够为每项服务选择最佳技术。微服务的松散耦合（这表明它们不依赖特定的技术或编程语言）使开发人员可以在不中断整个应用的情况下试用新技术。通过微服务，可以更轻松地采用新技术，因为只有受影响的微服务需要更新。
• 3. 故障隔离：微服务的松散耦合可限制故障的影响，防止故障级联到整个系统中。这是因为微服务是独立的单元，有自己的数据和代码。如果一项微服务失败，其他微服务可以继续正常运行。故障隔离有助于确保整个系统的稳定和可靠。

6.3 SOA 和微服务之间的区别

虽然 SOA 和微服务有一些共同的目标，但也有明显的区别。在比较 SOA 与微服务时，基本的体系结构风格可使这两种方法区分开来。SOA 采用自上而下的集中化方法，而微服务则更喜欢采用自下而上的去中心化模型。

功能	SOA	微服务
体系结构风格	粗粒度、集中化	细粒度的分布式系统；去中心化的数据管理
服务粒度	规模较大、更全面的服务	规模较小、有侧重点的服务
独立	服务是相互依存的；可以共享数据库进行数据存储	服务高度独立；解耦且自主
沟通	同步，通常以消息为导向；使用共享数据	异步，通常是 RESTful；避免数据共享
数据存储	集中化数据管理；服务共享数据库	分布式（去中心化）数据管理；每项服务负责自己的数据管理
可扩展性	水平扩展；由于资源共享和进行集中通信，因此扩展特定服务可能很复杂	水平和垂直扩展；随着服务独立运营，实现更精细和更集中的扩展
部署	通常涉及将整个应用作为一个单元进行部署	每项服务均独立部署和扩展；促进持续交付
耦合	由于资源共享和进行集中通信，因此服务呈现出一定程度的耦合	松散耦合，服务之间的依赖性最小