使用 request-reply 和 pub-sub 进行微服务通信

Posted 2023-02-16

【中文标题】使用 request-reply 和 pub-sub 进行微服务通信

【英文标题】：Using both, request-reply and pub-sub for microservices communication

【发布时间】：2020-07-23 04:44:58

【问题描述】：

我们计划将 pub-sub 和 request-reply 通信模型引入我们的 micriservices 架构。两种通信模型都需要。

其中一个解决方案可能是使用 RabbitMQ，因为它可以提供两种模型并提供 HA、集群和其他有趣的功能。

RabbitMQ 请求-回复模型需要使用队列，用于输入和输出消息。只有一个服务可以从输入队列中读取数据，这增加了耦合度。

对于在同一系统中同时使用请求-回复和发布-订阅通信模型，还有其他推荐的解决方案吗？ 服务网格会是更好的选择吗？

需要node.js、python和.净核心。

感谢您的帮助

【问题讨论】：

你为什么不让你的mircoservice为request-reply公开一个rest API并使用RabbitMQ作为pub-sub？

RabbitMQ 可以提供负载均衡，开箱即用的高可用性。它还可以处理网络错误、重新连接等。 HTTP/REST 更容易调试，但实现冗余/ha 支持需要做很多工作。

【参考方案1】：

有多种 pub-sub 和 request-reply 支持 HA 通信模型：

1。卡夫卡

Kafka 严重依赖文件系统来存储和缓存消息。所有数据都会立即写入文件系统上的持久日志，而不必刷新到磁盘。实际上这只是意味着它被转移到内核的页面缓存中。

Kafka 的设计考虑到了失败。在某个时间点，Web 通信或存储资源出现故障。当代理离线时，其中一个副本将成为分区的新领导者。当代理重新上线时，它没有领导分区。 Kafka 会跟踪哪台机器被配置为领导者。一旦原始代理备份并处于良好状态，Kafka 就会恢复它在此期间丢失的信息，并再次使其成为分区领导者。

见：

https://kafka.apache.org/ https://docs.cloudera.com/documentation/kafka/latest/topics/kafka_ha.html https://docs.confluent.io/4.1.2/installation/docker/docs/tutorials/clustered-deployment.html

2。 Redis

Redis 是一个开源（BSD 许可）的内存数据结构存储，用作数据库、缓存和消息代理。它支持数据结构，例如字符串、散列、列表、集合、具有范围查询的排序集合、位图、超日志、具有半径查询和流的地理空间索引。 Redis 具有内置复制、Lua 脚本、LRU 驱逐、事务和不同级别的磁盘持久性，并通过 Redis Sentinel 和 Redis Cluster 自动分区提供高可用性。

见：

https://redis.io/ https://redislabs.com/redis-enterprise/technology/highly-available-redis/ https://redis.io/topics/sentinel

3。零MQ

ZeroMQ（也称为 ØMQ、0MQ 或 zmq）看起来像一个可嵌入的网络库，但其行为却像一个并发框架。它为您提供跨各种传输（如进程内、进程间、TCP 和多播）传输原子消息的套接字。您可以使用扇出、发布-订阅、任务分发和请求-回复等模式连接 N 对 N 套接字。它的速度足以成为集群产品的结构。它的异步 I/O 模型为您提供可扩展的多核应用程序，构建为异步消息处理任务。它有许多语言 API，可在大多数操作系统上运行。

见：

https://zeromq.org/ http://zguide.zeromq.org/pdf-c:chapter3 http://zguide.zeromq.org/pdf-c:chapter4

4。 RabbitMQ

RabbitMQ 是轻量级的，易于在本地和云端部署。它支持多种消息传递协议。 RabbitMQ 可以部署在分布式和联合配置中，以满足大规模、高可用性的要求。

【参考方案2】：

我的偏好是为request-reply 模式使用REST api。这特别适用于您控制通信机制的内部微服务。如果您正确定义它们并且您可以根据需求横向扩展和缩减服务的实例数量，我不理解您关于为什么它们不可扩展的评论。无论是Kafka、RabbitMQ 还是任何其他代理，我认为它们不是为request-reply 开发的主要用例。并且不要忘记，无论您使用什么代理，如果它是 REST 中的 A->B->C，它将是 A->broker->B->broker->C->broker->A，并且代理需要进行内部管理。

那么对于 pub-sub，我会使用Kafka，因为它是一个统一的模型，可以支持 pub-sub 以及点对点。

但是，如果您仍想使用代理进行请求-回复，我会检查 Kafka，因为它可以通过分区进行大规模扩展，并且使用它构建了许多接近真实的流应用程序。所以它可能接近request-reply 模式的最小延迟要求。但是我希望在此之上有一个框架来关联请求和回复。所以我会考虑使用 Spring Kafka 来实现这一目标