模式：微服务架构

2018-08-25 本文已影响0人 scheshan

背景

你正在开发一个服务端的企业应用程序。它必须支持不同的客户端，包括桌面浏览器，移动端浏览器和原生手机应用。它需要暴露一个API接口给第三方消费。它需要通过web service或者消息机制与其他应用程序集成。它接受请求（HTTP请求和消息）；执行业务逻辑；访问数据库；与其他系统交换数据；返回HTML/JSON/XML响应。这个应用中，不同的功能区域都对应着不同的逻辑组件。

问题

该应用的部署架构？

限制

一个团队的开发人员正在开发这个应用
新的团队成员应该迅速上手
该应用应该容易理解和修改
你想尝试持续部署
你必须在不同机器上运行该应用的拷贝，以满足可扩展性和可用性的需求
你想尝试新的技术（框架，编程语言等）

解决方案

定义一种架构，将应用程序组织为松散写作的服务。这个方法对应于Scale Cube的Y轴。每个服务都定义了一组狭隘的相关功能。例如，应用程序可以包含订单管理服务，客户管理服务等等。
服务之间使用同步协议，例如HTTP/REST或者异步协议，例如AMQP交互。服务之间可以独立的开发和部署。每个服务拥有它自己的数据库，与其他服务解耦。服务之间的数据一致是通过Saga pattern管理。

示例

虚拟的电商应用

设想一下，你正在构建一个商城应用程序，为客户生成订单，验证库存和可用积分，快递商品。这个应用程序由以下几个组件构成：商城前端UI，它包括了用户界面；后端服务，包括检查积分，管理库存和运送商品。该应用程序包含一组服务。

微服务架构应用程序

展示代码

请访问 example applications developed by Chris Richardson。这些示例在github.com上，展示了微服务架构的各个方面。

结果

优势

该解决方案有以下优势：

允许持续交付和部署大型，复杂的应用程序
- 更好的可测试性 - 服务测试更小，更快
- 更好的部署能力 - 服务可以独立的部署
- 允许你围绕多个自动化团队组织开发工作。允许你围绕多个部门组织开发工作。每个部门负责一个或多个单独的服务。每个部门都可以独立开发，部署和扩展他们的服务。
每个微服务相对较小
- 很容易让每个开发人员理解
- IDE启动更快，让开发人员更有效率
- 应用启动更快，这让开发人员更有效率，而且加快开发速度
提高了错误隔离。例如，如果一个服务出现内存泄漏，仅有这个服务会受到影响。其他服务将继续处理请求。作为比较，单体架构中一个组件出现异常，将拖垮整个系统。
消除对一个技术栈的长期依赖。当开发一个新服务时，你可以选择新技术栈。同样，当对现有服务做出重大修改时，也可以用一个新技术栈来重写它。

弊端

该解决方案有以下弊端：

开发人员必须处理额外带来的分布式系统的复杂性。
- 开发工具/IDE面向的是构建单体应用，不为开发分布式应用程序提供明确支持
- 测试变得更复杂
- 开发人员必须实现服务内部的通信机制
- 实现跨多个服务的用例而不使用分布式事务非常困难
- 实现跨多个服务的用例需要部门之间的紧密合作
部署复杂性。在生产环境中，存在部署和管理包含多个不同服务类型的系统的操作复杂性。
内存消耗增加。微服务架构将N个单体应用替换成了N×M个服务实例。如果每个服务都运行在它独有的JVM（或者类似的运行时），这对隔离实例很游泳，这样就存在M倍的开销。还有，如果每个服务运行在它
独有的虚拟机（或者EC2实例），比如Netflix那样，开销会更高。

问题

你必须解决很多问题。

什么时候该采用微服务架构？

采用这个方法的一个挑战是决定什么时候使用它。当开发一个应用的第一个版本，你通常不会遇到必须采用这个架构才能解决的难题。此外，采用精心设计的分布式架构会减慢开发速度。这对初创公司是个主要问题，因为他们最大的挑战通常是迅速解决业务模型和对应的应用程序。使用Y轴拆分，会使迅速迭代变得更困难。然而，一段时间后，当挑战变成如何扩展，并且你需要使用功能分解时，这些纠缠的依赖可能使你难以将单体应用分解成一组服务。

如何将应用分解成服务？

另外一个挑战是决定该如何将系统拆分到微服务。这更是一门艺术，但是有一些策略可以帮上忙：

按业务能力拆分，定义与业务能力相对应的服务。
按领域驱动设计的子域拆分.
按谓词和用例拆分，定义与特定行为对应的服务。例如，一个“Shipping Service”对应运送订单。
按名词和资源拆分，定义与一个指定类型的entities/resources的所有操作相对应的服务。例如，一个“Account Service”对应管理用户账号。

理想角度，每个服务应该只拥有一小部分能力。Bob Martin讨论了采用单一职责原理（SRP）来设计类。SRP将一个类的职责定义为改变的理由，并且一个类只能有一个理由发生改变。将SRP应用到服务设计很有意义。
另一个帮助服务设计的类比是Unix工具设计理念。Unix提供了众多的工具，比如grep，cat和find。每个工具只明确做一件事，通常非常好，而且可以通过一个shell脚本和其他工具合并，提供复杂的任务。

如何保持数据一致性？

为了确保松耦合，每个服务都有它肚子的数据库。由于2阶段提交/分布式事务在多数应用中并不是一个选择，在不同服务之间保持数据一致是个很大的挑战。应用程序必须改为采用Saga模式。服务在数据发生更改时发布事件。其他服务订阅事件并更新它们的数据。有很多种方式可以可靠的更新数据和发布事件，包括Event Sourcing和Transaction Log Tailing。

如何实现查询

另外一个挑战是查询多个服务拥有的数据

API Composition 和 Command Query Responsibility Segregation (CQRS) 模式。

已知案例

大多数大型网站，包括 Netflix，Amazon和eBay都从单体架构进化到了微服务架构。

Netflix，知名的视频流服务，承担了30%的互联网访问流量，采用了大规模的，面向服务的架构。他们每天处理来自800个不同设备类型，针对视频流API的上十亿次调用。每个API调用平均分散出对后台服务的六次调用。

Amazon.com最开始采用两层架构。为了扩展，他们迁移为存在几百个后端服务的面向服务架构。一部分应用程序调用这些服务，包括Amazon.com网站和web服务API。Amazon.com网站访问100-150个服务，获取数据构建网页。

拍卖网站ebay.com也从单体架构进化到了面向服务架构。应用层有很多独立的应用程序。每个应用程序实现了特定功能领域的业务逻辑，比如购买和销售。每个应用程序采用X-轴切割；一部分应用，比如搜索，采用Y-轴切割。Ebay.com针对数据库层提供了X-，Y-，Z-风格的合并。

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