正如Lagom设计哲学中所讨论的，服务应该是独立的和自治的。这些服务通过网络发送消息来相互通信(服务间)。为了实现性能和弹性，您通常会在不同的节点上运行同一个服务的多个实例，而且这样的服务内部通信也会通过网络进行。此外，第三方或遗留系统也可能为您的微服务系统使用或提供信息。
以下主题更详细地讨论了这些通信路径:

• 微服务系统中的通信

• 与微服务系统外各方的通信

  微服务系统中的通信

  虽然在原则上是相似的，但服务间和服务内的通信有非常不同的需求，并且Lagom提供了多种实现选项。服务间通信必须使用松耦合协议和消息格式来保持隔离和自治。协调不同服务之间的更改可能很困难，而且成本很高。你可以利用以下方法在你的系统中实现这一点:

• 服务调用，无论是同步的还是异步的(流)，都允许服务使用发布的api和标准协议(HTTP和WebSockets)相互通信。

• 将消息发布到代理，比如Apache Kafka，可以进一步解耦通信。Lagom的Message Broker API提供了“至少一次”语义。如果新实例开始发布信息，则将其消息添加到以前发出的事件中。如果一个新实例订阅了一个主题，它们将接收过去、现在和将来的所有事件(只要它们订阅了)。

单个服务的节点(统称为集群)需要较少的解耦。它们共享相同的代码，并作为一个集合由单个团队或个人共同管理。由于这个原因，服务内部通信可以利用开销更少、性能更好的机制。例如:

• 许多Lagom组件内部使用Akka remoting，您可以直接在服务中使用它。
• 分布式发布-订阅可用于节点之间低延迟、最多一次的消息传递。限制包括:
  • 网络中断可能导致消息丢失
  • 当新实例启动、加入集群并订阅时，它将不会接收在订阅之前发送的消息。
• 数据库和其他持久存储可以看作是服务节点通信的另一种方式。对于使用持久化实体的微服务，Lagom鼓励事件流，这也利用了异步通信，并通过事件日志提供了保证。

此图说明了分布在三个服务器上的Lagom系统中的每种类型的服务间和服务内通信。在本例中，Order服务发布一个或多个Kafka主题，而User服务订阅主题消费信息。用户服务使用Akka remoting与其他用户服务实例(集群成员)通信。Shipping 服务和User服务通过事件流服务调用来交换信息。

与微服务系统外各方的通信

Lagom鼓励异步通信的使用，但在必要的情况下不会阻止同步通信的使用。第三方可以从发布到Broker API的Lagom服务异步获取数据，并有至少一次的保证。Lagom服务还公开了一个API，供第三方同步交换数据。这通常指HTTP。 Lagom服务API也支持通过websockets将数据流传输到外部客户端。有关更多信息，请参阅ServiceDescriptors。
与外部世界的交互的对象可能意味着任何通过互联网使用服务的客户端，如浏览器、移动应用程序或物联网设备。在使用标准HTTP或WebSockets时，这类客户端通常不直接与单个服务通信。通常，网络边界充当边界，一个控制良好的通信点充当外部世界和内部世界之间的中介。在Lagom中，这个通信点是一个服务网关。把你的微服务系统想象成一个中世纪的城镇，周围有一堵墙，只有一扇门提供进出的唯一通道。墙内的通信是自由和直接的，但与外部世界的通信必须通过服务网关，如下图所示。