别再堆服务器了：技术中台构建里藏着的那些踩坑日常

去年9月23号，我在南京河西那栋玻璃幕墙的办公楼里，对着满屏的报错喝第三杯冰美式。 客户的技术负责人蹲在我旁边，手指戳着屏幕上的订单超时日志，说我们去年砸了两百万上的中台，怎么现在比没上的时候还乱？ 我盯着屏幕看了十分钟。 真的乱。 订单接口的超时日志里，混着优惠券服务的鉴权报错，混着库存服务的连接池满提示，连带着用户中心的登录接口都跟着挂——因为他们之前想当然的把所有服务都挂到同一个网关上，线程池就那么大，一个服务被流量打满，整个链路全崩。

你以为的中台，和真的能跑的中台差在哪

很多人对技术中台构建的第一反应，就是把各个业务线写的接口都搬到同一个仓库里，搭个统一的网关，就敢说自己有中台了。 根本不是那回事。 之前这个客户的架构，说出来有点好笑：用户中心是三年前订单部为了做下单功能写的，优惠券接口是市场部去年做活动的时候临时赶出来的，库存服务是仓储部自己维护的。三个服务各有各的鉴权规则，各有各的日志格式，各有各的数据库表名，连个统一的错误码都没有。上次排查个优惠券核销失败的问题，翻了三个代码库，找了半天才发现是库存接口返回的错误码跟用户中心的定义撞了，系统直接把错误吞了，用户付了钱，优惠券没扣，库存也没减。 他们之前的“中台”，就是把这三个接口都挂到同一个公网网关上，连个限流规则都没配。 电商技术中台服务依赖拓扑示意图 真正能跑的技术中台，核心的抽离标准从来不是“把服务放到一起”，而是能被三个以上业务线复用、且逻辑变更频率远低于业务迭代频率的能力。 比如“获取当前登录用户的基础信息”这个能力，不管是做订单、发优惠券、处理售后，甚至是做内部的员工管理系统，都要用到。这个逻辑的变更频率极低——你总不能天天改用户ID的生成规则吧？这种能力，抽成独立的服务，配统一的鉴权中间件，统一的日志埋点，统一的限流熔断，这才叫中台的最小单元。 那些只有某一个业务线用的逻辑，你抽到中台里干嘛？给自己找活干吗？

从0搭的时候，别上来就铺全栈

我当时跟这个南京客户的CTO说，别信那些咨询公司画的“三年中台战略”大饼。 你现在最痛的点是什么？ 是每次做活动，都要重复写一遍用户身份校验、优惠券核销、库存扣减的逻辑，每次写都出bug，每次出bug都要熬到凌晨三点改代码。 那就先从这三个点切入。 别上来就搞什么全链路的用户画像中台，什么智能推荐中台，那些都是虚的。 我们当时花了两周时间，把原来散在各个项目里的这三段逻辑，抽成三个独立的服务：统一的用户身份服务，统一的优惠券核销接口，统一的库存扣减接口。每个接口都配了固定的限流阈值——比如库存接口最多每秒处理1000个请求，超过的直接返回排队提示，绝对不允许占满整个系统的线程池。 就这么点东西。 微服务架构下统一优惠券核销流程示意图 结果上次双11，他们的活动页面扛住了平时8倍的流量，没出一次大的故障。那个之前觉得“中台不够高大上”的CTO，现在逢人就说，别上来就搞大而全的东西，先把最痛的那根刺拔了再说。 哦对，我见过太多团队上来就铺全栈的中台：什么统一消息中台，什么文件存储中台，什么数据中台，搭了半年，业务线根本没人用。为什么？因为你搭的东西，根本不是业务线当下最需要的。业务线现在就想要个能快速发优惠券的接口，你给人搞一套复杂的用户标签系统，谁有空学你那套配置规则？ 中台从来不是用来炫技的。它是个工具，工具好不好用，要看用它的人愿不愿意伸手拿，不是看它的架构图画得有多漂亮。

那些没人告诉你的中台边界

很多人对中台有个误解，觉得只要上了中台，就能一劳永逸的解决所有重复开发的问题，就能让所有业务线的效率提升一倍。 别扯了。 中台有明确的边界。 首先，不要把强业务特异性的逻辑塞到中台里。比如那个南京客户，之前想把“用户生日当天发100元无门槛优惠券”的逻辑抽到中台里，我当时就拦下来了。为什么？因为这个规则是市场部拍脑袋定的，下个月可能就改成“用户注册满一年发优惠券”，下下个月可能就改成“只有会员用户才有资格领”。这种逻辑变来变去的东西，你放到中台里，以后改一次规则，中台的团队要跟着改一次代码，还要协调所有用到这个逻辑的业务线做回归测试，纯纯的无效劳动。 我见过最离谱的中台，把“直播带货的时候给主播加个弹窗提示”的逻辑都放到中台里了。结果后来主播说弹窗的位置要从右下角挪到左下角，中台的团队改了三天代码，还漏了两个业务线的调用，导致那场直播的时候，有三个直播间的弹窗位置不对，被运营骂了整整一周。 图啥呢？ 其次，中台不是越大越好。很多团队的中台团队越搞越大，几十号人，天天琢磨着怎么给中台加新功能，却从来不去问业务线到底需不需要。最后变成了中台自己玩自己的，业务线为了不用中台，甚至会偷偷在自己的项目里重新写一套相同的逻辑，美其名曰“灵活定制”。 那个南京客户现在的中台团队就三个人。 专门管最核心的三个服务，别的业务逻辑，全部让业务线自己搞。上次他们要做新的直播带货业务，直接调用现成的用户、优惠券、库存接口，两周就把业务上线了。要是搁以前，至少要两个月。 昨天那个CTO给我发消息，说他们现在打算加一个统一的支付回调服务，把原来各个业务线自己处理的支付通知逻辑抽出来，省得每次接个新的支付渠道，要改好几个项目的代码。 我回他说，你这就对了。 技术中台构建从来不是什么高大上的企业战略。 就是你干活的时候，发现哪些事你已经重复做了三遍以上，就把它抽出来，做成个谁都能拿来用的工具，仅此而已。