分布式系统开发实战：微服务架构，微服务与通信

微服务与通信

在微服务架构的世界中，我们通过一系列微服务来构建一个完整的系统。系统中的每个微服务都符合以下特征。

·松散耦合。

·可维护和可测试。

·可以独立部署。

微服务架构中的每个服务都解决了应用中的业务问题，或至少支持一个。一个团队对应用中的一个或多个服务负责。

使用微服务架构可以带来以下好处。

·它们通常更容易构建和维护。

·服务是围绕业务问题组织的。

·它们可以提高生产力和速度。

·它们鼓励自主、独立的团队。

这些好处是微服务越来越受欢迎的一个重要原因。但有微服务的架构并不是百分之百完美的架构，微服务中的任何技术选型都需要切实考虑自身架构的特定，其中一个重要的方面就是微服务之间的通信。

该体系结构的目标是创建松散耦合的服务，并且通信在实现这一目标中起着关键作用。在本节，我们将重点关注在微服务架构中进行通信的3种方式，每一种都有其自己的利弊和权衡。

HTTP通信

选择服务如何相互通信时，最直接的方式往往是HTTP。事实上，我们可以提出一个案例，即所有通信渠道都来自这个渠道。但是除此之外，服务之间的HTTP调用是服务到服务通信的可行选择。

HTTP通信方式在前面几章已经做了非常充分的介绍，“大”Web服务及RESTful Web服务都是基于HTTP通信。

这种方法的优点是可以使服务彼此隔离，并且耦合松散。缺点是服务之间调用是同步的，要想及时获取服务器的状态，只能通过轮询的方式，直到请求完成。这也引入了客户端的复杂性，因为必须检查请求的进度。

消息通信

另一种通信模式是基于消息的通信。

与HTTP通信不同，消息通信所涉及的服务不直接相互通信。服务将消息推送到其他服务订阅的消息代理。这消除了许多与HTTP通信相关的复杂性。

它不需要服务知道该如何相互交流，它消除了直接相互调用的服务需求。所有服务都知道消息代理，并且它们将消息推送到该代理。其他服务可以订阅代理中自己关心的消息。

在第7章中，已经详细介绍了面向消息的分布式架构及消息中间件。

 事件驱动的通信

最后一种模式是事件驱动模式。这是另一种异步方法，它看起来完全消除了服务之间的耦合。

与消息传递模式不同，事件驱动方法不需要服务必须知道公共消息结构。服务之间的通信通过各个服务产生的事件进行。

此处仍然需要消息代理，因为各个服务会将其事件写入其中。但是与消息方法不同，消费服务不需要知道事件的细节，它们对事件的发生做出反应，而不是产生会或可能不会传递的信息。在形式上，这通常被称为“仅事件驱动的通信”。

当使用异步事件驱动通信时，一个微服务领域模型发生更新时，会发布一个集成事件，然后另外一个微服务可能需要关注这个事件，比如在一个在线购物网站系统中，当产品分类微服务发生价格变动的时候，另外的微服务需要订阅这个事件，这样就可以以异步的方式来接收这个事件。然后当事件触发的时候，订阅端就可以更新自己的领域模型，从而集成发送端的事件。事件总线（Event Bus）可以设计为一个抽象类或接口，集成API订阅或取消订阅事件和发布事件。事件总线还可以有一个或多个基于任何进程间消息传递代理的实现，如一个消息队列或服务总线支持异步通信和发布/订阅模型。

如果集成事件驱动达成了最终一致性，那么用户应该清楚这种行为，客户端用户及其业务必须显式地拥抱最终一致性并且意识到在许多情况下这种业务没有任何问题。

你可以跨越多个微服务来集成事件驱动，这些服务之间拥有最终一致性。一个最终一致性的“事务”可能是由多个分布式的事件操作组成的一个集合。在每一个事件中，相关的微服务都在更新自己的领域实体并且发布另外一个需要集成的事件到事件总线中。

很重要的一点是，可能需要多个微服务订阅一个事件。因此，可以使用基于事件驱动的发布/订阅消息模式的消息通信，如图9-5所示。这种发布/订阅的机制不是微服务独有的。它类似于DDD中边界上下文之间的通信方式，或者类似于CQRS架构中的从写库更新数据到读库的这种模式。它最终的目标是在整个分布式系统多个数据源之间保持最终的一致性。

图9-5 事件驱动的通信