微服务架构模式简介

上下文

您正在开发服务器端企业应用程序。它必须支持各种不同的客户端，包括桌面浏览器、移动浏览器和本地移动应用程序。应用程序还可能公开一个API供第三方使用。它还可以通过web服务或消息代理与其他应用程序集成。应用程序通过执行业务逻辑来处理请求（HTTP请求和消息）；访问数据库；与其他系统交换信息；返回HTML/JSON/XML响应。存在与应用程序的不同功能区域相对应的逻辑组件。

问题

应用程序的部署架构是什么？

Forces

有一个开发团队在开发这个应用程序

新的团队成员必须迅速变得富有成效

应用程序必须易于理解和修改

您希望练习应用程序的连续部署

为了满足可伸缩性和可用性要求，必须在多台计算机上运行应用程序的多个实例

你想利用新兴技术（框架、编程语言等）

解决方案

定义一个体系结构，将应用程序构造为一组松散耦合的协作服务。此方法对应于缩放立方体的Y轴。每项服务是：

• 高度可维护性和可测试性—支持快速、频繁的开发和部署
• 与其他服务松散耦合—使团队能够在其服务上独立工作大部分时间，而不受其他服务更改的影响，也不影响其他服务
• 可独立部署—使团队能够部署其服务，而无需与其他团队协调
• 能够由一个小团队开发-避免大型团队的高沟通负责人，这对高生产率至关重要

服务使用同步协议（如HTTP/REST）或异步协议（如AMQP）进行通信。服务可以彼此独立地开发和部署。每个服务都有自己的数据库，以便与其他服务分离。使用Saga模式维护服务之间的数据一致性

示例

虚拟电子商务应用

假设您正在构建一个电子商务应用程序，该应用程序接收客户的订单，验证库存和可用信用，然后发货。该应用程序由几个组件组成，包括实现用户界面的StoreFrontUI，以及一些用于检查信用、维护库存和发货订单的后端服务。应用程序由一组服务组成。

结果上下文

好处

此解决方案有许多好处：

• 支持大型复杂应用程序的连续交付和部署。
• 改进的可维护性—每个服务都相对较小，因此更易于理解和更改
• 更好的可测试性—服务更小，测试速度更快
• 更好的可部署性—服务可以独立部署
• 它使您能够围绕多个自主团队组织开发工作。每个（所谓的两个比萨饼）团队拥有并负责一个或多个服务。每个团队都可以独立于所有其他团队开发、测试、部署和扩展其服务。

每个微服务都相对较小：

• 开发人员更容易理解
• IDE的速度更快，开发人员的工作效率更高
• 应用程序启动速度更快，这使开发人员的工作效率更高，并加快了部署
• 改进的故障隔离。例如，如果一个服务中存在内存泄漏，则只有该服务会受到影响。其他服务将继续处理请求。相比之下，单片体系结构中一个行为不端的组件会导致整个系统瘫痪。
• 消除了对技术堆栈的任何长期承诺。在开发新服务时，您可以选择一个新的技术堆栈。类似地，在对现有服务进行重大更改时，可以使用新的技术堆栈重写它。

缺点

此解决方案有许多缺点：

• 开发人员必须处理创建分布式系统的额外复杂性：
• 开发人员必须实现服务间通信机制并处理部分故障
• 实现跨多个服务的请求更加困难
• 测试服务之间的交互更加困难
• 实现跨多个服务的请求需要团队之间的仔细协调

开发工具/ide面向构建单片应用程序，不提供开发分布式应用程序的明确支持。

部署复杂性。在生产环境中，部署和管理由许多不同服务组成的系统也存在操作复杂性。

内存消耗增加。微服务架构用NxM服务实例替换N个单片应用实例。如果每个服务都在自己的JVM（或等效的JVM）中运行，这通常是隔离实例所必需的，那么JVM运行时的开销是JVM运行时的M倍。此外，如果每个服务都在自己的VM（例如EC2实例）上运行，就像Netflix的情况一样，开销甚至更高。

问题

有许多问题你必须解决。

何时使用微服务架构？

使用这种方法的一个挑战是决定何时使用它是有意义的。在开发应用程序的第一个版本时，您通常不会遇到这种方法解决的问题。此外，使用复杂的分布式体系结构会减慢开发速度。对于初创公司来说，这可能是一个主要问题，他们面临的最大挑战往往是如何快速发展业务模型和相应的应用程序。使用Y轴拆分可能会使快速迭代更加困难。然而，稍后，当挑战是如何扩展并且您需要使用功能分解时，复杂的依赖关系可能会使您难以将单片应用程序分解为一组服务。

如何将应用程序分解为服务？

另一个挑战是决定如何将系统划分为微服务。这在很大程度上是一门艺术，但是有很多策略可以帮助你：

• 按业务能力分解，定义业务能力对应的服务。
• 按领域驱动设计子域分解。
• 按动词或用例分解并定义负责特定操作的服务。e、 负责运送完整订单的运输服务。
• 通过定义负责给定类型的实体/资源上的所有操作的服务，按名词或资源进行分解。e、 负责管理用户帐户的帐户服务。

理想情况下，每个服务应该只有一小部分职责(Bob Martin谈到使用单一责任原则（SRP）设计类。SRP将类的责任定义为更改的原因，并指出类应该只有一个更改的原因。将SRP应用于服务设计也是有意义的。

另一个有助于服务设计的类比是Unix实用程序的设计。Unix提供了大量实用程序，如grep、cat和find。每个实用程序只做一件事，通常做得非常好，并打算与其他实用程序结合使用shell脚本来执行复杂的任务。

如何保持数据一致性？

为了确保松散耦合，每个服务都有自己的数据库。维护服务之间的数据一致性是一项挑战，因为两阶段提交/分布式事务不是许多应用程序的选项。应用程序必须使用Saga模式。服务在其数据更改时发布事件。其他服务使用该事件并更新其数据。有几种可靠地更新数据和发布事件的方法，包括事件源和事务日志跟踪。

如何实现查询？

另一个挑战是实现需要检索多个服务拥有的数据的查询。

API组合和命令查询责任分离（CQRS）模式。

相关模式

有许多模式与微服务模式相关。单片体系结构是微服务体系结构的替代方案。其他模式解决应用微服务体系结构时遇到的问题。

• 分解模式
• 按业务能力分解
• 按子域分解
• 每个服务的数据库模式描述了每个服务如何拥有自己的数据库以确保松散耦合。
• API网关模式定义了客户端如何访问微服务体系结构中的服务。
• 客户端发现和服务器端发现模式用于将客户端请求路由到微服务体系结构中的可用服务实例。
• 消息传递和远程过程调用模式是两种不同的服务通信方式。
• 每主机一个服务和每主机多个服务模式是两种不同的部署策略。
• 交叉关注点模式：微服务机箱模式和外部化配置
• 测试模式：服务组件测试和服务集成契约测试

已知用途

包括Netflix、Amazon和eBay在内的大多数大型网站都已从单一的体系结构演变为微服务体系结构。

Netflix是一种非常流行的视频流服务，它负责高达30%的互联网流量，具有大规模的面向服务的体系结构。他们每天处理超过10亿个来自800多种设备的视频流API调用。每一个API调用平均会有六个对后端服务的调用。

Amazon.com最初有一个两层架构。为了扩展，他们迁移到一个面向服务的体系结构，这个体系结构由数百个后端服务组成。一些应用程序调用这些服务，包括实现Amazon.com网站和web服务API的应用程序。Amazon.com网站应用程序调用100-150个服务来获取用于构建网页的数据。

拍卖网站ebay.com也从单一的体系结构演变为面向服务的体系结构。应用层由多个独立的应用程序组成。每个应用程序实现特定功能领域（如购买或销售）的业务逻辑。每个应用程序使用X轴拆分，而搜索等一些应用程序使用Z轴拆分。Ebay.com还对数据库层应用X、Y和Z风格的缩放组合。

还有许多其他公司使用微服务架构的例子。