与其他服务共享的微服务数据库

4

我一直在寻找一个明确的答案,但没有找到:

对于一个给定的服务,如果有两个实例部署在两台计算机上,它们是否共享相同的持久化存储,还是具有独立的存储和某些同步机制(主/从,集群)?

例如,我有一个由MySQL支持的OrderService。我们收到很多订单,因此需要扩展这个服务,因此我们部署了第二个OrderService。它的数据从哪里来?

可能听起来很傻,但对我来说,每次讨论似乎都表明服务和数据库是打包在一起部署的单位。但很少有讨论提及当您部署第二个服务时会发生什么。


如果您的单个实例具有Web服务+数据库,而不知道提供程序的具体信息,则任何水平扩展(即添加更多实例)都将复制现有设置,这意味着每个实例都有自己的离散数据存储。唯一的解决方法是解耦并独立地扩展数据和Web服务,或者垂直扩展(向现有实例添加更多资源)。 - pala_
好的,这一切都很有道理。但在“微服务”的背景下,DB是否应该在不同服务实例之间共享,以独立于服务进行扩展,还是应该将DB与服务配对,使每个可部署单元真正独立?在我看来,我倾向于后者,这样两个部分的扩展就会自动发生,而不是针对n个服务的流量独立扩展DB。 - MikeG
然后你陷入了如何在实例之间同步数据的问题中。这并不是一件简单的任务。 - pala_
1个回答

5
因为这篇内容太长了,所以我将其发布为答案。
微服务是自包含的组件,因此负责自己的数据。如果您想获取数据,则必须与服务API交互。这主要适用于不同类型的服务(即,您不会在提供不同业务功能的服务之间共享数据库-这是不良实践,因为您通过数据库将服务耦合在堆中,然后很容易耦合更多通常应在API级别完成但通过数据库执行更方便的事情=>您面临失去组件化的风险)。
但是,如果您拥有相同类型的服务,则有两个明显的选择:共享数据库或每个服务包含自己的数据库。
现在,您必须问自己选择哪种解决方案:
- 您的这些OrderService是否真正能够独立工作,或者您需要将所有订单放在同一个数据库中以供报告或其他应用程序访问? - 确定实际瓶颈是什么。它是数据库吗?如果不是,则共享数据库。是服务吗?如果不是,则分发数据。 - 需要分发数据吗?您的选择是什么,您的需求是什么?您是否需要始终保持一致性,还是最终一致性就足够了?您是否需要单独的数据库并手动同步它们,还是您的数据库安装可以处理复制和分区? - 等等。
我想说的是,在这种情况下,答案是:取决于情况。我们技术极客在开始这样的分布式/可扩展性/架构之旅之前经常忘记与业务交谈。通常业务可以处理一定程度的不一致性、次优进程或在多个位置查找数据而不是一个位置(即,您认为重要的可能不一定是业务所需的)。因此,请与他们交谈并了解他们能够容忍什么。以运营方式解决某些问题可能比投入大量精力构建高度可分发系统更便宜。

考虑的因素很多。我想我的问题应该是:最大的系统如何处理持久性?对我来说,像Cassandra这样的数据库在这里是理想的,因为每个新服务的数据库实例都可以加入集群,并且可预测的水平扩展将是结果。但这仅适用于一个数据库,那么其他的呢?对于我自己的个人目的,数据不能被分区用于您之前提到的报告用例。 - MikeG
最大的系统是如何处理持久性的?答案仍然是:这取决于具体情况!如果这不是你期望的答案,我很抱歉,但在处理大型系统中的持久性时,并没有任何标准方式。 在过去,这很简单:使用关系数据库。无论其功能如何(Oracle,MSSQL等),你都会使用它... - Bogdan
现在,我们不再使用通用的关系型数据库,而是有很多专门处理特定问题的数据库(主要是NoSQL)。大型系统现在具有多语言持久性,这需要处理其自身的问题 - Bogdan

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接