rabbitmq事件驱动的微服务

Question

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

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

关于传递数据的机制或获取数据的指令的建议可以是rabbitmq。

但是，每个微服务都是由k8精心安排以实现可伸缩性的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系统交付，以管理来自交易所的数据？是否可以通过负载平衡器路由所有消息，以便仅1个MS2实例获得一条消息？我不想开始手动管理很多队列，因为这将很痛苦，并且会破坏交换设计的简单性。

Answer 1

因此，如果M2将share队列并使用competing Consumer模式工作的所有实例，则每条消息都被消耗一次，如果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中都缓存了一段时间。最糟糕的结果是，您看到不再关注的人的新闻，或者您没有从新的联系人那里获得新闻。