在当今市场上，微服务已成为构建应用程序的首选解决方案。众所周知，它们可以解决各种挑战，但是，熟练的专业人员在使用此架构时经常面临挑战。因此，相反，开发人员可以探索这些问题中的常见模式，并可以创建可重用的解决方案来提高应用程序的性能。因此，在这篇关于微服务设计模式的文章中，我将讨论构建成功的微服务所必需的顶级模式。

本文将介绍以下主题：

什么是微服务？
用于设计微服务架构的原则
微服务的设计模式

什么是微服务？

微服务，又名微服务架构，是一种架构风格，将应用程序构建为围绕业务领域建模的小型自治服务的集合。在微服务架构中，每个服务都是自包含的并实现单一的业务能力。如果想详细了解微服务，可以参考我的微服务架构一文。

用于设计微服务架构的原则

用于设计微服务的原则如下：

独立自主的服务
可扩展性
权力下放(去中心化)
弹性服务
实时负载均衡
可用性
通过 DevOps 集成实现持续交付
无缝 API 集成和持续监控
故障隔离
自动配置

微服务的设计模式

聚合器
API 网关
连锁或责任链
异步消息
数据库或共享数据
事件溯源
分支
命令查询职责分离器
断路器
分解

聚合器模式

计算世界中的聚合器是指收集相关数据项并显示它们的网站或程序。因此，即使在微服务模式中，聚合器也是一个基本的网页，它调用各种服务来获取所需的信息或实现所需的功能。
此外，由于输出源在将单体架构分解为微服务时被划分，因此当您需要通过组合来自多个服务的数据来输出时，这种模式被证明是有益的。因此，如果我们有两个服务，每个服务都有自己的数据库，那么具有唯一事务 ID 的聚合器将从每个单独的微服务收集数据，应用业务逻辑并最终将其发布为 REST 端点。稍后，收集到的数据可以由需要收集到的数据的各个服务使用。
聚合设计模式基于 DRY 原则。基于此原则，您可以将逻辑抽象为复合微服务，并将特定业务逻辑聚合到一个服务中。
因此，例如，如果您考虑两个服务：服务 A 和 B，那么您可以通过将数据提供给复合微服务来同时单独扩展这些服务。

API 网关设计模式

微服务的构建方式使得每个服务都有自己的功能。但是，当应用程序被分解为小型自治服务时，开发人员可能面临的问题可能很少。问题可能如下：

如何从多个微服务请求信息？
不同的 UI 需要不同的数据来响应同一个后端数据库服务
如何根据消费者需求从可重用的微服务中转换数据
如何处理多个协议请求？

好吧，这些问题的解决方案可能是 API 网关设计模式。API 网关设计模式不仅解决了上述问题，还解决了许多其他问题。这种微服务设计模式也可以被认为是代理服务，将请求路由到相关的微服务。作为聚合器服务的一种变体，它可以将请求发送到多个服务，并类似地将结果聚合回组合或消费者服务。API Gateway 还充当所有微服务的入口点，并为不同类型的客户端创建细粒度的 API。
借助 API Gateway 设计模式，API 网关可以将协议请求从一种类型转换为另一种类型。同样，它也可以卸载微服务的身份验证/授权责任。
因此，一旦客户端发送请求，这些请求就会传递到 API 网关，该网关充当入口点，将客户端的请求转发到适当的微服务。然后，在负载均衡器的帮助下，处理请求的负载并将请求发送到相应的服务。微服务使用服务发现作为指导来找到它们之间的通信路径。然后微服务通过无状态服务器相互通信，即通过 HTTP 请求/消息总线。

链式或责任链模式

链式或责任链设计模式产生单个输出，该输出是多个链式输出的组合。因此，如果您将三个服务排成一条链，那么，来自客户端的请求首先由服务 A 接收。然后，该服务与下一个服务 B 通信并收集数据。最后，第二个服务与第三个服务通信以生成合并的输出。所有这些服务都使用同步 HTTP 请求或响应进行消息传递。此外，在请求通过所有服务并生成相应的响应之前，客户端不会得到任何输出。所以，总是建议不要做长链，因为客户端会等到链完成
您需要了解的另一个重要方面是，从服务 A 到服务 B 的请求可能看起来与服务 B 到服务 C 不同。同样，从服务 C 到服务 B 的响应可能看起来与服务 B 到服务 A 完全不同。

异步消息设计模式

从上面的模式中，很明显客户端在同步消息中被阻塞或等待很长时间。但是，如果您不希望消费者等待很长时间，那么您可以选择异步消息传递。在这种类型的微服务设计模式中，所有服务都可以相互通信，但它们不必按顺序相互通信。因此，如果考虑 3 个服务：服务 A、服务 B 和服务 C。来自客户端的请求可以直接同时发送到服务 C 和服务 B。这些请求将排在队列中。除此之外，请求还可以发送到服务 A，其响应不必发送到请求所经过的同一服务。

数据库或共享数据模式

对于每个应用程序，都存在大量数据。因此，当我们将应用程序从其单体架构分解为微服务时，非常重要的是要注意每个微服务都有足够的数据量来处理请求。因此，系统可以为每个服务拥有一个数据库，也可以为每个服务拥有一个共享数据库。您可以使用每个服务的数据库和每个服务的共享数据库来解决各种问题。问题可能如下：

数据重复和不一致
不同的服务有不同的存储需求
很少有业务可以查询数据，有多种服务
数据去规范化

好吧，为了解决前三个问题，我认为您可以使用每个服务的数据库，因为它将由微服务 API 本身访问。因此，每个微服务都有自己的数据库 ID，这会阻止系统中的其他服务使用该特定数据库。除此之外，为了解决反规范化问题，您可以为每个服务选择共享数据库，为每个微服务对齐多个数据库。这将帮助您为分解为微服务的单体应用程序收集数据。但是，您必须记住，您必须将这些数据库限制为 2-3 个微服务；否则，扩展这些服务将是一个问题。

事件溯源设计模式

事件源设计模式创建有关应用程序状态更改的事件。此外，这些事件被存储为一系列事件，以帮助开发人员跟踪何时进行了哪些更改。因此，借助此功能，您可以随时调整应用程序状态以应对过去的变化。您还可以查询这些事件以了解任何数据更改，并同时从事件存储中发布这些事件。发布事件后，您可以在表示层上看到应用程序状态的变化。

分支模式

分支微服务设计模式是一种设计模式，您可以在其中同时处理来自两个或多个独立微服务的请求和响应。因此，与链式设计模式不同，请求不是按顺序传递的，而是将请求传递给两个或多个互斥的微服务链。这种设计模式扩展了聚合器设计模式，并提供了从多链或单链产生响应的灵活性。例如，如果您考虑一个电子商务应用程序，那么您可能需要从多个来源检索数据，而这些数据可能是来自各种服务的数据的协作输出。因此，您可以使用分支模式从多个来源检索数据。

命令查询职责分离器 (CQRS) 设计模式

每个微服务设计都有每个服务模型的数据库或每个服务的共享数据库。但是，在每个服务的数据库模型中，我们无法实现查询，因为数据访问仅限于一个数据库。因此，在这种情况下，您可以使用 CQRS 模式。根据这种模式，应用程序将分为两部分：命令和查询。命令部分将处理与 CREATE、UPDATE、DELETE 相关的所有请求，而查询部分将处理物化视图。通过使用上述事件源模式创建的一系列事件来更新物化视图。

断路器模式

顾名思义，断路器设计模式用于在服务不工作时停止请求和响应过程。因此，例如，假设客户端正在发送从多个服务检索数据的请求。但是，由于某些问题，其中一项服务已关闭。现在，您将面临主要两个问题：首先，由于客户端不知道某个特定服务已关闭，因此请求将不断发送到该服务。第二个问题是网络资源枯竭，性能低下，用户体验差。
因此，为避免此类问题，您可以使用断路器设计模式。在此模式的帮助下，客户端将通过代理调用远程服务。该代理基本上将充当电路屏障。因此，当故障数量超过阈值数量时，断路器会在特定时间段内跳闸。然后，所有调用远程服务的尝试都将在此超时时间内失败。一旦该时间段结束，断路器将允许通过有限数量的测试，如果这些请求成功，断路器将恢复正常操作。否则，如果出现故障，则超时周期重新开始。

分解设计模式

微服务是根据开发人员的想法开发的，即创建小型服务，每个服务都有自己的功能。但是，将应用程序分解成小的自治单元必须在逻辑上完成。因此，要将小型或大型应用程序分解为小型服务，您可以使用分解模式。
借助此模式，您可以基于业务能力或基于子域来分解应用程序。例如，如果您考虑一个电子商务应用程序，那么如果您按业务能力进行分解，那么您可以为订单、支付、客户、产品提供单独的服务。
但是，在相同的场景中，如果您通过分解子域来设计应用程序，那么您可以为每个类提供服务。在这里，在这个例子中，如果你把客户看作一个类，那么这个类将用于客户管理，客户支持等。所以，分解，你可以使用整个领域模型的领域驱动设计细分为子域。然后，这些子域中的每一个都有自己的特定模型和范围（有界上下文）。现在，当开发人员设计微服务时，他/她将围绕范围或有界上下文设计这些服务。
尽管这些模式对您来说听起来可行，但它们对于大型单片应用程序并不可行。这是因为识别子域和业务能力对于大型应用程序来说并不是一件容易的事。因此，分解大型单体应用程序的唯一方法是遵循藤蔓模式或扼杀者模式。

扼杀者模式或藤蔓模式

扼杀者模式或藤蔓模式是基于与藤蔓的类比，藤蔓基本上扼杀了它所缠绕的树。因此，当将此模式应用于 Web 应用程序时，每个 URI 调用都会来回调用，并且服务会分解为不同的域。这些域将作为单独的服务托管。
根据扼杀者模式，两个独立的应用程序将并排存在于同一个 URI 空间中，并且在一个实例中将考虑一个域。因此，最终，新的重构应用程序会环绕或扼杀或替换原始应用程序，直到您可以关闭单体应用程序
如果您想查看更多有关人工智能、DevOps、Ethical Hacking 等市场最流行技术的文章，您可以参考 Edureka 的官方网站。

本文 :https://architect.pub/top-microservices-design-patterns-build-your-applications
讨论：知识星球【首席架构师圈】或者加微信小号【ca_cto】或者加QQ群【792862318】
公众号	【jiagoushipro】【超级架构师】精彩图文详解架构方法论，架构实践，技术原理，技术趋势。我们在等你，赶快扫描关注吧。
微信小号	【ca_cea】 50000人社区，讨论：企业架构，云计算，大数据，数据科学，物联网，人工智能，安全，全栈开发，DevOps，数字化.
QQ群	【285069459】深度交流企业架构，业务架构，应用架构，数据架构，技术架构，集成架构，安全架构。以及大数据，云计算，物联网，人工智能等各种新兴技术。加QQ群，有珍贵的报告和干货资料分享。
视频号	【超级架构师】 1分钟快速了解架构相关的基本概念，模型，方法，经验。每天1分钟，架构心中熟。
知识星球	【首席架构师圈】向大咖提问，近距离接触，或者获得私密资料分享。
喜马拉雅	【超级架构师】路上或者车上了解最新黑科技资讯，架构心得。	【智能时刻，架构君和你聊黑科技】
知识星球	认识更多朋友，职场和技术闲聊。	知识星球【职场和技术】
领英	Harry	https://www.linkedin.com/in/architect-harry/
领英群组	领英架构群组	https://www.linkedin.com/groups/14209750/
微博‍‍	【超级架构师】	智能时刻‍
哔哩哔哩	【超级架构师】
抖音	【cea_cio】超级架构师
快手	【cea_cio_cto】超级架构师
小红书	【cea_csa_cto】超级架构师
网站	CIO(首席信息官)	https://cio.ceo
网站	CIO,CTO和CDO	https://cioctocdo.com
网站	架构师实战分享	https://architect.pub
网站	程序员云开发分享	https://pgmr.cloud
网站	首席架构师社区	https://jiagoushi.pro
网站	应用开发和开发平台	https://apaas.dev
网站	开发信息网	https://xinxi.dev
网站	超级架构师	https://jiagou.dev
网站	企业技术培训	https://peixun.dev
网站	程序员宝典	https://pgmr.pub
网站	开发者闲谈	https://blog.developer.chat
网站	CPO宝典	https://cpo.work
网站	首席安全官	https://cso.pub ‍
网站	CIO酷	https://cio.cool
网站	CDO信息	https://cdo.fyi
网站	CXO信息	https://cxo.pub