多主题消息队列

我对微服务的体系结构有一个相当理论上的问题。多主题消息队列

假设我们有两个通过RabbitMQ彼此交互的微服务A和B。当A有问题时，它会向queue_1发送消息，并通过queue_2接收来自B的答复（因此通信可以保持异步）。

  ------------ 
     ---> queue_1 ---> 
    A  ------------  B 
      ------------ 
     <--- queue_2  <--- 
      ------------

现在我明白了，我们将至少有4种不同的可能由A问到的问题。我的问题是什么是最好的配置方式？

可以为每种问题创建一个单独的队列对（所以它们不是混合的，它更容易确定，期望得到什么样的答案）？

或者它被认为不是非常优化的，最好为所有消息创建单个通道并在微服务中路由它们？

我会感谢有关此主题的任何种类的链接和信息。

来源

2017-08-28 user2957954

没有简单的答案;建筑师的工作是彻底分析真实场景并确定合适的结构。

假设请求类型是W，X，Y和Z.为了简单起见，让我们假设每个队列有一个消费者。如果W和X快速处理，而Y和Z是漫长的操作，那么在单个队列中拥有所有内容意味着一旦在队列顶部有Y或Z，那么任何排队的W和X将花费很多的时间排队等待消费者完成冗长的过程。在这种情况下，最好有一个Ws和Xs排队，另一个排队Ys和Zs。

想想现实生活中的排队服务，可以说超市。你有收银台的正常通道，并且你有那些“多达10个产品”的快车道。

要考虑的另一件事是：你是否想要对每种请求类型应用不同的策略和保证？例如，可能是Ws是每隔一段时间到达的“文档消息”，不能丢失（需要保存到磁盘），并且必须处理，而不管它们何时被分派（不包括“ ），而X是始终到达的“事件消息”，必须快速处理，并且仅在几秒钟内有效（具有短的TTL）。这意味着他们需要不同的队列。

也许Ys和Zs有不同的优先级：也许你必须尽快处理Zs，即使有待处理的Ys。这将再次要求不同的队列。

如果所有请求类型的重要性都是相同的，那么为简单起见，也许单个队列会更好。

对响应队列进行相同的讨论。您可以有四个不同的请求队列和一个响应队列。或者四个响应队列，或两个...（它不必是对称的）。

还有其他问题需要考虑，如安全性，可伸缩性和性能。

实际的路由并不是真正的挑战，并且确定哪个处理程序应该处理每个消息类型可以通过使用消息头很容易地帮助（您不必检查实际的消息体来确定它的类型），这是真的就像拥有不同的队列一样简单。

来源

2017-08-30 23:14:49

多主题消息队列

回答

相关问题