微服务的缺点

[gansteed]

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

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

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

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

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

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