为什么每个微服务要有自己独立的数据库？

[lotusp]

分享一下自己写的一篇文章：为什么每个微服务要有自己独立的数据库？

在微服务架构下，推荐每个服务要有自己独立的数据库，甚至现在一些企业会做微服务架构成熟度评估，其中有一条是数据库是否是每个 service 一个，甚至还要求每个数据库要独立部署。

最近跟一个同事讨论 EDA 的场景下数据怎么管理，不知道大家有没有什么经验？欢迎分享，谢谢

[FanError]

看完后，突然感觉 spring cloud 没 k8s 好呀。。
spring cloud 不方便做技术异构 0_0

[8rmEHZ8WhVHVOb0E]

数据库不拆分做微服务就没有意义 直接加机器就行了 ，我以前接手过一个系统，拆了 cms 、用户系统、支付系统但是数据库都是一个库，cms 拖死数据库的时候 支付一样永不了。除此之外，拆分数据库也是为了降低维护难度，比如你开发的服务调用了订单服务，你直观按它提供的接口使用就行，你不必关心它的实现，也不用担心数据太大分库分表之类的事情，那都是订单微服务的开发者关心的事情。

[xiangyuecn]

我上来就是一拳🐶🐶🐶

[LowBi]

好奇独立了又是怎么跟用户表这些关联

[yumerdev93]

@LowBi 同好奇

[flighter]

@LowBi 如果是像查询用户订单这种，一般的会在业务聚合层分别对 order 服务和 user 服务查询出来，然后再将数据组合一起， 好处是比较简单，再之后就是 CQRS 模式， 将查询与创建更新删除分离，构建一个查询模型，发生写事件(创建、更新、删除)时，通知事件处理程序，将查询模型中的数据进行更新

[xiangagou]

@LowBi 代码层关联，不在 sql 层。

[cccer]

@LowBi 用户相关信息单独做一个微服务，提供 SDK 给其他服务，在业务上避免出现其他表需要 join 用户表的情况。

[kaf]

如果不这么搞，同一张表会用的所有服务都是，到最后一张表变动一下，所有服务挨个搜索改，屎山啊

[libook]

系统架构上没有银弹，一切都应该从需求出发，虽然我做微服务基本上也是一个服务一个数据库，但从来不是认为每个微服务就应该单独配数据库，而是经过权衡后恰好这样做符合业务和技术上的需要，换言之，也存在一些微服务场景可以共用数据库的，甚至一个服务可以有多个、多种数据库。

[MineDog]

独立的意思是不用同一个 db 还是不用同一个 rds

[kongkongyzt]

@LowBi 通过微服务的接口而不是直接 SQL 交互, 减少耦合性

[fancy2020]

比较好奇都是独立 db 的话，事务(transaction)怎么做？

[EvaCcino]

等价于「为什么每套房子都要有自己独立的卫浴？」

[xiangagou]

@fancy2020 三阶段提交，有框架支持，代码跟普通事务一样。

[encro]

@fancy2020

说到了微服务的关键----消息机制：

https://www.infoq.cn/article/thmgmfvqvpwp9yrrxpmw

[jones2000]

开发成本, 维护成本都是成倍的增长

[jhdxr]

@FanError
sidecar :)
其实也还好，不少语言都还是有原生的 eureka client 的。

但总体来说我也赞成有条件的话 k8s 更优

[joetse]

EDA 是什么？我觉得拆不拆取决于预测未来的流量和预算…拆后实现分布式读写 ACID 。如果不差钱新增机器，有现成的调度器，或者能手撸一个，随便玩…

[chengyiqun]

@fancy2020 分布式事务, 事务补偿.