首先，在microservices体系结构中，您应该追求独立的数据库，或者至少是独立的模式。正如评论中指出的，跨微服务共享数据将是一种微服务反模式。
您可以考虑以下几种方法：
每个微服务都会更新自己的数据库，并通知其他微服务已经进行了更新。这使每个微服务都能够调整自己的数据库（最终保持一致）。
如果需要协调，更好的方法是创建第四个协调微服务，其任务是协调其他三个微服务。研究传奇模式。如果您需要事务协调（即所有服务都必须更新其数据库或不更新任何数据库），这一点尤其有用。如果您认为您需要事务性协调，请非常仔细地再考虑一次—在许多（大多数？）情况下，最终一致性就足够了。如果你真的需要交易，那么你应该研究传奇和路由滑动模式，其中包括在发生故障时的补偿。
如果您需要三个独立数据库的统一视图，那么可以考虑另一个microservice，它的任务是创建您需要的视图（投影）。让微服务做他们擅长的一件事，而且只有当你开始在微服务中混用关注点时——好吧，这也是一种反模式。
启用微服务通信的一个好方法是使用消息总线，如rabbitmq或azure服务总线，但是还有许多其他选项，包括spring引导。
考虑到您的问题，在开始一个microservices项目之前，我会花更多的时间研究microservice体系结构和适合您项目的工具。为了减轻微服务的复杂性，已经做了很多工作，您最好研究最适合您的工具集。尽管如此，它会增加相当多的复杂性，但如果做得好，随着项目的发展，它可以支付股息。

对于独立的数据库，您可能需要google saga架构模式。这有助于管理不同微服务之间的事务帐户，每个微服务都有各自的数据库。在这里描述它需要很大的篇幅，所以我认为我能给您的最好建议是让您参考本文saga模式的每服务数据库体系结构

您可以使用rabbitmq在微服务之间进行消息交换。rabbitmq将保存数据库更新的所有信息。因此，即使一个微服务在数据库更新之前终止，那么当微服务再次启动时，它也会查看rabbitmq并知道它错过了什么。这样就可以在故障恢复后进行数据库更新。