13、深入解析微服务消息模式

深入解析微服务消息模式

1. 微服务消息路由基础

通过摒弃单个微服务具有固定身份的观念，并使用模式匹配来定义消息到微服务的映射，可实现消息的神奇路由。我们可以通过列出每个微服务识别和发出的模式，来全面描述系统的设计。

消息的实现和物理传输是任何系统（尤其是大型系统）都必须解决的实际工程问题，但在编写微服务时，应将传输视为独立的考虑因素。这意味着我们可以自由使用从 HTTP 到消息队列等任何传输机制，并且可以随时更改传输机制。同时，我们还能自由更改消息的分发方式，消息可以参与请求/响应模式、发布/订阅模式、参与者模式或其他任何变体，而无需考虑微服务的情况。微服务既不知道也不关心还有谁与消息进行交互。

2. 消息交互的两个关键方面

在讨论消息模式之前，需要明确消息交互的两个关键方面：
- 同步/异步（实线/虚线） ：消息是否期望响应。
- 观察/消费（空心/实心箭头） ：消息是被观察（其他人也能看到）还是被消费（其他人看不到）。

我们将在服务数量不断增加的背景下考虑这些交互。除非明确说明，我们假设系统是可扩展的，每个微服务以多个实例的形式运行，并且部署基础设施或微服务框架提供了负载均衡等功能。

为了对模式进行正式分类，可以从消息模式的数量和微服务的数量（而非实例数量）的角度来考虑。最简单的情况是，两个微服务之间存在一种特定模式的单个消息，这就是 1/2 模式，用 m/n 的形式表示，其中 m 是消息模式的数量，n 是微服务的数量。

3. 核心模式：一个消息/两个服务

3.1 请求/