微服务的缺点

[gansteed]

https://jiajunhuang.com/articles/2020_02_19-should_i_use_microservice.md.html

微服务，火了好几年的东西。曾经我们看中的是微服务拆分之后，每个项目变得更小，对团队的每个人来说维护成本降低，因为需要了解 的东西局限于一个更小的服务。第二是加强了技术选型的灵活性。但是由于没有实践，并不知道微服务会带来什么大的问题。 当我们大规模应用微服务之后，问题才开始慢慢显现出来。

• 网络调用过多
• 技术栈太过灵活
• 难于应对连表查询的需求
• 核心应用崩溃会导致大面积瘫痪
• 运维成本增加
• 接口风格不一致

上面就是个人总结的一些微服务所带来的问题。对每个缺点的详细说明请看原文 :)

首先不要喷，这不是讨论该有的氛围，心态平和一点不是坏事。

其次，灵活与死板是一个度的问题，不是说灵活不好，说的是太过灵活。如果说认为太过灵活是优点，说明没有经历过此类痛苦。

再者，连表查询，不是说在微服务的情况下连表，而是指，当有此类需求时。

[m939594960]

灵活不是件好事么？如果你不想灵活就规定不能使用其他语言 /框架啊


核心应用崩溃会导致大面积瘫痪，熔断啊，降级啊


运维成本增加？ 单体应用不会有自动扩容之类的策略么？做到微服务里一样啊，用 kubernets 解决更方便


接口风格不一致？这还是人的问题，如果人有问题不用微服务他也能写的不一致。


“而当 A 成员 去维护 B 成员的项目时，A 成员就不得不再学一个重复的对他无提升的东西。” 微服务的优势就是每团队维护自己的东西，那团队里面每个人用的还都不一样？？

[Erroad]

1. 注意粒度和划分方式，不要强行微服务；
2. 建议人为约束并建立代码规范，建设公用代码库；
3. 可能是业务模型划分问题；
4. 可能是服务注册发现问题；
5. 业务规模大，运维成本感觉都不会小，微服务现在也有很多运维方案了；
6. 建立规范或使用同样的框架。

[zhuawadao]

@m939594960 看到您没有提到这个，比较关心"连表查询的需求"在设计之初怎么优雅的设计的
@gansteed 建议您同时写一个《微服务的优点》，看看对于您来说是否利大于弊

[optional]

* 调用过多是领域架构不合理，不该分得被分了。
* 技术栈太过灵活 不应该是优点吗
* 分布式下，join 查询应尽可能被避免。
* 『核心应用崩溃会导致大面积瘫痪』 这说明只做了应用拆分，没有上微服务治理（熔断，负载均衡）
* 上了 ci/cd,k8s 等容器化架构之后，运维成本不一定增加
* "接口风格不一致" 不算确定，和第二点灵活是一样的

[optional]

不算确定 -> 不算缺点

[Jacky23333]

一名在校大学生，看到技术栈太过灵活突然笑出声

[m939594960]

@zhuawadao #3 join 尽量避免啊，比如要查询用户列表可以先这样
$users = User::where('status',"1")->get(10); // $userIds=[1,2,3,4]

然后第二个服务这样

$result = UserInfo::whereIn("user_id",$userIds)->get();

[sphawkcn]

*核心应用崩溃会导致大面积瘫痪

这个锅不该微服务来背吧，如果没有设计好，其他架构在核心应用崩溃的情况下同样也会导致大面积瘫痪。

[sujin190]

@zhuawadao #3 微服务的首先要求不就是不能有联表查询么，如果实在有这个需求但又不好解决，那说明你可能是在强行微服务，拆分不合理

微服务拆分可以按单一完整功能拆分也可以按业务拆分，数据流上看对数据库的依赖每个服务应该是内聚管理的，换言之如果尽可能在微服务内部完成数据重组，以及实时计算、离线计算这样来处理关联数据，微服务面向的本来也是超复杂业务、数据量大系统，别功能页面没几个，一个月都没几个人用，还搞啥微服务，那真的是在作死

关于中心节点问题，既然微服务，逻辑拆分上是不应该出现完全中心节点，当然大节点避免不了，那么按照节点重要成都，运维要求、服务治理要求、性能稳定性要求都是不一样的，微服务的特点也在于此，本身就应该随着业务发展不断升级进化，你都发展成超级大车，前面的小马不好好升级一下，不死才见鬼了

[uxstone]

因噎废食

[server]

复杂是原罪

[Seddas]

切实体会，每个组管一小块，遇到跨部门的项目来回扯皮，屁大的改动拖个半年，不知养活多少中层管理

[feelinglucky]

下面是个人的些观点，不是杠供参考

网络调用过多 // 业务在大部分情况下达不到网络 IO 瓶颈上限的
技术栈太过灵活 // 个人不认为这是坏事
难于应对连表查询的需求 // 微服务封装以后，怎么还需要连表查询？有点不理解
核心应用崩溃会导致大面积瘫痪 // 看架构设计的能力，以及运维的部署了，这个锅不应该微服务背
运维成本增加 // k8s 很香
接口风格不一致 // 技术管理的问题，和微服务无关

[murmur]

分布式早就有了，微服务只是加个名字，买了别人的东西又叫 serverless，什么都不是万能药，得看好自己的需求

[wc951]

搞微服务之前先学学领域驱动设计

[chenqh]

微服务之后不需要链表查询？

[tt67wq]

网络调用过多 就这个是个问题，其他的都不算

[zjsxwc]

就和 Linux 一直宏内核、macOS、Windows 是微内核一样的道理

[leonard916]

@zjsxwc macOS 是混合內核 謝謝

[wolfie]

只有运维成本增加一个说对了。

[soulmine]

啥都没强行上是这样的

[est]

service mess 分布式 monolith

[luzemin]

锤子就是这样，使用的不顺手，那就是你没拿着去钉钉子。（同意楼主，手动狗头）

[javapythongo]

微服务确实对架构、拆分、运维要求有点高，复杂必然的

[powerfj]

只提问题不关注场景, 也不不提解决方案感觉有点耍流氓.

[WispZhan]

微服务肯定是有优势的，但是不是软件架构里的银弹。

说实话，小公司做微服务费力不讨好。 就那么几个人。 大部分小公司的服务， 最后都拆成了 Entity 实体服务了。 哪里有内聚和自治可谈。 你说的这些就是典型的，这个问题的表现。

各种强行微服务。先把服务边界定好才是重点。 另外，部署和监控问题是第一个要解决的，没有这 2 个前置条件，就谈微服务，简直扯淡。

[zrc]

网络调用过多 ，这个体会挺深，一个接口由 A 提供，A 依赖 B，B 依赖 C，C 又依赖 D，这个时候 D 又依赖了 B。
链路过长的时候，和容易产生一个循环依赖。
各个微服务之间开发，运维都相互独立，当出现故障时，一个问题的排查就更复杂了

[W1angMh]

@zrc 网络调用确实多，但是服务之间产生循环依赖问题 ，这个就真的是业务拆分和架构设计问题了

[SkyYu822]

我不会

[superbiger]

灵活度太高，那是需求边界不清晰带来的。感觉什么都能做，就缺乏框架性。
至于连表查询，讲真。反泛式的存储，以及合理的用户行为和模块划分是能够避免。不要搭理产品或者用户的一些不合理需求。非要一个页面看到所有信息，是不可能也不显示的。信息卡在不同的信息流线下呈现不同的焦点性才能够提供用户的使用便捷性和使用效率。

[flashrick]

@WispZhan 部署和监控分别有什么成熟的坚决方案吗？

[iphantom]

楼主说的话，简直，是我的心声啊，不做项目管理只是纯粹做开发的人，或许很难理解楼主的一些点；
特别大的项目，有架构团队，比较小的项目，用什么架构其实都差不多，微服务和不用其实区别不大，就是这种中型项目，微服务有其优点，但有一些本身的缺点，也是很头疼。
我们这种关联方特别多的项目，甚是头疼啊

[Michaelssss]

微服务的缺点？费钱是头号…

[p1094358629]

这么多缺点,只认 IO 开销大这一个缺点

[jeffh]

深有同感，微服务不能拆得太细了，遇到过把商品和订单两个模块做成两个微服务，期间的查询真是令人头疼，特别是分页查询。

[seanseek]

还有重复造轮子，太难受了

[tairan2006]

小公司最好别上微服务，先把服务边界拆分好

[xsen]

微服务，火了好几年的东西。曾经我们看中的是微服务拆分之后，每个项目变得更小，对团队的每个人来说维护成本降低，因为需要了解 的东西局限于一个更小的服务。第二是加强了技术选型的灵活性。但是由于没有实践，并不知道微服务会带来什么大的问题。 当我们大规模应用微服务之后，问题才开始慢慢显现出来。

网络调用过多
-----------------------------------------------------------------
不知道是如何评判过多？是影响到带来额外的处理延迟，还是性能瓶颈，或是带来额外的运维

技术栈太过灵活
-----------------------------------------------------------------
有很多选择又不是以为着所有的都会使用。若出现混乱（如随意选用技术栈等），这是管理的问题
选用特定技术栈，自然是有响应的好处

难于应对连表查询的需求
-----------------------------------------------------------------
这是架构或管理要背的锅

核心应用崩溃会导致大面积瘫痪
-----------------------------------------------------------------
降级，限流就是来做这个的

运维成本增加
-----------------------------------------------------------------
短期看是带来运维成本增加，但若真的把 devops 用起来；就算是简单的把 docker 用起来，看到的都是节省运维成本

接口风格不一致
-----------------------------------------------------------------
管理要背的锅

上面就是个人总结的一些微服务所带来的问题。对每个缺点的详细说明请看原文 :)

[xsen]

有人说小公司不要用微服务，恰恰相反，小公司更应该用微服务。因为这样整套框架搭建起来之后，在招人用人及运维方面，都是极其节省各种成本，提高开发维护效率

[huahouye]

一个人开发都可以用微服务，只要自动化跟上，约定优先于配置，微服务雏形只需要大于两个服务就够了，其他的往后再演进 😃

[gamexg]

感觉微服务的麻烦是事务支持
跨服务锁和回滚比较麻烦。

[hantsy]

任何东西都有利弊，微服务也一样。

国内真正实施成功的，像 Netflix 那样的经典案例很少，很多 3，6 月用 Spring Cloud 做出来的东西的案例只能当笑话看看了。微服务灵活扩展性是优势，也是痛点，实现起来带来的运维成本会成几何级的增加。

1. 微服务实施中，开发的成本显示增加，另外 DevOps 在微服务实施过程是一等公民，没有 DevOps 的微服务是假微服务。开发过程中写测试的成本大大增加，实现 CI 完全自动化难度明显增加。

2. 技术上的挑战，服务快速响应（ circuit breaker, load balance)，安全，微服务下分布式数据的一致性（ CAP，CQRS，EventSouring ），一系列服务之间的调度问题（ Saga，Workflow ）。

3. 公司组织结构的调整，对于微服务开发，传统的根据项目功能（设计，开发，测试等）来划分不同的组已经无法适合微服务开发，开发人员必须具备基本的 DevOps 知识，实施 Infrastructure as Code。各开发组不再以功能区分， 各组之间以服务划分，各组自己负责服务整个发布周期。

[hantsy]

@huahouye 不错， 微服务是一个不断演进的过程。

[guolaopi]

看到有人说的微服务之后不用连表查询，我来请教个问题（认真的请教）

举个电商系统的例子，有一个查询历史订单的服务 historyOrder，有一个查询店铺信息的服务 shop。
现在有个需求要在订单中所有商品显示对应的店铺信息（不是单纯的名字，比如要显示店铺等级和联系方式）

如何实现。。
先调用 historyOrder，再根据 shopId 的 list 再去调用 shop 服务，然后合并结果的 model 吗？

[goldpumpkin]

@guolaopi 也可以不用服务间的调用。
系统 historyOrder 可以去连 shop 系统的从库。
但是一般，既然都分成了两个系统了，把边界也划分清楚。如果是我的话，还是去调用 shop 系统，在合并结果。

[stevefan1999]

你把微服務和微內核置換一下就知道你這問題和「宏內核 vs 微內核」的相似性了

[cabing]

肯定是有利有弊的，利弊都说了，最终还是要看执行的人了。

每个公司的架构也是在不断演进和优化的，不是一成不变的啊。

我只能说代码的架构一定程度上反映了公司技术部门的组织架构。。

[zmqking]

我曾经不记得在哪里看到过一段这样的话。就是说现在软件越来越臃肿，架构啥的也是越来越复杂，各种的思想，技术……其本质是：有些大公司在后面驱动故意这样搞的，这样才能让他们的服务或者软件越来越赚钱，比如像 SAP 之类的……

[lovedebug]

我觉得最大的缺点是写代码的某些人，没有大局观，没有从一个整体上思考，没有从业务流程上思考

[lovedebug]

微服务最重要的是：
Think in a whole symstem
Build for product(money)
Design for deploy

[cedoo22]

最大的缺点就是维护成本高。
业务没大到一定规模，项目维护成本大的弊端大于带来的开发灵活性优势。
另外，如果上了 docker, 可以很方便的扩展服务。

[charlie21]

你是不是想说，微服务的缺点就是怎么还没让那些不会微服务的程序员失业？

v2ex.com/t/642258#r_8544236
v2ex.com/t/640367#r_8518012
v2ex.com/t/637739#r_8480263

大龄程序员界的终极之问：吹不吹一个技术，不在于它好不好，而在于：它是否有助于让 35 岁以上不懂此技术的人立即下岗

[mywaiting]

微什么鬼服务，多数的业务根本用不上，WordPress 一条 /龙服务已经很足够了~

[Wizards]

@mywaiting 哈哈哈

[guolaopi]

@goldpumpkin
合并结果的方法我可以理解。

但是像你说的第一种，historyOrder 去连 shop 的从库的话，
假设使用 orm 操作数据，那么 historyOrder 和 shop 两个服务中应该会存在冗余的一些表的 model，
如果某天这个表结构发生了变化，两个服务都需要去修改相关的代码。。。

我觉得合并结果的话是多走一次服务间的通信，连从库的话开发的复杂度会变高。。
我还是跟你一样选择合并结果吧。。。。

[bw2015]

个人认为微服务不太适合小团队，本来一个人就要做好几个模块，弄成微服务之后一个人维护好几个微服务，工作量反而变大。
太过灵活也是这个问题，A 服务的人离职或者调去做别的项目，另外一个人接手的话，又得重新熟悉 A 的编码习惯。

[shidenggui]

我觉得每个架构都有其内在复杂度，在选择的时候要权衡自己的业务复杂度跟架构复杂度，我们的精力应该更多的用来处理需求变更，而不是技术复杂度。

[wd]

就和什么中台一样，大公司可能是解药，小公司就是毒药一份。拆分开之后一个人维护好几块东西，不累死

[graffitist]

难于应对连表查询的需求 这个有时候倒是真的

[ifconfig]

我只服气 53 楼

[Thiece]

我只服气 53 楼

[ffLoveJava]

我只服气 53 楼

[gemini767]

@guolaopi 首先确定主表，肯定先查历史订单，再查店铺信息

传输层的数据和 orm 肯定不一样，图省事吧 orm 的结构拿过来肯定会有问题

至于改底层结果，肯定会造成 Gateway 的一些改动，这个无可厚非，即使单体应用也一样，不过建议数据的 merge 在最上层做。

其实微服务的核心就是抽象业务，而非抽象技术。每个服务都是一个单独的业务服务就好了。

[guolaopi]

@gemini767
get 到了，我就理解成 soa 里企业总线做的事微服务里多调几个服务来搞定。

[CoderGeek]

小团队来说 微的优秀也是极好的适合增长的时候不用换轮子
当然业务不发展没需求 一把梭也没啥问题

大团队来说 个人感觉 超过一定规模的肯定有基础部门
配套组件这类 自然而然需要拆分 没什么好不好

[CoderGeek]

大点都是 soa paas saas ？

[ExploreWay]

仿佛在我的世界里没有出现过微服务，至少还没有真正体会过。

[chenqh]

@gemini767 那如果是店铺要自己的历史订单呢?分页呢？

[gemini767]

@chenqh 消费者的历史订单和店家的历史订单有区别么 :)

[chenqh]

@gemini767 你说你在 64 楼的回复是消费者的历史订单？ 那我就针对你 64 楼来讲
1. 如何分页？ 比如每页 10 条数据, 先从历史订单里面取 10 条？ 在 filter 店铺信息？
2. 假如有一个管理后台，产品提出，需要根据 用户名来查询 历史订单怎么做？ 关键还要有分页！

[xuanbg]

店铺信息的问题，也就是跨服务列表的问题，你们都不觉得是产品设计的问题吗？为什么一定要在列表中显示店铺信息？不能鼠标悬停或者点击后显示店铺详细信息吗？

[Actrace]

我认为是核心问题是缺少规范。
这基本上所团队协作型任务都要面临的问题。灵活的代价是降低开发速度，进一步受限于架构。这里我只想谈一下缺点，因为克服了缺点，不就万事大吉了嘛。

[lostpupil]

网络调用过多
微服务的本质就是调来调去，这么个没错，如果你说的是那种 http call 的话，的确造成一些不必要的延时是没办法的

技术栈太过灵活
灵活是双刃剑啦

难于应对连表查询的需求
没错，里面还可能不止一种数据库，要查询怎么都麻烦

核心应用崩溃会导致大面积瘫痪
熔断，限流我觉得并不能有效的防治应用奔溃不能用的事实，最多也就是让你损失的不那么多而已。

运维成本增加
能不手动的就不要手动，实际上设立了统一 CI/CD 风格后只有好处没有坏处，写代码也更有信息

接口风格不一致
Convention over configuration，这点也是因为技术栈的不统一导致的很多问题，PHP 有自己的想法，Java 也有自己的想法。

微服务的出发点是好的，对于前端人员来说，其实需要的想要的结果，以及统一格式的返回，至于后面发生了什么，怎么协作的，他们并不需要去 care，你用 56 种语言都没有问题，他们要的就是你统一格式的 json 而已。
还有我一直不认为只用 SpringCloud 这种厚重的东西写出来的能叫做微服务。
对于服务提供的后端来说，有一个统一风格的 数据库 ORM DSL 也是一个很好的解决方案，因为那些业务就是查询来查询去，插来插去，这个时候当前后端不能统一的时候，就需要一个 MiddleMan 来干这些脏活累活，就是所谓的中台，提供聚合好的东西。

没有银弹的，Serverless 也不是。

[gemini767]

@chenqh 还是要确定主表是什么，你要查询历史订单，不管什么条件，都是在历史订单里查询完，然后在 merge 店铺信息，不会你的订单里连店铺的 id 都没存吧？那是一个完成的订单系统么？

关于分页，不知道纠结点在那？ limit offset 不能用？

[slyang5]

大部分公司 把业务模块，分清楚就够了

[quan01994]

一般的公司只会一般的微服务，也就是把几个业务拆成几个独立的应用，然后在 k8s 中运行，就算微服务。
但是真正的微服务，有一套完整配置管理、服务发现、熔断器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态等等。

[guolaopi]

@xuanbg
虽然我也喜欢怼产品，但你说这个有点过不去了，
什么叫：“为什么非要在列表中显示店铺信息？”
就是有这个需求呗，不能啥都甩给产品设计有问题吧（凭良心
难不成因为这个不干了换公司？

[kim01]

码农一枚，个人觉得不能为了微服务而微服务，微服务是大型系统为了解耦、降低复杂度，各人负责各人的那一块就好，真到了要用微服务的级别你说的这些都不是问题，有真正的底层公共组件，有代码规范，有专业运维。好多在做微服务完全就是歪货。。。完全用不着而且加大了工作量

[chenqh]

@gemini767 那根据店铺名字来查找分页呢？

[gemini767]

@chenqh 难道不应该先根据店铺名查店铺 id，在查主表么？