8、微服务集成实践：Kafka 消息通信与顺序处理

微服务集成实践：Kafka 消息通信与顺序处理

1. 微服务扩展与消息通信挑战

在典型的基于 HTTP 的传输中，将请求路由到不同类型的微服务并将负载分配到同一类型的多个微服务实例是比较直接的。但在基于消息的基础设施上，这并非易事。消息通信本质上是异步的，且消息通道是单向的，这给开发者带来了一系列复杂性，尤其是在异步事件通道上模拟同步风格的微服务间通信时。

1.1 发布者 - 订阅者组合

每个发布者微服务可以有自己的返回地址，这样响应消息就能被定向到相应的发送者。当扩展微服务时，如果需要在异步通道上发送同步风格的通信，会引入更多复杂性。若有同一微服务的多个实例，必须确保回复被发送到正确的微服务实例。Spring Kafka 文档建议每个消费者使用唯一的回复主题，以避免回复消息混淆。

1.2 Kafka 分区的利用

更好的解决方案是利用 Kafka 提供的主题分区功能。每个消费者可以使用额外的 KafkaHeaders.REPLY_PARTITION 头值，该值随请求一起发送，是一个四字节字段，包含分区整数的大端表示。Kafka 分区是 Kafka 中的主要并发机制，一个主题可分为一个或多个分区，使生产者和消费者的负载能够扩展。消费者均匀分布在分区上，通过增加消费者和分区数量，可线性扩展消费者负载，可将此功能用于回复地址。

2. 微服务顺序处理示例

2.1 示例概述

此示例展示了如何调整一组微服务。消费者和提供者微服务通过消息通道进行通信，提供者微服务将实体存储在内存数据库中。浏览器向第一个（消费者）微服务发送请求时使用异步 HTTP。与