模式: 微服务架构

Pattern: Microservice Architecture

上下文

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

问题

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

关注点

• 有一组开发人员在开发应用程序
• 新团队成员必须快速提高工作效率
• 应用程序必须易于理解和修改
• 您希望实践应用程序的持续部署
• 您必须在多台计算机上运行多个应用程序实例才能满足可伸缩性和可用性要求
• 您希望利用新兴技术（框架，编程语言等）

解决方案

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

• 高度可维护性和可测试性 -
• 实现快速，频繁的开发和部署与其他服务的松散耦合
• 使团队能够在大部分时间内独立工作，而不会受到其他服务变更的影响，也不会影响其他服务，可独立部署
• 使团队能够部署他们的服务而无需与其他团队协调能够由小团队开发 
• 通过避免大型团队的高通信负责人来提高生产力至关重要

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

请详细了解服务的性质， 读这篇文章.

例子

虚构的电子商务应用程序

让我们假设您正在构建一个电子商务应用程序，该应用程序接收来自客户的订单，验证库存和可用信用，并运送它们。该应用程序包含几个组件，包括实现用户界面的StoreFrontUI，以及用于检查信用，维护库存和装运订单的一些后端服务。该应用程序包含一组服务。

​

代码例子

Chris Richardson开发的微服务例子. Github上的这些示例说明了微服务架构的各个方面。

造成的影响

优点

该解决方案具有许多优点：

• 支持大型复杂应用程序的持续交付和部署。
  • 改进的可维护性 - 每项服务都相对较小，因此更易于理解和更改
  • 更好的可测试性 - 测试服务更小，速度更快
  • 更好的可部署性 - 可以独立部署服务
  • 它使您能够围绕多个自治团队组织开发工作。每个（所谓的两个披萨）团队拥有并负责一项或多项服务。每个团队都可以独立于所有其他团队开发，测试，部署和扩展他们的服务。
• 每个微服务都相对较小：
  • 开发人员更容易理解
  • IDE可以更快地提高开发人员的工作效率
  • 应用程序启动速度更快，这使开发人员的工作效率更高，并加快了部署速度
• 改善了故障隔离。例如，如果一个服务中存在内存泄漏，则只会影响该服务。其他服务将继续处理请求。相比之下，单片架构中的一个行为不当的组件可能会导致整个系统崩溃。
• 消除对技术堆栈的任何长期承诺。在开发新服务时，您可以选择新的技术堆栈。同样，在对现有服务进行重大更改时，您可以使用新技术堆栈重写它。

缺陷

该解决方案有许多缺点：

• 开发人员必须处理创建分布式系统的额外复杂性：
  • 开发人员必须实现跨服务通信机制并处理部分失败
  • 实现跨多个服务的请求更加困难
  • 测试服务之间的交互更加困难
  • 实现跨多个服务的请求需要团队之间的仔细协调
  • 开发人员工具/ IDE面向构建单一应用程序，并不为开发分布式应用程序提供明确支持。
• 部署复杂性。在生产中，还存在部署和管理由许多不同服务组成的系统的操作复杂性。
• 增加内存消耗。微服务架构用NxM服务实例替换N个单片应用程序实例。如果每个服务都在自己的JVM（或等效服务器）中运行，这通常是隔离实例所必需的，那么就会产生M倍运行时M次的开销。此外，如果每个服务在其自己的VM（例如EC2实例）上运行，如Netflix的情况，则开销甚至更高。

问题

您必须解决许多问题。
 

何时使用微服务架构？
 

使用这种方法的一个挑战是决定何时使用它。在开发应用程序的第一个版本时，您通常不会遇到此方法所解决的问题。此外，使用精心设计的分布式架构将减缓开发速度。对于初创公司而言，这可能是一个主要问题，其最大的挑战通常是如何快速发展业务模型和随附的应用程序。使用Y轴拆分可能会使快速迭代变得更加困难。然而，稍后，当挑战是如何扩展并且您需要使用功能分解时，纠结的依赖关系可能使您难以将整体应用程序分解为一组服务。

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

另一个挑战是决定如何将系统划分为微服务。这是一门艺术，但有许多策略可以提供帮助：

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

理想情况下，每项服务应该只有一小部分职责。（叔叔）Bob Martin谈到使用单一责任原则（SRP）设计课程。SRP将类的责任定义为改变的理由，并声明类只应有一个改变的理由。将SRP应用于服务设计也是有意义的。

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

如何保持数据一致性？

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

如何实现查询？

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

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

关联的架构模式

有许多与微服务模式相关的模式。单片架构是微服务架构的替代品。其他模式解决了在应用微服务架构时将遇到的问题。
 

​

• Decomposition patterns
  • Decompose by business capability
  • Decompose by subdomain
• The Database per Service pattern describes how each service has its own database in order to ensure loose coupling.
• The API Gateway pattern defines how clients access the services in a microservice architecture.
• The Client-side Discovery and Server-side Discovery patterns are used to route requests for a client to an available service instance in a microservice architecture.
• The Messaging and Remote Procedure Invocation patterns are two different ways that services can communicate.
• The Single Service per Host and Multiple Services per Host patterns are two different deployment strategies.
• Cross-cutting concerns patterns: Microservice chassis pattern and Externalized configuration
• Testing patterns: Service Component Test and Service Integration Contract Test
• Circuit Breaker
• Access Token
• Observability patterns:
  • Log aggregation
  • Application metrics
  • Audit logging
  • Distributed tracing
  • Exception tracking
  • Health check API
  • Log deployments and changes
• UI patterns:
  • Server-side page fragment composition
  • Client-side UI composition

已知用户

包括Netflix，亚马逊和eBay在内的大多数大型网站已从单片架构发展为微服务架构。
Netflix是一种非常受欢迎的视频流服务，负责高达30％的互联网流量，具有大规模，面向服务的架构。他们每天处理来自800多种不同设备的视频流API超过10亿次呼叫。每个API调用都会向平均六次调用后端服务。
Amazon.com最初有两层架构。为了扩展，他们迁移到由数百个后端服务组成的面向服务的体系结构。有几个应用程序调用这些服务，包括实现Amazon.com网站和Web服务API的应用程序。Amazon.com网站应用程序调用100-150服务来获取用于构建网页的数据。
拍卖网站ebay.com也从单片架构演变为面向服务的架构。应用程序层由多个独立的应用程序组成。每个应用程序都实现特定功能区域的业务逻辑，例如购买或销售。每个应用程序都使用X轴分割，一些应用程序（如搜索使用Z轴分割）。Ebay.com还将X，Y和Z样式缩放的组合应用于数据库层。
使用微服务架构的公司还有许多其他例子。

例子

Chris Richardson has examples of microservices-based applications.

See my Code Freeze 2018 keynote, which provides a good introduction to the microservice architecture.