微服务的设计模式（一）

在优锐课的学习分享中，讨论了关于微服务的许多设计模式的详细描述。
码了很多专业的相关知识， 分享给大家参考学习。

微服务可以对你的企业产生积极影响。 因此，有必要知道如何处理微服务架构（MSA）和一些微服务设计模式，以及微服务架构的一般目标或原理。 这是微服务架构方法[1]中要考虑的四个目标。

降低成本：MSA将降低设计，实施和维护IT服务的总体成本。
提高发布速度：MSA将提高从构思到服务部署的速度。
提高弹性：MSA将提高我们服务网络的弹性。
启用可见性：MSA支持可在你的服务和网络上提供更好的可见性。

你需要了解微服务架构的构建原理

可扩展性
可用性
弹性
灵活性
独立自主
分散管理
故障隔离
自动配置
通过DevOps连续交付

遵循上述原则，在使你的解决方案或系统付诸实践的同时，会带来一些挑战和问题。 这些问题在许多解决方案中都很常见。 使用正确和匹配的设计模式可以克服这些问题。 微服务有一些设计模式，可以分为五种模式。 每个都包含许多模式。

分解模式

通过业务能力分解微服务的全部目的是使服务松散耦合并应用单一责任原则。 它根据业务能力分解。 定义与业务功能相对应的服务。 业务能力是来自业务体系结构建模的概念[2]。 企业为了创造价值而要做的事情。 业务能力通常对应于一个业务对象，例如

订单管理负责订单
客户管理对客户负责
按子域分解

使用业务功能分解应用程序可能是一个不错的开始，但是你会遇到所谓的“神类”，这很难分解。 这些类将在多种服务中通用。 定义与域驱动设计（DDD）子域相对应的服务。 DDD将应用程序的问题空间（即业务）称为域。 一个域由多个子域组成。 每个子域对应于业务的不同部分。 子域可以分类如下：

核心-业务和应用程序最有价值部分的关键区别
支持-与业务活动有关，但与差异化无关； 可以在内部实施或外包
通用-不特定于业务，理想情况下使用现成的软件实施

订单管理的子域包括

产品目录服务
库存管理服务
订单管理服务
送货管理服务

按事务分解/两阶段提交（2pc）模式

这种模式可以分解事务上的服务。 然后，系统中将有多个事务。 分布式事务处理的重要参与者之一是事务处理协调器[3]。 分布式事务包括两个步骤：

“准备阶段”-“在此阶段中，事务的所有参与者都准备提交并通知协调者他们已准备好完成事务
“提交”或“回滚”阶段-在此阶段，事务协调器向所有参与者发出“提交”或“回滚”命令

2PC的问题在于，与单个微服务的运行时间相比，它相当慢。 即使微服务在同一网络上，它们之间的事务协调也确实会降低系统速度。 因此通常不会在高负载情况下使用此方法。

扼杀模式

你所经历的前三个设计模式是分解Greenfield的应用程序，但是你所做的工作中有80％是针对Brownfield应用程序，它们是大型的整体式应用程序（旧版代码库）。 扼杀者模式可以解决。 这将创建两个单独的应用程序，它们在同一URI空间中并排运行。 随着时间的流逝，新重构的应用程序会“扼杀”或替换原始应用程序，直到最终，你可以关闭整体应用程序。 Strangler应用程序步骤已转换，共存并消除[4]：

Transform—使用现代方法创建并行的新站点。
共存—将现有站点保留一段时间。 从现有站点重定向到新站点，以便逐步实现该功能。
消除-从现有站点中删除旧功能。

隔板图案

此模式将应用程序的元素隔离到池中，这样，如果其中一个失败，其他应用程序将继续运行。 这种模式被称为“舱壁”，因为它类似于船体的分段分区。 根据使用者负载和可用性要求，将服务实例划分为不同的组。 此设计有助于隔离故障，并允许你即使在故障期间仍可为某些使用者维持服务功能。

边车图案

这会将应用程序的组件部署到单独的处理器容器中，以提供隔离和封装。 这种模式还可以使应用程序由异构组件和技术组成。 该模式被称为Sidecar，因为它类似于连接到摩托车的Sidecar。 在该模式中，sidecar附加到父应用程序，并为该应用程序提供支持功能。 Sidecar还与父应用程序共享相同的生命周期，并与父应用程序一起创建并退出。 Sidecar模式有时被称为sidekick模式，是我们在文章中显示的最后一个分解模式。

整合模式

API网关模式当应用程序分解为较小的微服务时，有一些需要解决的问题API

通过不同的渠道多次调用多个微服务。
需要处理不同类型的协议。
不同的消费者可能需要不同格式的响应。

API网关有助于解决由微服务实现引起的许多问题，而不仅限于上述问题。

API网关是任何微服务调用的单一入口点。
它可以作为代理服务将请求路由到相关的微服务。
它可以汇总结果以发送回消费者。
此解决方案可以为每种特定类型的客户端创建细粒度的API。
它也可以转换协议请求并做出响应。
还可以减轻微服务的身份验证/授权责任。

聚合模式

将业务功能分解为几个较小的逻辑代码段时，有必要考虑如何协作每个服务返回的数据。消费者不能承担这种责任。
聚集器模式有助于解决此问题。它讨论了如何聚合来自不同服务的数据，然后将最终响应发送给消费者。这可以通过两种方法来完成[6]：

组合微服务将调用所有必需的微服务，合并数据并转换数据，然后再发送回去。
API网关还可在将请求发送给使用者之前将请求划分为多个微服务并聚合数据。

如果要应用任何业务逻辑，建议选择复合微服务。否则，API网关是已建立的解决方案。代理模式API网关仅通过API网关公开微服务。在此示例中，

API网关具有三个API模块：

移动API，可为FTGO移动客户端实现API。
浏览器API，该API为浏览器中运行的JavaScript应用程序实现该API。
公共API，它为第三方开发人员实现API。

网关路由模式

API网关负责请求路由。 API网关通过将请求路由到相应的服务来实现一些API操作。 当API网关接收到请求时，它会查询路由映射，该路由映射指定将请求路由到的服务。 路由映射例如可以将HTTP方法和路径映射到服务的HTTP URL。 此功能与Web服务器（如NGINX）提供的反向代理功能相同。

链式微服务模式

单个服务或微服务将具有多个依存关系，例如：销售微服务具有依存关系产品微服务和订单微服务。 链接微服务设计模式将帮助你将合并结果提供给你的请求。
微服务：1收到的请求，然后该微服务正在与微服务2通信，并且可能正在与微服务3通信。 所有这些服务都是同步调用。

分支模式

微服务可能需要从包括其他微服务在内的多个来源获取数据。 分支微服务模式是聚合器和链设计模式的混合，并允许来自两个或多个微服务的同时请求/响应处理。 调用的微服务可以是微服务链。 根据你的业务需求，分支模式还可用于调用不同的微服务链或单个链。

文章写道这里，先更上章节，下章节更新出来会第一时间发出来~

喜欢这篇文章的可以点个赞，欢迎大家留言评论，记得关注我，每天持续更新技术干货、职场趣事、海量面试资料等等
如果你对java技术很感兴趣也可以加入我的java学习群 V–（ddmsiqi）来交流学习，里面都是同行，验证【CSDN2】有资源共享。
不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！