rabbitmq - rabbitmq 事件驱动微服务

Question

微服务架构和共享通用应用程序数据。

场景是：今天有 17 个微服务用于一些在线社交媒体服务，其中 9 个需要知道谁与谁连接，以便它们的功能正常工作。为了防止每个服务不断向“身份验证”或“连接”微服务请求列表，所有服务都注册以接收每个用户的连接副本并存储在缓存中。

提供数据的机制或获取数据的指令的提议可以是rabbitmq。

但是，每个微服务都是由 k8s 编排的 docker 容器集群，以实现可扩展性。

每个容器都会注册以收听他们感兴趣的交换集合......所以对于“新闻提要”服务，可以说是 5 个连接......

下面是建议设置的图示：

• T1 - 用户 A 接受好友请求
• T2 - 连接服务 (MS1) 在其主数据库中建立连接
• T3 - MS1 发布到 rabbitmq 交换上述事件
• T4 - rabbitmq 交换发送到所有 Q（即所有其他注册的微服务）
• T5 - MS2 集群中的所有节点接收事件并采取行动……他们的行动（在这种情况下）将是更新好友连接的缓存。
• T6 - 用户 A 为其新闻源请求数据，MS2 现在使用其本地缓存查询其数据库

这一切都很好：

• 连接服务不知道也不关心谁得到了数据，只是它应该通过单个 rabbitmq 入口点发送到 1 个交换
• MS2的开发者只需要知道rabbitmq实例的位置
• 所有其他服务的开发人员都是一样的……他们以自己出色的方式处理数据。

1个例外是..有3个MS2实例，因此将是3个数据库写入..如果系统扩展到10个，则将是10个db写入等等。

问题 如何绕过这个问题...如何确保只有 1 个 MS2 实例起作用？

新闻源微服务是否应该使用自己的内部 q 系统来管理来自交易所的数据？是否可以通过负载均衡器路由所有消息，以便只有一个 MS2 实例收到消息？我不想开始手动管理大量队列，因为这会很痛苦并且会破坏交换设计的简单性。

标签： rabbitmqmicroservices

Answer 1

因此，如果 M2 将共享一个队列并使用竞争消费者模式工作，则所有实例都将被消费一次，如果 M2 的所有实例都关闭，则队列会增长，直到它们再次恢复。

M2、M3 和 M4 将分别为 M1 发布的内容创建一个队列。我们将它们命名为 M2_from_M1、M3_from_M1 和 M4_from_M1。它们还将针对 M1 使用的交换器和该消息的路由键创建一个绑定。

现在，M2 的实例将全部从 M2_from_M1 消费，M3 的实例将全部从 M3_from_M1 消费，依此类推。

如果其中任何一个的所有实例都关闭，它的队列将开始填满，但这很好，因为它稍后会被消耗掉。

关于整体架构。首先尝试在 M2 和 M1 之间进行实际调用，pod 之间的访问时间可能非常快，您可能会在 M1 和 M2 中缓存一段时间。最糟糕的结果是您看到来自您不再关注的人的消息，或者您没有从新联系人那里获得消息。