微服务的缺点

[gansteed]

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

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

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

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

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

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

[mathgl]

join table 可以说是”当需要分库时怎么处理 join”

不管你用不用微服务都会面临的问题。