微服务 数据库耦合_mysql – 与其他服务共享的微服务数据库

我搜索过但找不到直接答案的东西是：

对于给定的服务,如果有两个服务器的实例部署到两台机器上,它们是否共享同一个持久存储,或者它们是否具有一些具有某些同步机制(主/从,群集)的存储？

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

这可能听起来很愚蠢,但对我来说,每次讨论都会使服务和数据库看起来像是一个部署在一起的打包单元.但很少讨论提到部署第二个服务时会发生什么.

解决方法:

将此作为答案发布,因为评论时间过长.

微服务是自包含的组件,因此负责自己的数据.如果您想要获取数据,则必须与服务API进行通信.这主要适用于不同类型的服务(即,您不在提供不同类型的业务功能的服务之间共享数据库 – 这是不好的做法,因为您通过数据库将堆中的服务耦合在一起,然后很容易结合更多的事情通常可以在API级别完成,但通过数据库更新会更方便=>您可能会失去组件化的风险.

但是,如果您拥有相同类型的服务,那么正如您所提到的那样,有两个明显的选择：共享数据库或让每个服务包含它自己的数据库.

现在您必须问自己,您选择了哪种解决方案：

>您的这些OrderServices是否真的能够独立工作,或者您是否需要在同一数据库中拥有所有订单以供其他应用程序报告或访问？

>确定你的实际瓶颈是什么.是数据库吗？如果没有,则共享数据库.这是服务吗？如果没有,那么分发您的数据.

>需要分发数据吗？你有什么选择,你有什么需求？您是否需要始终保持一致或最终的一致性足够好？您是否需要拥有单独的数据库并手动同步它们,或者您的数据库安装是否处理复制和分区开箱即用？

>等

我想说的是,在这种情况下,答案是：它取决于.在开始这样的分布式/可扩展性/架构旅程之前,我们技术人员经常忘记做的事情就是与业务部门交谈.业务通常可以处理某种程度的不一致,次优的流程或在更多地方查找数据而不是一个(即您认为重要的可能不一定是业务).所以和他们交谈,看看他们能忍受什么.以操作方式解决问题可能比在试图建立高度可分配系统上投入大量资金更便宜.

标签：mysql,web-services,deployment,microservices

来源： https://codeday.me/bug/20190623/1274214.html