Spring boot 作为微服务的持久层？

我是微服务体系结构的初学者，我在很多博客上读到，在微服务体系结构中，每个微服务都必须有自己的数据库。就我而言，它可能会很贵

我的问题是，是否有可能将持久层本身作为微服务？它将具有允许其他微服务对数据库进行读/写访问的功能。

---

感谢

让所有微服务访问同一个数据库将导致松散的内聚和强耦合

尝试看看是否可以为每个微服务定义单独的模式，以便确保微服务不引用其他微服务的表

---

这样，将来，当您的基础架构成本问题消失时，您可以无缝地为每个服务移动到单独的数据库

首先要回答您的问题，让我们了解：

每个微服务都必须有自己的数据库。在我的 如果是这样的话，它可能会很贵

是的，据说每个微服务都应该有自己的数据库

他们的意思是，每个微服务的表/集合应该是独立的（您可以使用单个可扩展的数据库实例），一个微服务只能通过API调用访问其他微服务的数据

使用单独模型的好处是：

模型将是干净的。例如：在电子商务中，客户对于配送微服务、订单微服务、客户管理微服务等有着不同的含义。如果我们把所有需要的数据放在多个微服务器上，客户对象将变得非常大

微服务可以独立发展。在这种情况下，如果我们有一个客户对象和一个微服务，比如说Order one想要向模式中添加一些东西，那么所有的微服务都需要更改

如果我们有一个单一的数据库模式，我们将陷入一片混乱

就我而言，它可能会很贵

若昂贵，那个么读取模型实际上需要来自多个微服务的数据。然后更好地从多个微服务中侦听事件，并创建一个单一的读取模型，几乎不需要重复数据

---

如果还有其他问题，请提出更具体的问题。

微服务遵循每个服务模型的数据库，这至少会部分违反微服务体系结构的某些好处，就像一个服务宕机一样，那么需要DB访问的所有服务也会宕机一样。您可以让数千个微服务共享一个高可用的“数据库”每个微服务有一个“租户”或模式。除此之外，微服务不是强制性的，但如果多个微服务需要访问单个数据库，您可能需要重新设计这些服务，并尝试重新构建您的微服务。毕竟，微服务是一种体系结构风格，对于什么可以构成微服务没有任何严格的界限。不，微服务界限可以是3种类型之一：1）私有表-每个服务2）架构每个服务3）数据库服务器每个服务