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 次数据库写入等。

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

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

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 中缓存一段时间。最糟糕的结果是您看到不再关注的人的新闻，或者您没有收到新联系人的新闻。