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

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

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

我上来就是一拳

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

@LowBi 同好奇

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

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

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

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

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

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

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

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

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

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

@fancy2020

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

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

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

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

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

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

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

@fancy2020 分布式事务，原理忒麻烦

服务分拆，数据库分拆，全部独立一套，这样的项目，一般公司 hold 不住

小公司做这套。。。快醒醒，公司已经没了。

@fancy2020 #13 分布式事务

简单点按业务分表，按大业务分库，整体连接的都是一个数据库集群。服务不允许操作数据库里非自己的数据，其实也差不多达到了要求了。

@Actrace 你这句逗乐我了。我中山面了几个问微服务的，我就好家伙，你公司就没几个人，还微服务。
事实上我也没做过微服务

做评估的跟卖软硬件的是不是有利益输送。。。。。

@EvaCcino 比喻的很好，下次不要再比喻了。既不懂微服务，也不懂现在房子并非都是商品房。

@dddd1919 一个服务一个数据库，又不是一个服务一个 instance 实例

公司 1 个前端 3 个后端，系统却有 20 多个，数据到处冗余还不一致，天天修数据。

@xinJang #26 我一个人搞微服务架构搞了半年

@klo424 我我我不会啊 主要也不知道的它实际场景

给微服务一个定义吧，普遍认为的微服务就是把什么订单、用户等等系统拆分出来当作一个独立的项目来开发和部署，但是需要注意这个“拆分”只是逻辑上的。

比如我在开发的时候将所有的服务都放在一个项目里面，然后最终只打包出一个可执行文件来，分别在 ABC 机器上面进行部署，然后在 nginx 上面针对请求的 URL 路径转发到不同的机器上。我可以在 ABC 机器上面都分别配置不同数据库，毕竟这台机器只负责部分子集，只会操作部分的数据表，这样一来出现的一个问题就是 ABC 之间数据不互通了，比如订单需要查询用户信息，调用 UserService ，UserService 将不会查询到用户数据，因为这些数据存在于另一台机器和另一个数据库上，一种办法是 ABC 三台机器使用同一个数据库，这样可以解决数据互通的问题。注意自始至终我没有使用到 RPC 以及消息队列，我只是将同一个程序部署到了三台机器上，每一个机器负责部分的 URL 请求，你说这算不算是微服务呢？

如果你认为不算，我们可以改造一下，当某一个机器调用 XXXService.doSomething()的时候，实现不再是通过 JVM 进程内直接调用对象方法，而是通过构造 HTTP 请求另外一台专门负责这服务的机器来进行处理，这样一来，我们就可以将 ABC 三台机器又恢复到使用各自独立的数据库。如果我们拆分得足够好，三台机器应该至始至终只会生产和查询自己负责的那几张表。你说这算不算是一种微服务呢？

注意不管我如何部署，我们的开发结构仍然是一个单体的大项目，所有的代码在变更以后都需要重新打包然后部署到三台机器上面，但是如果我只修改了 A 机器负责的功能，我可以只更新 A 机器那一份，只要接口没有变动，其他两台机器仍然可以正常请求。

既然 ABC 都只负责部分功能，那为什么不在开发的时候就建立 3 个项目呢？这样岂不是更加清晰吗？的确可以这么做，但是我想说的是这样并不是必须的，或者说这不是重点，那么重点是什么？重点就是你如何确定这是 3 个项目而不是 4 个或者 5 个呢？是根据有 3 台机器我们就得有 3 个项目吗？所以重点就是如何找到进行拆分背后所隐含的那些逻辑，这些逻辑就是你的业务组织方式。

早前，我以为开发微服务就是把各种 Service 拆分出来当作一个独立的进程，使用独立的数据库，然后通过 RPC 进行相互调用，成功的把的注意力集中到了各种注册中心，网关，配置中心等等令人眼花缭乱的东西上面去了。在经历各种各样的填坑之后，回过头来再想一下，如果我只是作为一名开发，真的有必要去了解这些东西吗？我把大量的时间浪费在了去研究这些鬼东西上，反而把应该排在第一位的需求给丢到了一边。当服务网格和容器化出现以后，我对微服务这个词有了一些不一样的定义，说到底微服务终究不过是一种部署策略，它不是什么开发架构，它只是一系列指导如何正确开发服务的约定和理念，有了这些理念，我们就可以更容易的开发出适配部署运维的应用服务。微服务的终极目标，不是教我们如何用什么开发框架，用什么中间件，而是为了实现如何使资源利用得更加合理，更加有弹性，更加可伸缩。

@walkerliu 所以多服务会用到更多或者性能更高的机器，至少考虑去单点的情况，总归要吃更多的资源

@lscexpress #28 哈哈哈哈 老哥说的太对了

@xinJang 我不是嘲讽微服务，我主要是嘲讽 CTO （如果有的话）。有时候真的是笑死。

产品：我要点数据，你把两个微服务的数据库同步一下就好了。
大部分的需求跟基础架构不会考虑系统设计，各怀鬼胎

因为数据库必须酱紫

@LowBi #4
@yumerdev93 #5

微服务首要解决的是业务解耦，性能是其次。要业务解耦首先要做的是去关联，不去关联就不要做微服务。去关联的方法多得很，就是门槛比较高（其实门槛本身不高，而是 Sun 带起来又被国内发扬光大的"J2EE>三层架构>CRUD”风格，把门直接给隐藏了）。

拆分数据库是为了性能，如果你的量级不够没必要拆分。

其实中小公司直接上 TiDB 这种分布式数据库更简单。

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

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

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

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

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

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

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

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

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

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

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

这类问题是建设规划问题

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

@tairan2006 #49

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

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

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

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

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

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

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

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

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

@lotusp

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

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

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


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

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

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

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

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

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

你可以对比下隔壁的技术分享：t/855914
再看看你的文章里有多少有用的干货，你的帖子标题我前面就解释过了

少点假大空，少点 ppt 架构师，没啥有用的贡献还拿很多钱并且坑队友误导社区

你要非觉得是人身攻击那就是吧，就像你认为“每个微服务要有自己独立的数据库”一样，你觉得好那你就觉得好呗


“这观点就很武断，滴滴、阿里哪个业务稳定，哪个变化不快，为啥非要稳定的传统企业才能用中台
很多中台搞不起也不单纯是技术的问题，组织结构上就很难支持”
你是真觉得阿里中台很成功是吧，中台也好、微服务也好，多搜几个“阿里 中台”关键字的文章看看再来反思自己的技术吧，你看看说它好的有几个、不好的有几个，如果真的好，会是这种局面？

另外别觉得中台没有失败，只是老板们总不能自己打自己脸因为自己代表着集团，随便承认错误资本也是不答应的，因为还有声誉、公信力、股价各种，所以委婉地低调转变罢了

从你的文章和回复中，我知道你也是个受害者，自己并没有深入体会，甚至别人都船掉头了你还在顺着人家的轨迹继续驶向深渊。所以我说你们人云亦云垃圾架构师，没说错，但凡哪天你真的进阶了会发现我这是点醒梦中人，回头肯定要感谢我、至少是内心里感谢我让你在技术理解上少走了一些弯路

就像早年的 ACE 框架一样，圈子里广泛流传一句评价：学之者生，用之者死

微服务、中台也是类似，只是如果能实事求是地运用，也不至于死。但是大多数人都做不到，大多数人都是盲目跟风胡乱拆分一通服务，然后呢，横向上服务数量增加了，纵向上调用链条增加了，开发流程图变复杂了，人力增加了，运维复杂度增加了，遇到问题时排查难度恢复难度增加了我不是说所有的微服务都不合理，但多数团队都是东施效颦成了这种，除了程序员吹了一波自己技能点，更大程度就是重复制造垃圾代码、浪费电

明白人好好跟这说话根本没人信，全去信道貌岸然西装革履说话像心理按摩一样的所谓大能架构师布道师了。国内的 KPI 环境，尤其阿里为主带头搞这种文化的企业，踏踏实实本本分分做技术的人里，有多少被这种 ppt 架构师坑的，然后 ppt 架构师踩着老实人肩膀爬上去留一地鸡毛给老实人擦屁股，新东方版的《沙漠骆驼》听过吗？