微服务的缺点

[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]

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