Architecture 具有共享数据库的微服务

我已经建立了两个微服务，它们都具有对共享数据库的读写访问权限。一项服务创建/更新用户详细信息。另一个服务直接从数据库读取用户数据并生成报告。现在的问题是，如果第二个微服务出于某种原因必须更新某些用户数据，我应该使用第一个微服务更新用户数据，还是直接从第二个微服务更新数据库中的用户数据，因为它已经具有对共享数据库的写访问权限。这种用例有最佳实践吗？

共享数据库模式被认为是一种反模式，因为您的微服务相互交错，两者都依赖于您的单个数据库

通过将api放在控制流程的服务之上，您可以让其他服务通过其端点收集信息。这会给你更好的隔离

---

基本上，这将解决您的问题。

如果您有两个微服务需要读写相同的数据来实现其目标，问题不在于您使用什么技术或技术（共享数据库连接或公开REST api），而在于为什么会发生这种情况

在共享数据之前，请考虑以下两个选项：

为什么两个独立的微服务放在首位？如果它们读取和写入相同的数据，那么它们可能正在履行相同的职责，它们应该是一个单一的微服务，而不是两个

数据是服务于单个责任还是多个责任？如果您对数据/数据库进行建模，使其能够履行两项职责，那么您不仅需要两个微服务，还需要两个数据库。我不知道您的用例，所以很难说，但例如，如果您将产品价格和产品描述存储在同一个表中，定价和目录微服务都将共享数据库，而实际上，它们只需要共享ProductId

另一种可能性是，您需要将写模型与读模型分开。在这种情况下，您可以让一个微服务控制导致模型演化（写入）的业务逻辑，而另一个微服务将存储为读取而优化的模型的“副本”。这种模式（CQRS）有几个优点：

您可以使用与写入管道不同的方式优化和扩展读取管道

如果需要，读模型可以输入来自多个写模型的数据（想象一下按名称、类别、价格、评级等搜索和排序产品）

---

这一主张确实需要引用。既然可以直接使用db（基本上可以充当api），为什么还要构建api？为什么错过交易？用传统编程语言编写的api可能会像表/视图/存储过程一样发生变化。我希望看到确凿的证据表明，与共享数据库相比，使用api建立多个数据库（具有高可用性和它所需要的所有其他功能）是一种更好的方法，而不仅仅是关于分离关注点的意见。@JanSommer我稍后将发送一些参考资料-您可以自己决定是否信任源。给你一个简单的提示：1）总是有例外，2）在云中为ms设置数据库只是一个简单的表-不是一个麻烦3）一些分布式数据库引擎，虽然从技术上讲，单个数据库不被认为是共享数据库模式，4）事务、触发器、SP在使用合适的ORM时不会丢失，5）访问数据库的支持不如典型（web）API 6）共享数据库模式不能扩展到更多服务；零钱多。对不起，空间不足。我稍后会更新答案，因为这只是介绍。