微服务架构

一、上下文

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

二、问题

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

三、目的

有一组开发人员正在处理该应用程序 新团队成员必须迅速提升工做效率 应用程序必须易于理解和修改 您但愿实践应用程序的持续部署 您必须在多台计算机上运行该应用程序的多个实例，以知足可伸缩性和可用性要求 您想利用新兴技术（框架，编程语言等）

解决方案

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

优势

该解决方案具备许多优势：

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

缺点

该解决方案有许多缺点：

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

什么时候使用微服务架构？

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

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

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

按业务能力分解并定义与业务功能相对应的服务。 经过域驱动设计子域进行分解。 经过动词或用例分解并定义负责特定操做的服务。例如Shipping Service，负责运送完整订单。 经过定义一个服务来分解名词或资源，该服务负责对给定类型的实体/资源的全部操做。例如 Account Service，负责管理用户账户的人。 理想状况下，每项服务应该只有一小部分职责。（叔叔）Bob Martin谈到使用单一责任原则（SRP）设计课程。SRP将类的责任定义为改变的理由，并声明类只应有一个改变的理由。将SRP应用于服务设计也是有意义的。

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

如何保持数据一致性？

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

如何实现查询？

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

该API组成，并命令查询职责隔离（CQRS）模式。

相关模式

有许多与微服务模式相关的模式。该单机结构是将微服务架构的替代方案。其余模式解决了在应用微服务架构时将遇到的问题。