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

[lotusp]

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

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

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

[sujin190]

@LowBi #4 需要就同步一份呗，都限制死了不允许跨库还有啥好方法，大量冗余，如果有公共的事件订阅系统其实也还好，没有的话确实不是一般的费劲

[YzSama]

@tairan2006 中小公司，上 TiDB 成本不高么？

[tairan2006]

@YzSama 当达到性能瓶颈的时候再从 MySQL 迁移过去啊…很多架构师第一反应是拆微服务，中小公司实际上没啥必要。

[YzSama]

@tairan2006 #43 但是 ，mysql 迁移 TiDb ，也是有坑的。虽然 TIDB 说支持 mysql 5.7 ，但有些事务特性是不一样的。

如果，个别业务体量大，更新迭代快，拆出去是最好的。因为没必要其他服务一块跟着天天上线。

[dqzcwxb]

@qwe520liao #33 最后一段话是微服务,甚至是开发的经验之谈

[fengjianxinghun]

@YzSama TiDB 中小公司用这个不是找坑么。。。比如你就用 j**v 写点 curd 之类的。

[james2013]

不需要独立
除非数据太多了，必须要单独开来
要不然，多表 join 和事务非常麻烦

[FleyX]

微服务发明就是为了解耦，避免单点故障引起整体崩掉，如果多个服务用同一个数据库，那么这个库出问题，对应所有依赖这个库的服务全都会挂，那拆分这几个服务的意义就没了，还不如不拆

[tairan2006]

@YzSama 拆服务和拆数据库是两个问题。我意思是拆分数据库很多时候会引入非常复杂的问题，有时候其实并没有必要，用分布式数据库也可以。当然，肯定是拆了数据库才完全解耦。

不说分布式事务，很多时候只有一个服务写的数据，多个服务都要 join 读取，所以拆分之后还是要重聚合。binlog 同步 es 或者搞数仓之类的，这些才是麻烦事。

[BenX]

这类问题是建设规划问题

[wonderfulcxm]

好家伙,果然, 没有什么计算机问题是不可以靠加一层来解决的.
解决的思路就是为了不耦合再加一层.还耦合那再加一层.

[YzSama]

@tairan2006 #49

按你说的确实，可以在不拆分库的情况下，可以这么弄。

[pastor]

就是像楼主这种只知道人云亦云拿来主义的垃圾架构师太多了，而且其中很多还喜欢“布道”，于是坑了更多人

前几年大肆鼓吹微服务的很多，被坑的人很多，以 uber 为例，去年又发帖子说他们要搞宏服务

中台也一样，坑很多团队，真正适合的搞法是从实际出发，除非你家业务成熟稳定需求不怎么变了比如很多传统企业级的产品，否则就别鼓吹什么不知道实事求是的方法论了

[ChenSino]

@zcf0508 说出了我的心声，前离职同事非要给我们这个几百人用户的服务上了一个微服务，结果 2 个后端，1 个前端要维护一大推屎山，tmd 他自己被公司 fire 了

[frandy]

自己的产品整个微服务,中台的概念还情有可原,本身公司性质就是类外包,甲方还跟风硬要用微服务,甲方是 toB 的业务,一天用户量不会上千,纯属于折腾乙方。这样的甲方来一个也就罢了,一来来几个,最终错付的还是程序员。 @qwe520liao 的回答真的很共鸣。
一上来来一套分布式架构的东西,什么注册中心,分布式事务,链路跟踪,分布式消息来一套,别的不说,哎,就是高大上,什么熔断,限流,水平拓展包齐全。业务,什么业务,我要的就是有逼格,要的就是标书能拿下,业务就那么点东西,用的人就那么点,能有啥技术含量。

[lotusp]

@pastor #53 看了你的很多留言，确实是个天生不会好好说话的人，讨论技术就说技术，别夹枪带棒的人身攻击，要是真不会好好说话就少说

技术没有对错，看你用的对不对，微服务这么多年，有人成功，有人失败
中台也是有人成，有人败，搞不懂关键问题在哪就开始整不死才怪
你搞不定不能一棒子打死就说技术不行

@qwe520liao #33 楼说的很中肯，也是经验之谈，微服务目的是解耦，提升弹性，不是随便拆成几个进程就完了

[pastor]

@lotusp

”讨论技术就说技术“
我在上一楼回复过：
“中台也一样，坑很多团队，真正适合的搞法是从实际出发，除非你家业务成熟稳定需求不怎么变了比如很多传统企业级的产品，否则就别鼓吹什么不知道实事求是的方法论了”
——我这个不是就技术论技术吗兄弟？

你自己看下这个帖子的标题：“为什么每个微服务要有自己独立的数据库？“　妥妥的推广软文带节奏的标题，你能保证每家业务都跟你讨论的技术选型适配吗？什么叫从实际出发？但凡脑回路正常点，也不会这么武断地来写出这篇文章。从来就没有什么大一统的技术框架，踏踏实实做事，少出来坑小白

还有逻辑问题："你搞不定不能一棒子打死就说技术不行"
你是怎么看出来我搞不定的呢。。。我照样搞微服务，但是不会像你这种千篇一律设计一种架构方案，而是根据实际情况去设计服务架构。


另外，你可能误解了什么是不会好好说话。我只是对帖子标题这种明显反智之类的言论不好好说话，并不是见谁喷谁。而且不管是前面的回复还是这个回复，我也不是虚空喷，讲了原因的，如果楼主看不出来，那更说明我对此帖不好好说话是对了

[pastor]

@lotusp
“别夹枪带棒的人身攻击”
没想人身攻击，社区里确实是你们这些带节奏的“技术大能”太多了，对于小白，你们的很多“布道”都是在误导人。
我们招聘的时候就能遇到很多被你们洗脑了的技术人，或者团队里总是会有人被洗脑后，把我们的架构做的高耦合低性能且臃肿难看。

”就是像楼主这种只知道人云亦云拿来主义的垃圾架构师太多了，而且其中很多还喜欢“布道”，于是坑了更多人”
我前面说的这句，说的是实际情况，我不是针对阁下，我是针对所有像阁下一样的所谓“架构师”，如果觉得这算人身攻击，那也可以自省一下是不是需要把技术做得踏实、扎实一点再“布道”。或者，就思考、分享、讨论的帖子也行，不要那么信誓旦旦把自己说成成功经验、既定规范，比如帖子题目改成”关于微服务与数据库设计的思考“，然后大家来讨论，这都没毛病。

[lotusp]

@pastor 上来就一句“像楼主这种只知道人云亦云拿来主义的垃圾架构师”，这么直接的攻击不叫人身攻击，我也是很难理解你的思考方式。没想人身攻击说话就注意表达方式，请“好好说话”。

[lotusp]

@pastor 没有谁做技术是千篇一律的，如果你读一篇文章就认为这是唯一的架构方案，不需要根据实际情况做调整，也需要自省一下，写文章是分享思路和经验，每家的业务复杂度、技术实力、现实情况都不一样，某些技术选型有什么优势，有什么劣势，这是我们要讨论分享的。

“中台也一样，坑很多团队，真正适合的搞法是从实际出发，除非你家业务成熟稳定需求不怎么变了比如很多传统企业级的产品，否则就别鼓吹什么不知道实事求是的方法论了”
---- 这观点就很武断，滴滴、阿里哪个业务稳定，哪个变化不快，为啥非要稳定的传统企业才能用中台
很多中台搞不起也不单纯是技术的问题，组织结构上就很难支持