当一个服务需要另一个服务拥有的数据时,有两种主要策略来获取所需的数据:

    1. 服务可以向拥有它的服务请求数据,并等待数据发送回它。这是一种同步通信模式。
    2. 系统的架构可以使服务拥有但其他服务需要的数据发布到一个基础设施组件,该组件在预定义的时间内存储数据。这个附加组件允许发布和消费在不同的时间发生,有效地分离服务,从而使服务能够异步通信。

    这种微服务之间同步通信的唯一依赖是一种不太好的架构风格。微服务体系结构有许多可移动的部分,这意味着有更多的失败机会。同步一词的字面意思是“同时发生”,同步通信意味着发送方和接收方必须同时运行。这意味着在失败面前,同步通信也会失败。如果消息丢失,这可能会导致一致性问题,并可能导致系统脆弱,其中一个组件的故障会导致整个系统的故障。
    解决方案是避免同步通信,将系统设计为异步通信。正如前面所暗示的,可以使用基础设施组件来支持服务异步通信。这个组件通常被称为消息代理。可以用作消息代理的各种技术已经存在,例如Google Cloud Pub/Sub, Kafka, RabbitMQ
    Lagom允许服务轻松地进行同步和异步通信。这两种通信策略都有各自的用途,但您应该尽可能使用异步通信来构建微服务系统。为了帮助您实现这一点,Lagom提供了一个Message Broker API,它对特定的Message Broker技术进行抽象,并使服务异步共享数据变得非常简单。目前,Lagom只支持使用Kafka的Message Broker API的实现,但将来可能会提供其他实现。