微服务架构设计：别再为了拆分而拆分

去年跟一个做电商的朋友喝茶，他拍着桌子骂娘。说半年前听了某个架构沙龙的忽悠，把好好跑了三年的单体应用，硬生生拆成了十二个微服务。现在运维成本翻三倍，线上出问题查半小时还摸不到门，本来想提升迭代效率，结果团队一半人都在修拆分出来的跨服务bug。

拆分不是目的，解决问题才是

现在打开任何一个技术论坛，搜微服务，满屏都是教你怎么拆分，怎么落地，怎么上云原生。很少有人告诉你，你到底需不需要微服务。 微服务架构业务边界拆分示意图 说实话，很多人对微服务的认知都错了。微服务从来不是架构设计的银弹，更不是工程师简历上的装逼素材。微服务架构设计的核心起点，从来不是技术追新，是业务复杂度和团队规模到了那个份上，不得不拆。 你一个三个人的创业项目，月活还没过万，需求半个月换一次方向，拆什么拆？单体应用扔在云服务器上，一次发版十分钟搞定，不好吗？非要拆五六个服务，搞什么容器编排，服务发现，每天光是处理各种网络问题、依赖冲突都够你喝一壶。 康威定律说的很清楚，组织的沟通结构，就是系统的结构。你一个全栈小组包揽所有功能，非要拆分出十个独立服务，等于人为给自己制造沟通成本，不是有病吗？

那些踩了无数坑才总结出来的设计细节

真到了要拆的时候，也别瞎拆。我见过太多错得离谱的设计，说出来都好笑。 第一个坑，拆分粒度细得离谱。有人把用户登录拆成三个服务：账号校验一个，验证码生成一个，登录回调一个。三个功能本来就是强绑定，改一次登录逻辑，要改三个仓库，发三次版，拉三个开发对齐，这不纯纯浪费时间吗？拆分的原则从来不是越细越好，是按业务边界来，变化频率一致、强依赖的就放一块，别为了凑微服务的数量硬拆。 第二个坑，分布式事务追求完美强一致性。上来就要两阶段三阶段提交，把性能搞的一塌糊涂，上线之后用户点开一个页面要转三秒，谁受得了？其实百分之九十的业务场景，最终一致性足够用了。你电商下单扣库存，晚个三五秒扣有什么问题？真遇到极端情况超卖了，给用户发个十块钱优惠券补偿，成本比搞强一致性低到姥姥家了。 微服务分布式事务最终一致性流程图 第三个坑，网关变成了新的单体。很多人把权限校验、日志打点、流量染色、限流降级全堆进网关里，本来微服务是为了解耦，结果网关变成了新的单点瓶颈，一出问题全链路挂掉，所有人都等着网关的开发修bug，这不就是换了个地方做单体吗？说实话，网关就干好路由分发和基础的安全过滤就行了，业务逻辑别往里面塞，谁家的孩子谁家抱，每个服务自己处理自己的逻辑不好吗？ 还有个隐形坑，服务之间乱调用。A调B，B调C，C又调回A，一张调用关系图画出来像蜘蛛网，出了问题链路追踪追到脑壳疼，谁都不敢随便下线改代码。设计的时候就要定好规则，分层调用，只能上层调下层，不能反向调，跨层调用要走网关，别乱串。

当下的微服务设计，都在往合适的方向走

当下的微服务设计，都在往合适的方向走 不过话说回来，这两年行业风向变了。之前各大厂都在比谁拆的更细，服务数量更多，现在都开始往回找补了。 前阵子看字节和阿里的技术内部分享，不少团队把原来拆的太细的业务服务，又合并成了几个大的领域服务，运维成本直接降了三四成，接口响应速度还提了十几个百分点。很多人开始提倡渐进式拆分，就是不一开始就把全栈拆完，先从单体里把变化最快、最容易出瓶颈的模块拆出去，跑顺了再慢慢拆别的，不合适再合回去，弹性调整。 现在云原生普及了，容器、服务网格把很多基础问题解决了，反而大家对微服务架构设计的本质看的更清楚了。架构从来都是为业务和成本服务的，不是用来评架构师等级的工具。你做设计的时候，先算一笔帐：拆分之后，研发效率是不是真的提升了？故障影响范围是不是真的缩小了？带来的收益能不能cover多出来的机器成本、人力成本、沟通成本？算完这笔帐再动手，错不了。 我之前待过的一个SaaS公司，十个人的研发团队，就做一个面向中小商家的客户管理系统，一直用模块化单体，跑了五年，支撑几十万用户，没出过大问题，迭代速度一点不比拆微服务的慢。人家就不焦虑，也不觉得不用微服务就是技术落后。 很多人就是被营销焦虑坑了，好像不用微服务就是落伍，就是技术不行。其实哪有这回事。能解决你的问题，成本可控的设计，就是好设计。