关于微服务设计的一个问题

[Aliberter]

公司关于微服务项目的设计中，打算把所有关于数据库的操作都集中到单独的服务中，每一个其他微服务有数据的增删改查都要去调用这个服务获取，我想问这有必要吗，甚至说这是不是已经违背了微服务的设计原则了？我感觉除了带来服务之间耦合性之外，也让数据事务的控制变得很难，增加了网络消耗，甚至也让开发层面变得异常困难与繁琐，想不通为什么要这么搞，感觉毫无优点可言。请大佬们指点一下。

[iConnect]

微服务本质上是不合理的结构。打造一个产品没必要把手工作坊全改成工厂，但是大规模制造必须上流水线了，各司其职，专人专事提高效率。所以你说的问题这样看才是合理的。

[puncsky]

https://tianpan.co/notes/120-designing-uber#why-micro-services

[Aliberter]

@iConnect 我感觉没有太能说服我，专人专事，按照业务去划分为不同的服务不就是已经专人专事了吗，为什么单独要把数据操作抽出来？它提升效率的点在哪？现实中可能我接触的项目还不够多，我还没遇到过这样设计的，如果只是因为理论的合理性而不去考虑执行效率开发成本我觉得就是在耍流氓，我现在需要的是大佬能说服我，或者是给我理由让我去说服公司的项目设计。

[Aliberter]

@puncsky 看了一下这个设计就很正常啊，每个服务去单独的操作 db 就 ok 了，我现在说的是一个比较奇葩的设计场景，相当于在业务层和 db 之间又加了一层，所以我问加这个干啥…

[opengps]

你的想法属于按软件功能组拆分，不是按需求功能组拆分，各有所长。
微服务出发点是将来集群下针对压力大的服务单独扩容节点，实现全局压力均匀，缺点是每个微服务都是个全面的个体
你的出发点更符合小而全的整体打包，比较符合以前的类似于三层架构，但是将来做大之后需要每个团队成员提交时候都得对整个代码库进行获取和编译

[watzds]

你说的是各个服务直接读自己相关的数据 ，还是专门搞了一个读数据的服务

[iConnect]

@Aliberter 不清楚你那边是什么业务，具体业务具体分析吧，比如电商类的，以后做秒杀是要考虑到的高并发和限流，如果数据请求很分散，就不容易全局控制。

[magicdu]

单独把 Dao 拿出来作为了一个服务？不是分库分表吗？你们怕不是搞“数据中台”吧。

[k9982874]

吃饱撑的

[wangxiaoaer]

1 不要微服务而微服务

2 “公司关于微服务项目的设计中，打算把所有关于数据库的操作都集中到单独的服务中” 微服务不是你这么微的

[passerbytiny]

这是一个很蠢的、拍脑袋的、错误的设计，如果上面的人强行推这种架构，赶紧跑路。

这种架构的优点是：我本质上不是微服务，但我表面上看着像。缺点那是一大堆，单说一点：关于数据库的操作都集中到单独的服务中，就没有数据库级别的事务了，而一旦没了数据库级别的事务，不管是强一致性（要添加 2 阶段提交等分布式事务导致性能大降），还是最终一致性（需要对每个原子 SQL 操作都准备好补偿措施导致开发难度剧增、可用性降低），都很难做到了。

[IMCA1024]

我看看怎么发 PDF。。。。有两张 PDF 想发上来

[technode]

DAOService 是很多新手想做微服务又怕团队搞不下去的一个折中办法 其实没啥鸟用 建议直接不用微服务

[IMCA1024]

@IMCA1024
https://github.com/caztg/information
有兴趣看看有没帮助。。刚上传上去的

[zr8657]

就是说所有服务想要操作数据库都要调用同一个数据库服务吗？就像游乐园入园排队排了 5 排，但是入口一次还是只能入一个人，那 5 排有什么意义呢？

[janxin]

可能是个数据中台 23333

[cabing]

微服务现在都是公司的标配了。
这是硬核微服务。。

难道是因为你的 boss 偶然看了贝佐斯提出的服务的 6 个原则？

[popesaga]

上一家公司的工作，应用沿用了两三年的架构就是这么干的。当时没觉得有多大问题，还觉得展示层做展示层，业务层做业务层，数据操作层做数据操作层挺好。后来说往 DDD 和 serverless 上靠，划分领域后一个领域的所有操作在一个应用，展示层到底层代码都在一起。不过这个架构没整完我已经走了，不清楚最终形态是什么。现在工作又要考虑架构，讨论下发现这个确实有问题。我说下我一开始理解的可能成立的理由哈，抛出引玉让大家批判下。如果对同一份数据的操作散布在不同应用里，那么每次一个数据模型的变更。要么选择所有相关应用都变更，要么根据这次需求的影响范围变更。前者可能造成应用多发布，后者则造成不同应用对同一份数据操作不一致。数据库操作集中在一个应用是一种解法，那么只要变更数据库操作应用和业务应用即可，能做最小发布。新的问题来了，考虑到单纯变更就是可能引起故障的一个风险点，那么更合理地减少变更并且满足业务需求法是怎样？

[a852695]

说白了就是把 CRUD 给全部统一在一起，感觉这个拆分不是很合理。一是 CRUD 本身就和业务关联很大，微服务是要划清楚边界，这下又把边界给混在一起了。二是还得维护好 CRUD 的接口，这成本恐怕不能接受吧。一般来说是按照业务领域进行划分的。

[dovme]

个人觉得微服务里面的每一个服务,应该可以不依赖别的服务而运行,除非个别地方调用了别的服务的接口,但是, 你现在这个如果没有数据库服务就完全无法工作了.