8、微服务架构：定义与通信

微服务架构：定义与通信

1. 定义应用的微服务架构

在微服务架构中，不同服务之间的协作至关重要。例如，当消费者下单时，订单服务在验证消费者信用卡后，需触发厨房服务创建订单票。若餐厅通过厨房服务拒绝订单，订单服务要取消该订单，计费服务需给客户退款。

多个领域模型不仅带来技术挑战，还影响用户体验的实现。应用需在用户体验（自身领域模型）和各服务的领域模型之间进行转换。以FTGO应用为例，消费者看到的订单状态信息来自多个服务。这种转换通常由API网关处理。

接下来，我们将探讨如何定义服务的API。

1.1 定义服务API

我们已有系统操作列表和潜在服务列表，下一步是定义每个服务的API，包括操作和事件。服务API操作存在的原因主要有两个：一些操作对应系统操作，由外部客户端或其他服务调用；另一些操作用于支持服务间的协作，仅由其他服务调用。

服务发布事件主要是为了与其他服务协作。事件可用于实现sagas以维护服务间的数据一致性，还可用于更新CQRS视图以支持高效查询，也能通知外部客户端，如通过WebSockets将事件发送到浏览器。

定义服务API的起点是将每个系统操作映射到一个服务，然后判断服务实现系统操作时是否需要与其他服务协作，若需要，确定其他服务需提供的API。

• 将系统操作分配给服务
  首先要确定请求的初始入口服务。很多系统操作能清晰地映射到一个服务，但有时映射并不明显。例如， noteUpdatedLocation() 操作更新快递员位置，从与快递员相关角度看，该操作应分配给快递员服务；但从