应用架构模式之微服务模式

最新推荐文章于 2024-07-22 17:51:09 发布

lcli

最新推荐文章于 2024-07-22 17:51:09 发布

阅读量348

点赞数

分类专栏： PHP

PHP 专栏收录该内容

76 篇文章

订阅专栏

背景

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

问题

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

现状和诉求

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

解决办法

定义一个体系结构，将应用程序构建为一组松散耦合的协作服务。该方法对应于Scale Cube的Y轴。每个服务都实现了一组狭义的相关功能。例如，应用程序可能包含订单管理服务，客户管理服务等服务。

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

例子

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

结果背景

优点

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

1 支持大型复杂应用程序的持续交付和部署。

更好的可测试性 - 测试服务更小，速度更快
更好的可部署性 - 可以独立部署服务
它使您能够围绕多个自动团队组织开发工作。它使您能够围绕多个团队组织开发工作。每个（两个披萨）团队拥有并负责一项或多项单项服务。每个团队都可以独立于所有其他团队开发，部署和扩展他们的服务。

2 每个微服务都相对较小

开发人员更容易理解
IDE可以更快地提高开发人员的工作效率
应用程序启动速度更快，这使开发人员的工作效率更高，并加快了部署速度

3 改善了故障隔离。例如，如果一个服务中存在内存泄漏，则只会影响该服务。其他服务将继续处理请求。相比之下，单片架构中的一个行为不当的组件可能会导致整个系统崩溃。

4 消除对技术堆栈的任何长期承诺。在开发新服务时，您可以选择新的技术堆栈。同样，在对现有服务进行重大更改时，您可以使用新技术堆栈重写它。

缺点

该解决方案有许多缺点：

1 开发人员必须处理创建分布式系统的额外复杂性。

开发人员工具/ IDE面向构建单一应用程序，并不为开发分布式应用程序提供明确支持。
测试更加困难
开发人员必须实现跨服务通信机制。
实现跨越多个服务而不使用分布式事务的用例很困难
实现跨多个服务的用例需要团队之间的仔细协调

2 部署复杂性。在生产中，还存在部署和管理由许多不同服务类型组成的系统的操作复杂性。

3 增加内存消耗。微服务架构用NxM服务实例替换N个单片应用程序实例。如果每个服务都在自己的JVM（或等效服务器）中运行，这通常是隔离实例所必需的，那么就会产生M倍运行时M次的开销。此外，如果每个服务在其自己的VM（例如EC2实例）上运行，如Netflix的情况，则开销甚至更高。

注意点

1 何时使用微服务架构？

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

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

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

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

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

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

3 如何保持数据一致性？

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

4 如何实现查询？

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

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