微服务架构促进了作为独立，细粒度和自治服务套件的软件应用程序的构建。 因此，当我们构建真实的业务用例时，组成应用程序的微服务必须相互通信。 随着细粒度服务的激增，集成微服务和建立服务间通信已成为实现微服务体系结构中最具挑战性的任务之一。
为了了解微服务架构的挑战，让我们首先看一下最近的情况。 在面向服务的体系结构（SOA）和Web服务的前微服务时代，我们将使用中央企业服务总线（ESB）架构，在其中实现了所有服务组合和集成。
例如，如图1所示，所有服务都与ESB集成在一起，并且选定的业务功能通过API管理层向消费者公开。 ESB提供了集成不同的API，数据和系统所需的所有功能。
图1：使用企业服务总线的集中式集成架构。
但是，当我们进入微服务体系结构时，拥有具有大量业务逻辑的单片集成层将使实现微服务的基本概念（例如自治和面向狭窄的业务功能）的实现变得非常困难。 因此，将中央ESB用作集成总线是不切实际的。
取而代之的是，通过微服务架构，微服务使用智能端点和哑管道样式进行集成，所有智能都驻留在端点上，这些端点通过哑消息基础结构互连。 如图2所示，我们可以为已经确定的业务功能设计微服务，并且它们必须相互通信才能实现各种业务用例。
图2：微服务架构的特点是智能端点和哑管道。
尽管拆分一个单一的应用程序和中央ESB并将这些功能分流到每个服务听起来很简单，但我们仍然面临许多挑战。 因此，了解常见的微服务集成模式并选择合适的技术和框架来实现它们非常重要。 让我们看一下这些关键的微服务集成模式中的两个，即主动组合和被动组合。
微服务架构的主动组合模式
在主动组合模式中，微服务使用请求-响应样式通信进行通信，其中给定的微服务可以使用同步消息传递协议（例如REST / HTTP，gRPC远程过程调用和GraphQL API查询语言）来调用一个或多个其他微服务。 。 图3说明了这样的微服务集成方案，其中基于不同的交互类型来组织服务。
在主动组合微服务实现中，我们可以标识核心服务或原子服务。 这些是细粒度的自包含服务，没有或只有很少的外部服务依赖性，主要由业务逻辑组成，很少或没有网络通信逻辑。
图3：在活动组合模式中，微服务使用同步消息传递协议进行通信。
原子微服务通常过于细粒度，因此通常无法直接映射到业务功能。 因此，特定的业务功能可能需要包含多个原子服务或核心服务。 中间层包括此类复合或集成微服务。 这些服务通常必须支持很大一部分ESB功能，例如路由，转换，编排，弹性和稳定性。
相比之下， 组合或集成服务相对于原子服务而言是粗粒度的。 它们彼此独立，并包含业务逻辑（例如，路由，要调用的服务以及如何进行数据类型映射）和网络通信逻辑（例如，通过各种协议和弹性行为（如断路器）进行服务间通信）。
您将使用API服务和/或边缘服务将一组选定的组合服务（甚至某些原子服务）公开为托管API。 这些是特殊类型的组合服务，它们应用基本路由功能，API版本，API安全模式，限制和货币化，以及创建API组合。 如图3所示，这些API由控制平面或API管理层集中管理。
主动组合的好处在于，您可以选择各种实现技术来实现核心，复合和API服务。 但是，这种模式的缺点是服务间耦合和依赖性。 一项给定的服务可能取决于一个或多个下游服务。 因此，活动组合仅适用于某些以交互请求-响应方式为关键要求的微服务交互。
微服务架构的反应式组合模式
借助反应式组合，服务可以使用事件驱动的异步消息进行通信并创建组合。 我们可以使用以下两种技术之一来实现反应式组合：针对多个使用者的发布-订阅消息传递或针对单个使用者的基于队列的消息传递。
如图4所示，在反应式组合模式中，微服务不会直接相互通信； 而是它们与集中事件或消息总线之间收发消息。 给定服务的业务逻辑以这样的方式实现：在事件到达时，应用并执行服务业务逻辑。 服务业务逻辑还可以将新事件提交到事件总线。 该总线充当愚蠢的消息传递基础结构，所有业务逻辑都在生产者或消费者级别实现。
图4：在反应式组合模式中，微服务通过事件总线间接通信。
反应式组合中常用的消息传递技术是Apache Kafka消息传递协议，NATS云原生消息传递协议以及在诸如RabbitMQ，ActiveMQ和Artemis之类的消息传递软件中发现的AMQP协议。
反应性组合消除了服务之间的紧密耦合，并使服务更加自治。 反应性组合通常用于其他微服务模式，例如事件源 ，命令和查询责任隔离（ CQRS ）等。
现在让我们看一下这些模式如何应用于现实的微服务实现中。
实际微服务实现中的主动和被动模式
在大多数实际的微服务实现中，我们必须使用主动和被动组合的混合体。 如图5所示，我们可以对大多数外部服务使用基于同步消息传递的组合。 此类功能通常通过由多个API服务组成的API网关层公开给使用者，并且这些功能由API控制平面集中管理。
通常，API服务与使用者之间的通信利用RESTful消息传递或GraphQL API查询语言。 可以使用开源技术（例如WSO2 API Manager，Kong和Gluu）或商业替代方案（例如Apigee，IBM，Software AG和Tibco）来实现API服务和管理层。
图5：实际的微服务实现通常同时使用主动和被动组合。
主动和被动合成样式均需要丰富的集成框架或编程语言，以满足各种集成和合成需求。 例如，这些可能包括消息转换，与不同系统和服务的连接器，同步或异步事件驱动的消息传递，或对各种不同消息交换模式的支持。 有一些微服务友好的开源集成框架，包括Camel-K，WSO2 Micro Integrator和Micronaut.io。 某些编程语言（例如Ballerina.io）和语言框架（例如Spring Boot）也支持这些功能。
服务之间的内部同步通信可以使用gRPC作为通信技术，而不是使用传统的RESTful消息传递，这是由于其性能，类型安全性和合同驱动的性质。
异步事件驱动的服务交互可以利用事件总线技术，例如利用Apache Kafka，NATS或AMQP协议的软件。 异步服务应具有可以使用或产生消息并与事件总线交换消息的集成逻辑。 可以使用本文中讨论的大多数集成技术，但是大多数标准编程语言的库中也经常支持这些相同的消息传递标准。 使用消息传递基础结构时，重要的是不要将任何业务逻辑与事件总线隔离开。
在本文中，我们讨论了纯微服务实现的两种主要方法。 但是，在大多数现实情况下，基于微服务的应用程序必须与企业中的单片系统集成。 因此，您可能希望在微服务和整体子系统之间构建一个桥接层，通常称为反腐败层。 在大多数实际使用案例中，微服务和单片子系统并排共存，而反腐败层允许两者无缝集成，而无需更改任何一个系统。 现有的集成技术（例如ESB或集成总线）可用于实现反腐败层。
您可以在与同事Prabath Siriwardena合着的《 企业微服务：设计，开发和部署 》一书中找到此处讨论的微服务模式的更多详细信息和示例用例。
Kasun Indrasiri是 WSO2 的集成架构主管 。 他是WSO2体系结构团队的重要成员，该团队推动WSO2集成平台的开发工作。
-
新技术论坛提供了一个以前所未有的深度和广度探索和讨论新兴企业技术的场所。 选择是主观的，是基于我们对InfoWorld读者认为最重要和最感兴趣的技术的选择。 InfoWorld不接受发布的营销担保，并保留编辑所有贡献内容的权利。 将所有查询发送到 newtechforum@infoworld.com 。
这个故事“基本的微服务集成模式”最初由InfoWorld发布 。
From: https://www.idginsiderpro.com/article/3343068/essential-microservices-integration-patterns.html
474
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
