踩过三年坑才明白：微服务架构设计不是越拆越细越好

一开始做架构的时候，我对微服务的理解全是网上搜来的鸡汤。 拆就完了。拆得越细，扩展性越强，团队协作越顺。 直到上线第一个月，我对着监控面板掉头发。 一个支付请求，跨了六个服务，挂了一个，全链路崩了。查问题的时候，开发推测试，测试推运维，运维推另一个团队的开发，整整一下午没找到根因。

一开始我也踩了“拆拆乐”的坑

前几年微服务风口起来的时候，不管是什么公司，开口就是“我们要搞微服务”，仿佛不拆服务就是技术落后，就是跟不上云原生的潮流。 我当时刚升架构师，心气高，老板一说要重构，吭哧吭哧花了三个月，把原来一个单体项目拆成了七十二个微服务。 现在回头看。 纯纯的浪费时间。 开发本地启动要跑十多个容器，机器内存直接干到90%以上，开机半小时才能调通一个接口。线上出了问题，链路追踪打出来十几层调用，眼睛都看花了也找不到哪里报错了。更坑的是，本来一个简单的事务操作，拆到两个服务里，还要搞分布式事务，复杂度翻了十倍不止，出问题的概率也翻了十倍。 过度拆分微服务架构调用链路图 说实话，那大半年我天天背锅，上线只要出问题，第一个找的就是我。我那时候还不服，觉得是别人运维不到位，是开发水平不够，直到后来跟阿里出来的前辈吃饭，人家一句话点醒我：微服务架构设计，拆分是手段，不是目的。你拆分是为了解决问题，不是为了凑数。 我才反应过来。 对啊，我当初拆分的时候，根本没考虑我们团队多少人，业务迭代速度是多少，现有架构的痛点到底是什么。为了拆分而拆分，纯粹是为了符合“标准微服务”的定义，给自己找麻烦。

合格微服务架构设计的三个核心判断标准

踩过坑之后，我总结了三个判断标准，每次做设计都拿出来过一遍，再也没出过大问题。 第一个，拆分粒度匹配团队规模。 你一个十个人的技术团队，搞出来五十个微服务，平均两个人管五个服务，谁能顾得过来？维护成本直接压垮所有人。说实话，我现在给中小团队做咨询，一般都建议他们拆分粒度不超过团队人数的三分之一，一个人管两个服务顶天了，多了真管不过来。 第二个，按照业务领域边界拆分，而不是按照技术分层拆分。 很多新手最爱犯的错，把所有的权限抽出来一个服务，所有的日志抽出来一个服务，所有的缓存抽出来一个服务，结果每个业务服务都要调用这些基础服务，本来本地化的操作变成了网络调用，延迟上去了，稳定性下来了。这完全是搞反了。微服务拆的是业务域，不是技术层。你做电商，用户是一个域，商品是一个域，订单是一个域，支付是一个域，这才对。把订单拆成订单接口、订单计算、订单存储，那叫没事找事。 第三个，数据低耦合，才拆服务。如果两个服务拆完之后，天天要互相查对方的数据库，隔三差五要联表查询，那说明你拆分的边界错了。要么把两个服务合回去，要么重新划边界。我见过太多拆分完之后，跨服务JOIN的操作比服务内部还多，那还不如不拆。 DDD领域驱动微服务边界划分示意图 不过话说回来，也不是说拆得粗就一定好。我之前见过一个公司，为了怕出问题，就把所有东西都放在一个单体里，团队二三十个人改代码，天天合并冲突，上线一次要测三天，这也是走了另一个极端。对吧？合适才是最重要的。

当下微服务架构设计的新变化你得知道

当下微服务架构设计的新变化你得知道 最近两年行业里的风向变了很多。之前大家拼谁拆得细，现在大厂都在喊“微服务粒度要适当”，甚至不少团队开始做服务聚合，把拆分太细的小服务合并起来，降低调用开销和维护成本。 还有一个很明显的趋势，就是云原生下的微服务架构设计，越来越偏向于让基础设施接管非业务逻辑。原来你要自己搞服务发现，自己搞熔断降级，自己搞监控，现在k8s加service mesh全都搞定了，架构师不用再花太多精力在这些东西上，把更多精力放在划业务边界上就好。 还有不少团队开始用Serverless做轻量微服务，那种流量波动大，迭代快的小业务，直接拆成函数，按需付费，不用管运维，爽得不行。当然，核心业务还是老老实实做常规微服务，不能乱试。 我前阵子跟腾讯做架构的朋友聊天，他说他们内部现在做微服务设计，第一句话不是问你要拆成几个，而是问你这个业务的痛点是什么。如果单体能解决问题，那就用单体，先跑起来，等业务真的大了，团队真的扩了，再慢慢拆。演进式设计，不是一步到位。 对哦，很多人忘了这点。微服务架构设计不是一锤子买卖，不是你一开始画好图就不能改了。你要跟着业务成长，跟着团队变化，慢慢调整。一开始拆太细，不如慢慢演进，边走边拆。 踩过这么多坑，我最大的感受就是，技术从来都是为业务服务的。不要为了赶时髦，为了凑所谓的架构标准，做一堆没用的设计，最后苦了团队，坑了业务，自己背锅。