微服务模式系列之二：微服务架构

译者评论：

微服务架构大家已经耳熟能详，但是我认为这篇文章最有价值的是这段：

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

• 开发者必须应对创建分布式系统所产生的额外的复杂因素。 现有开发者工具/IDE主要面向单体应用程序，因此无法显式支持分布式应用的开发。

• 测试工作更加困难。

• 开发者必须采取服务间通信机制。
• 很难在不使用分布式事务机制的情况下跨服务实现功能。

• 跨服务实现功能要求各团队进行密切协作。

• 部署复杂。在生产环境下，对这类多种服务类型构建而成的系统进行部署与管理十分困难。

• 内存占用量更高。微服务架构使用N*M个服务实例替代N个单体应用实例，如果每项服务运行自己的JVM（或者其它类似机制），且各实例之间需要进行隔离，那将导致M倍JVM运行时的额外开销。另外，如果每项服务都在自己的虚拟机（例如EC2实例）上运行，如同Netflix一样，那么额外开销会更高。

微服务架构带来的这些复杂性正是普元数字化企业云平台着力解决的。

译者自序：

熟悉我的朋友都知道，我很不喜欢翻译东西，因为在两种语言的思维方式之间做频繁切换对我来说是件很痛苦的事情。但是这次不一样，公司和同事的大力支持降低了我的痛苦指数，让我能够坚持把Chris Richardson的微服务模式系列文章翻译完，今天发布第二篇，《微服务架构》。

背景

在开发服务端企业应用时，应用需要支持各种不同类型的客户端，比如桌面浏览器、移动浏览器以及原生移动应用。应用还需要向第三方提供可访问的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轴拆分方式可能使应用更加难以迅速迭代。但是，如果当面临需要解决扩展性问题的时候再去进行功能拆分，单体应用的复杂依赖性使其很难被分解为服务集合。

另一项挑战在于如何将系统拆分为多个微服务。这虽然很棘手但还是有些可行之策。方法之一是根据“动词”或者用例进行服务划分。举例来说，我们经常会在电子商务应用中发现有单独的“发货”服务用于处理已完成订单。另一种常见的“动词”划分方式是实现登录用例的“登录”服务。

另外一种划分方式是根据“名词”或者资源进行系统划分。这类服务负责利用特定的实体/资源完成一系列操作。举例来说，大家可能会在电子商务系统当中发现有“库存”服务用于跟踪货物的库存。

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

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

相关模式

微服务相关模式有很多，其中包括：

• 单体架构是微服务架构的备选方案。
• 由API Gateway模式定义客户端如何在微服务架构中访问对应服务。
• 客户端发现模式与服务器端发现模式，用于将客户端的请求路由至微服务架构中的可用服务实例。
• 消息收发与远程流程调用模式是两种不同的服务通信方式。
• 每主机一服务模式与每主机多服务模式是两种不同的部署策略。
• 每服务一数据库模式表示每项服务拥有自己的数据库。
• 微服务底盘模式是指利用一套可以处理横切关注点的框架来构建微服务。

已知案例

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

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

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

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

示例

Chris Richardson提出了多项微服务应用示例，点击英文原文查看。
英文原文链接
译文原文链接