作为微服务的持久层？
我是微服务架构的初学者，我在很多博客中读到过，在微服务架构中，每个微服务都必须有自己的数据库。在我的情况下，它可能花费非常昂贵。
我的问题是，有没有可能使持久层本身成为微服务？这将具有允许其他微服务对数据库具有读/写访问权限的功能。谢谢
共有3个答案
微服务遵循每个服务模型的数据库
让所有微服务访问同一个数据库将导致松散的内聚和强耦合
尝试查看是否可以为每个微服务定义单独的架构，以便确保微服务不会引用其他微服务的表。
这样，将来当您不再担心基础设施成本时，您可以无缝地为每项服务迁移到单独的数据库。
首先要回答您的问题，让我们了解：
每个微服务必须有自己的数据库。在我的情况下，它可能花费非常昂贵。
是的据说每个微服务都应该有自己的数据库。
它们的意思是每个微服务的表/集合应该是独立的（您可以使用单个可扩展数据库实例），并且一个微服务只能通过API调用访问其他微服务的数据
拥有单独模型的好处是：
>
模型将是干净的。例如：在电子商务中，客户对运输微服务、订单微服务、客户管理微服务等有不同的含义。如果我们把多个微服务所需的所有数据都放在客户对象上，就会变得非常大
微服务可以独立发展。在这种情况下，如果我们有一个客户对象和一个微服务，比如说订单1，想要向模式添加一些东西，所有的微服务都需要更改
如果我们有一个单一的数据库模式，我们将陷入一团糟。
在我的情况下，它可能花费非常昂贵。
如果昂贵意味着读取模型实际上需要来自多个微服务的数据。那么最好是监听来自多个微服务的事件并创建单个读取模型，少量的数据复制是可以的。
如果还有其他问题，问更具体的问题。
-
我刚开始接触微服务架构，我有几个关于数据持久性和数据库的问题。 所以我的理解是每个微服务都有自己的数据库（不一定，但通常）。但鉴于这种情况，请考虑一个包含用户、帖子和评论的常用社交媒体平台。将有两个微服务，一个用户的微服务和一个帖子的微服务。用户的数据库有一个用户表，帖子的数据库有一个帖子和评论表。 我的问题是关于帖子微服务，因为每个帖子和评论都有一个作者，所以通常我们会创建指向用户表的外键，但是
-
创建一个单独的服务来管理数据（如用户管理），这是一个好的实践吗？实现之后，只有该服务将有权访问用户和其他相关的DB表。所有其他服务都必须调用这个新的用户微服务来执行与用户相关的任务。 这种方法将迫使我们通过添加反规范化来重构DB模式。我们不会得到在多个微服务之间提供的基础表。如果服务器服务需要数据，它将通过微服务共享。
-
我想运行perl6/raku Cro应用程序，作为前端Web服务器后面的服务。 只是运行不会处理分段错误后的重新启动 以前在perl5中，我使用过FastCGI-但是的惯用语看起来不兼容FastCGI::Native的示例。 由确实有一个处理程序，但是我不确定这是否足以在服务中指向它，即。 人们目前如何托管Cro应用程序？
-
我能知道Hazelcast支持磁盘持久性吗？换句话说，我可以使用Hazelcast作为常规数据库吗？（就像apache点火一样）。
-
问题内容： 我正在开发一个Java REST API，它使用来自postgreSQL数据库的客户端数据。 数字： 。开始时大约有600个客户。他们中的一些人每隔几秒钟就会发出请求 因为客户是按请求付费，所以我们需要控制成功请求的数量是否达到限制，并且由于每个请求在性能差之后查询PostgreSQL数据（更新’hitsCounter’字段的值），我们正在考虑实施具有redis的缓存系统。 想法： 客
-
Seata 的事务上下文由 RootContext 来管理。 应用开启一个全局事务后，RootContext 会自动绑定该事务的 XID，事务结束（提交或回滚完成），RootContext 会自动解绑 XID。 // 绑定 XID RootContext.bind(xid); // 解绑 XID String xid = RootContext.unbind(); 应用可以通过 RootCon