我们计划在我们的微服务架构中同时引入pub-sub和请求-回复通信模型。这两种沟通模式都是需要的。
其中一个解决方案可能是使用RabbitMQ，因为它可以提供这两种模型并提供HA、集群和其他有趣的功能。
RabbitMQ请求-应答模型需要使用队列，用于输入和输出消息。只有一个服务可以从输入队列中读取，这增加了耦合性。
对于在同一系统中同时使用请求-回复和发布-子通信模型，是否有其他推荐的解决方案？服务网格可能是更好的选择吗？
node.js、python和。Net CORE。
感谢您的帮助
有多个pub-sub和请求-回复支持HA通信模型：
1.卡夫卡
Kafka在很大程度上依赖于文件系统来存储和缓存消息。所有数据都会立即写入文件系统上的持久日志，而不必刷新到磁盘。实际上，这只是意味着它被转移到内核的页面缓存中。
卡夫卡的设计考虑到了失败。在某个时间点，web通信或存储资源会出现故障。当代理脱机时，其中一个副本将成为分区的新领导者。当代理重新联机时，它没有前导分区。卡夫卡会跟踪哪台机器被配置为领导者。一旦原始代理备份并处于良好状态，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.ZeroMQ
ZeroMQ(也称为websphere MQ、0MQ或zmq)看起来像一个可嵌入的网络库，但其作用类似于一个并发框架。它为您提供了在各种传输(如进程内、进程间、TCP和多播)上承载原子消息的套接字。您可以使用扇出、pub-sub、任务分发和请求回复等模式将套接字连接到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可以部署在分布式和联合配置中，以满足高规模、高可用性的要求。
-
我更喜欢
request-reply模式的RESTapi。这特别适用于您控制通信机制的内部微服务。我不理解你关于为什么它们不可扩展的评论，如果你正确地定义了它们，并且你可以根据需求扩展和减少服务的实例数量。无论是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来实现