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将共享一个队列并使用竞争性消费者模式工作，则所有实例都将消耗一次所有消息，并且如果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中都缓存了一段时间。最糟糕的结果是，您看到不再关注的人的新闻，或者您没有从新联系人那里获得新闻。