架构模式: 微服务架构

模式: 微服务架构

背景

在开发服务端企业应用时，应用需要支持各种不同类型的客户端，比如桌面浏览器、移动浏览器以及原生移动应用。应用还需要向第三方提供可访问的API，并通过Web Service或者消息代理与其它应用实现集成。应用通过执行业务逻辑、访问数据库、与其它系统交换信息、并返回一条HTML/JSON/XML响应，来处理请求（HTTP请求与消息）。

应用采用多层架构或者六角架构，主要由以下几类不同组件构成：

• 展现组件——负责处理HTTP请求并响应HTML或者JSON/XML（对于web Services APIs）
• 业务逻辑——应用的业务逻辑
• 数据库访问逻辑——用于访问数据库的数据访问对象
• 应用集成逻辑——消息层，例如基于Spring Integration

不同逻辑组件分别响应应用中的不同功能模块。

问题

应用的部署架构是什么？

需求

• 应用需要由一个开发者团队专门负责
• 团队新成员需要快速上手
• 应用应该易于理解和修改
• 对应用能够进行持续部署
• 需要在多台设备上运行应用副本，从而满足可扩展性与可用性的要求
• 使用各种新技术（框架、编程语言等）

方案

用 Scale Cube 方法（特别是Y轴扩展）设计应用架构，将应用程序按功能拆分为一组互相协作的服务。每个服务实现一组特定、相关的功能。举例来说，一个应用程序可能由订单管理服务、客户管理服务等多个服务构成。

服务间的通信则可由HTTP/REST等同步协议或者AMQP等异步协议实现。服务可以彼此独立开发与部署。每个服务皆有自己的数据库，从而保证其与其它服务解耦。在必要时，可利用数据库复制机制或者应用层事件驱动机制，维护数据库之间的数据一致性。

示例

假设需要构建一款电子商务应用程序，使其能够接收来自客户的订单、验证库存信息与可用信用额度，而后进行发货。该应用程序会包含多个组件，其中StoreFrontUI负责实现用户界面，而其它后端服务则分别负责检查信用额度、维护库存信息以及发送订单。

此应用程序被部署为一组服务集合。
​

​

 

结果

优势

此类解决方案拥有以下优势：

• 每项微服务相对较小
  • 易于开发者理解
  • IDE处理速度更快，可提高开发者生产效率
  • Web容器启动速度更快，提高开发者生产效率并可加快部署速度
• 每项服务皆可独立于其它服务进行部署——简化频繁部署新服务版本的流程
• 易于实现规模化开发。多团队可以共同进行开发工作。每个（双披萨，即团队成员规模控制在订购两块披萨即可吃饱的程度）团队负责其中一项服务。各团队可独立于其他团队，进行开发、部署工作及扩展自身服务。
• 改善故障隔离。举例来说，如果某一服务出现内存外溢，则只有该服务本身受到影响。其它服务将继续正常处理请求。相比之下，单体架构中的故障组件会令整套系统陷入瘫痪。
• 每项服务可独立进行开发与部署
• 无需长期使用同一套技术堆栈

弊端：

但这类解决方案中也存在着以下弊端：

• 开发者必须应对创建分布式系统所产生的额外的复杂因素。
  • 现有开发者工具/IDE主要面向单体应用程序，因此无法显式支持分布式应用的开发。
  • 测试工作更加困难。
  • 开发者必须采取服务间通信机制。
  • 很难在不使用分布式事务机制的情况下跨服务实现功能。
  • 跨服务实现功能要求各团队进行密切协作。
• 部署复杂。在生产环境下，对这类多种服务类型构建而成的系统进行部署与管理十分困难。
• 内存占用量更高。微服务架构使用N*M个服务实例替代N个单体应用实例，如果每项服务运行自己的JVM（或者其它类似机制），且各实例之间需要进行隔离，那将导致M倍JVM运行时的额外开销。另外，如果每项服务都在自己的虚拟机（例如 EC2 实例）上运行，如同Netflix一样，那么额外开销会更高。

需要解决的问题

采用微服务架构之前，有若干需要解决的问题。

何时应该使用微服务架构？

应用此类方案带来的挑战在于如何把握好时机。在开发应用程序的最初版本时，大家往往不会面临需要使用微服务架构才能解决的问题。另外，使用复杂的分布式架构会拖慢开发流程。对于初创企业，其面临的最大挑战往往在于如何快速发展商业模式及附属应用。微服务架构中的Y轴拆分方式可能使应用更加难以迅速迭代。但是，如果当面临需要解决扩展性问题的时候再去进行功能拆分，单体应用的复杂依赖性使其很难被分解为服务集合。

如何将应用拆分为服务？

另一项挑战在于如何将系统拆分为多个微服务。这虽然很棘手但还是有些可行之策：

• 根据业务能力拆分（Decompose by business capability） - 根据业务能力界定服务的范围
• 根据领域的子域拆分（Decompose by subdomain） - 根据领域驱动设计中子域的概念界定服务的范围
• 根据“动词”或者用例进行服务划分。举例来说，我们经常会在电子商务应用中发现有单独的“发货”服务用于处理已完成订单。另一种常见的“动词”划分方式是实现登录用例的“登录”服务。
• 根据“名词”或者资源进行系统划分。这类服务负责利用特定的实体/资源完成一系列操作。举例来说，大家可能会在电子商务系统当中发现有“库存”服务用于跟踪货物的库存。

在理想情况下，每项服务都应只面向一小部分职责。（大叔）Bob Martin 曾提出根据单一责任原则（Single Responsibility Principle，简称 SRP）进行类的设计。SRP 会用单一变更理由去定义一个类的职责：一个类的状态变更只能由一个原因导致。同理，我们也可以在微服务设计当中引入 SRP。

另一项可用于指导服务设计的是Unix工具的设计思路。Unix 提供大量工具选项，包括 grep、cat 以及 find 等等。每种工具都只负责实现一项功能，而且功能良好，它们可以通过Shell脚本与其它工具结合进而执行复杂的任务。

如何维护数据一致性？

为了确保松耦合，每个服务都有独用的数据库。维护服务间的数据一致性成为了挑战。在多数应用的架构下，2 阶段提交和分布式事务不再是一个可选项。应用需要采用事件驱动架构，一个服务在其数据发生变化时，对外发布一个事件，其他服务订阅并通过消费这个事件来对应更新自己的数据。有一些可靠的方式可以实现事件的发布和数据的更新，比如事件溯源 和事物日志跟踪。

如何实现数据查询？

另一个挑战是进行跨服务的数据的查询。一个常用的解决方式是采用CQRS，维护一份包含重要数据的视图并通过事件流的方式保持数据的更新。

相关模式

微服务架构有很多与之相关的模式，单体架构 便是微服务架构的另一众选择。在应用微服务架构时，您还会跟如下这些模式打交道：
​

​

 

• 服务拆分模式
  • 根据业务能力拆分
  • 根据领域的子域拆分
• 每服务数据库模式 描述了服务之间采用独享数据库的方式实现了解耦合。
• API 网关模式 定义在微服务架构下客户端访问服务的方式。
• 客户端服务发现 和 服务器端服务发现 模式用来在微服务架构中把客户端请求路由到一个可用的服务实例上。
• 消息和远程过程调用是服务间通信的两种选择。
• 单主机上部署服务的单个实例 和 单主机上部署服务的多个实例 模式是两种不同的部署策略。
• 解决边界问题的模式：: 微服务的基底模式 和 配置信息外部化
• 可测试性模式: 服务组件测试 和 服务集成协议测试
• 断路器
• 访问令牌
• 可观测性模式:
  • 应用日志
  • 应用指标
  • 审计日志
  • 分布式追踪
  • 异常追踪
  • 健康检查
• UI 模式:
  • 服务器端页面碎片化元素构建
  • 客户端 UI 构建

已知案例

众多大型网站将单体架构发展为微服务架构，其中包括 Netflix、Amazon 与 eBay 等。

作为一个热门视频流服务，Netflix 利用一套大规模的面向服务的架构来承载高于 30% 的互联网流量。该公司每天需要处理来自 800 多种设备的 10 亿多次视频流 API 请求。平均每次 API 调用会在后端服务中产生 6 次后续调用。

Amazon.com 最初采用一套双层架构。为了扩展业务规模，其决定迁移至一套由数百项后端服务构成的面向服务的架构。多个应用调用这些服务，其中包括 Amazon.com网站和Web服务API。Amazon.com 网站需要调用 100 到 150 个服务方可获取到构建一个 Web 页面所需的全部数据。

作为拍卖网站，eBay.com 也是从单体架构逐步转向面向服务的架构。其应用层由多个独立应用构成。每个应用负责实现完成一组特定功能的业务逻辑，例如购买或者出售。每个应用皆利用X轴进行拆分，部分应用（例如搜索）以Z轴进行拆分。eBay.com 还在数据库层采用了 X、Y 与 Z 轴相结合的扩展方式。