出了几次事故后，我们把全公司的中间件拆了|sdk|中间件|代码|回滚|密钥|调用

当初下决心封装，是被痛醒的甜头没吃几个月，账单就开始上门干这活的人，才是最委屈的我们的完整轮回：封装、膨胀、事故、拆分什么阶段做什么事，一张表说清五条掏心窝的话，替你省几场通宵写在最后

凌晨十二点半，公司大群突然弹出一条消息：「统一中间件出问题了，所有业务线暂停发布，等回滚通知。」那一晚，好几个团队的工程师同时从被窝里爬起来开电脑。问题不在任何一条业务代码上，而是出在那层谁都离不开、平时又没人多看一眼的「公共中间件」上。

我在这件事里从头熬到尾，也算把公司封装中间件的完整轮回亲眼看了一遍：从咬牙抽人封装，到越包越厚，再到几场事故之后亲手把一部分拆掉。今天把这段经历摊开讲，给同样在纠结「要不要封装中间件」的你，省下几场通宵。

公司还只有一条业务线的时候，日子其实挺好过。十来个人，各服务直接对接第三方 SDK，写法五花八门也无所谓，出了问题吼一嗓子就有人应。

变化是随着业务线一条条多起来发生的。同样是接一个短信服务，A 团队一套写法，B 团队另一套，日志格式、异常处理、重试策略全都对不上。真出了问题，光把各家代码翻一遍就得半天。

于是我们抽了人做统一封装，效果立竿见影：新人入职看一个示例就能接入，不用再啃几十页的官方文档；第三方爆出安全漏洞，中间件修一次、大家升个版本就完事；所有调用走统一入口，加个埋点就能看清调用量、成功率、平均耗时，限流熔断也能在同一层配置。连省钱都顺带了——短信通道对接好几家供应商，哪家便宜切哪家。

第一个坑是升级。你可能只是修了个小 Bug、改了一行代码，但这一行影响的是几百个服务。你得挨个业务线去协调：一起升级、一起测试、一起发布。但凡有一个团队正在赶需求排不进来，这版就推不下去；推不下去，那个漏洞就一直悬在头顶。

第二个坑是瓶颈。用户中心、权限服务、消息中心这些处在链路核心位置的中间服务，几乎所有服务都要调它们。有一次中间服务的数据库查询慢了 200 毫秒，结果全链路跟着超时，各业务线互相踩踏，像雪崩一样倒了一大片。

第三个坑最致命：中间件团队自以为改了个很小的逻辑，测试环境也跑通了，上线后一个没覆盖到的边界条件直接把所有依赖方拖下水。修复的时候要同时安排几百个服务的回滚或升级，那种感觉，就像给几百辆高速行驶的车同时换轮胎，车还不能停。

还有两个不那么显眼但同样磨人的问题。一是过度封装：业务方提一个特殊需求就加一个参数，加着加着，自己那层比官方 SDK 还厚，最后人家干脆绕开你直接用原生的。二是排查变难了：出了 Bug，业务方查到中间件那层就断了，得换中间件团队接手，再往下又是第三方 SDK，一来一回好几个团队陪着一个 Bug 转，加上层层代理和切面，堆栈信息看得人一头雾水。

上面这些坑，大公司人多资源多还能扛，小公司就更难了——通常没有专职的中间件团队，就是一个技术不错的人兼着：白天写自己的业务需求，晚上维护中间件，精力根本不够用。

更扎心的是这活的价值感。中间件做得好，没人夸你，一句「这不是应该的嘛」就打发了；出了问题，全公司都在问「怎么又崩了」。到了绩效季更尴尬，你维护的东西不直接产出业务功能，成绩根本没法写。

还有一个慢性炸弹：当初封装的那个人一旦离职，接手的人大概率不敢动那块代码。时间一长，它就成了一个谁都不敢碰的黑盒，只敢往上堆功能，越堆越臃肿，越臃肿越没人敢动。

复盘我们走过的路，基本就是一部中间件的兴衰史。

最早只有一条业务线，不封装是对的；后来业务线多了，同一个短信服务三套对接代码，有的服务还在用两年前的 SDK 版本，已知漏洞都没人知道——这个阶段抽人统一封装，也是对的。

问题出在后半段。服务数量滚起来之后，中间服务先扛不住，高峰期响应明显变慢；紧接着几次升级引入 Bug，几百个服务陪着回滚，业务线对中间件的信任就这么崩了。大家嘴上不说，行动上已经在「用脚投票」——有团队悄悄绕开中间件，直接接原生 SDK。

那之后我们开始「去中间件」。不是一刀切全拆，而是回归理性：SDK 类不再深度封装，官方的已经够好用，我们把精力挪到真正需要统一的地方——密钥集中管理、环境配置隔离；中间服务能并回业务线的就并回去，减少不必要的网络调用；只保留网关、认证中心这些真正值得独立部署的，重点砸资源做好高可用和降级。

这轮做完，调用链路明显变短，性能上来了，更要紧的是故障影响面小了——一个服务出问题，不再拖垮一大片。业务线拿回了自主权，迭代速度也跟着回来了。