Microservices 向在不同数据中心运行(多个实例)的其他micro服务发送更新的最佳方法

Microservices 向在不同数据中心运行(多个实例)的其他micro服务发送更新的最佳方法,microservices,production-environment,multiple-instances,Microservices,Production Environment,Multiple Instances,我有3种不同的微服务(例如:A、B、C。它们是基于REST和springboot的)。这3种不同的服务通常在3个不同的数据中心位置上运行,因此每个服务都有不同的实例 试图解决的问题: 我需要在服务A中发送更新(它是一种轮询,检查是否有任何更新的记录),然后通过REST调用将更新的信息发送到服务B和C。基于这些更新,服务B和C自行处理。部署后一次(主要是在云中)。A如何知道哪些B、C实例已启动并正在运行。以便它可以向正在运行的实例发送更新 在从数据库发送更新之前,我们是否需要跟踪正在运行的实例到某

我有3种不同的微服务(例如:A、B、C。它们是基于REST和springboot的)。这3种不同的服务通常在3个不同的数据中心位置上运行,因此每个服务都有不同的实例

试图解决的问题: 我需要在服务A中发送更新(它是一种轮询,检查是否有任何更新的记录),然后通过REST调用将更新的信息发送到服务B和C。基于这些更新,服务B和C自行处理。部署后一次(主要是在云中)。A如何知道哪些B、C实例已启动并正在运行。以便它可以向正在运行的实例发送更新

在从数据库发送更新之前,我们是否需要跟踪正在运行的实例到某个DB表中并查找活动实例?。(或者)只需创建一些基于指示符或序列号的方法,就可以发现A上有一些更新,所以我们需要发送。但在这种情况下,A是否知道所有活动实例都在运行?或者,我们只需要从发送更新,这样一些路由器或负载平衡器或其他东西将负责发送到运行的可用活动实例,而不管存储和查找活动实例


我不太熟悉网络和prod系统的行为及其在云系统中的通信。

试图通过基于REST的同步实现跨服务更新是一个坏主意,因为它在某种意义上是不可扩展的,如果您添加更多需要了解服务a上所做更新的微服务,您将不得不这样做修改发出更改的现有微服务。这实际上带来了风险和额外的维护成本

但是,您可以尝试使用发出指示对服务所做更改的事件。这种方法不需要修改任何现有的微服务(由于pub/sub模式),只需将新的使用者插入到生态系统中现有的更新服务中即可