本文旨在让大家了解微服务体系结构的设计模式以克服微服务所带来的挑战。文章会分为上下两篇，上篇包含1、分解模式2、集成模式，下篇包含3、数据库模式4、可观测性模式5、横切关注点的模式。
PS：丰富的一线技术、多元化的表现形式，尽在“
HULK一线技术杂谈
”，点关注哦！
微服务体系结构已经成为现代应用程序开发的实际选择。虽然它解决了某些问题，但它不是一颗银弹。它也有一些缺点，在使用这种体系结构时，有许多问题必须解决。这就需要学习这些问题中的通用模式，并使用可重用的解决方案来解决它们。因此，需要讨论微服务的设计模式。在深入研究设计模式之前，我们需要了解微服务体系结构的构建原则：
-
可伸缩性
-
可用性
-
弹性
-
独立的，自主的
-
分散治理
-
故障隔离
-
自动预配
-
通过DevOps持续交付
应用所有这些原则带来了一些挑战和问题。让我们讨论这些问题和它们的解决方案。
问题
微服务就是让服务松散耦合，应用单一职责原则。然而，将应用程序分解成更小的部分必须逻辑地完成。如何将应用程序分解为小型服务？
解决方案
一种策略是根据业务能力分解。业务能力是企业为了产生价值而做的事情。给定业务的功能集取决于业务类型。例如，保险公司的能力通常包括销售、营销、承保、理赔处理、开票、合规等。每个业务能力都可以被看作是一种服务，只是它是面向业务的，而非技术性的。
问题
使用业务功能分解应用程序可能是一个很好的开始，但是您会遇到所谓的“上帝类”，它们不容易分解。这些类在多个服务中很常见。例如，Order类将用于Order管理、Order收入、Order交货等等。我们如何分解它们？
解决方案
对于“上帝类”问题，DDD(领域-驱动 设计)起到了拯救作用。它使用子域和有界上下文概念来解决这个问题。DDD将为企业创建的整个领域模型分解为子领域。每个子域都有一个模型，该模型的作用域称为有界上下文。每个微服务都将围绕有界上下文开发。
备注
：识别子域并不是一项简单的任务。这需要对业务有所了解。与业务功能一样，子领域是通过分析业务及其组织结构以及识别不同的专业领域来识别的。
问题
到目前为止，我们讨论的设计模式是对greenfield的应用程序进行分解，但是我们所做的80%的工作是对brownfield应用程序进行分解，brownfield应用程序是大型的、单一的应用程序。将上面所有的设计模式应用到它们上是很困难的，因为将它们分解成更小的部分同时使用是一个很大的任务。
解决方案
勒死人的模式来了。勒死人的模式是基于一种藤蔓的类比，藤蔓缠绕着一棵树。这个解决方案很适合web应用程序，在web应用程序中，一个调用来回进行，对于每个URI调用，可以将服务分解为不同的域并作为独立的服务托管。我们的想法是一次做一个领域。这将创建两个独立的应用程序，它们并排放在同一个URI空间中。最终，新重构的应用程序将“扼杀”或替换原始应用程序，直到您最终可以关闭单片应用程序为止。
问题
当应用程序分解为更小的微服务时，有几个问题需要解决：
-
如何调用多个微型服务来提取生产者信息。
-
在不同的通道(如桌面、移动设备和平板电脑)上，应用程序需要不同的数据来响应相同的后端服务，因为UI可能不同。
-
不同的使用者可能需要不同格式的可重用微服务的响应。谁将进行数据转换或字段操作？
-
如何处理不同类型的协议，有些协议可能不受生产者微服务的支持。
解决方案
API网关有助于解决微服务实现引起的许多问题，而不仅仅局限于上述问题。
-
API网关是任何微服务调用的单一入口点。
-
它可以作为代理服务将请求路由到相关的微服务，抽象生产者的详细信息。
-
它可以将请求分散到多个服务，并聚合结果发送回消费者。
-
一刀切的api不能解决所有用户的需求；该解决方案可以为每种特定类型的客户机创建细粒度的API。
-
它还可以将协议请求(例如AMQP)转换为另一个协议(例如HTTP)，反之亦然，以便生产者和消费者能够处理它。
-
它还可以减轻微服务的身份验证/授权责任。
问题
我们已经讨论了如何解决API网关模式中的聚合数据问题。然而，我们将在这里整体地讨论它。在将业务功能分解为几个较小的逻辑代码片段时，有必要考虑如何协作每个服务返回的数据。这种责任不能留给消费者，因为那时它可能需要了解生产者应用程序的内部实现。
解决方案
聚合器模式有助于解决这个问题。它讨论了我们如何聚合来自不同服务的数据，然后将最终的响应发送给消费者。这可以通过两种方式实现：
-
复合微服务将调用所有所需的微服务，合并数据，并在发送回之前转换数据。
-
API网关还可以将请求划分为多个微服务，并在将数据发送给使用者之前聚合数据。
如果要应用任何业务逻辑，建议选择组合微服务。否则，API网关就是已建立的解决方案。
