★ FEATURED ARTICLE 这几年总有人问我中台到底是个什么东西听各种分享会每个演讲者说的中台都不太一样翻技术博客微服务还没搞明白又冒出一堆数据中台、业务中台、技术中台。更离谱的是有的团队连项目都没跑顺张口就要建中台结果建完反而比之前更难迭代。所以我决定把这几年看到的、踩过的、复盘出来的关于中台的理解用一篇尽量不打官腔、不堆术语的文章讲清楚。不管你是写代码的、带团队的还是做产品的看完这篇文章至少能明白中台解决什么问题、什么时候该建、什么时候千万别碰。1. 中台到底是什么——从一个“县城餐馆”说起很多解释中台的文章会直接甩定义中台是介于前台和后台之间的一个共享服务平台。这个定义没错但对新人来说等于没讲。我换个说法。1.1 前后台之间的那段“怎么配合”的关系你现在脑子里先别装技术术语想象一家做外卖和堂食的中型连锁餐馆。门店负责接客、点菜、上菜这相当于互联网公司里的“前台”直接面对用户响应需求。后厨负责采购、仓储、财务对账、供应链管理这相当于“后台”支撑整个餐馆运作的关键基础。门店和后台其实天然拧巴。三个门店“A店”的菜单里有酸菜鱼“B店”也想上酸菜鱼于是B店自己买鱼、找人杀鱼、自己调酱料忙活半天。过了一个月“C店”也上了酸菜鱼又是从头折腾一遍。每次新店开张都要把买菜、切菜、调味、蒸煮这一整套流程重做一遍后厨累得半死菜品口味还不稳定。这时候有人提了个主意干脆建一个中央厨房把酸菜鱼的加工、酱料的调配、食材的预处理全部放到中央厨房统一完成三个门店只需要买现成的半成品加热、装盘、上桌三分钟搞定。这个中央厨房就是典型的中台。1.2 共享不等于复制中台是把“公用的能力”沉淀出来注意中央厨房的逻辑核心不是把三个门店的后厨合并而是把三家都需要的“做鱼能力”提炼出来做成标准化、可复用的半成品能力。门店不需要关心鱼从哪来、酱料怎么调只需要关心怎么更快更好地端给顾客。这就是中台和“统一后台”的本质区别——后台是强管控的是底层的财务、采购、基础设施中台是服务性的是往前台输出能力的。所以我的理解是中台是一种组织方式和架构思想的结合体。它不是某一个系统也不是某一个团队而是把多个业务线共同需要的“通用能力”沉淀到一个共享的平台上让前台业务可以快速调用、灵活组合、按需扩展。它的灵魂是“复用”和“共享”。1.3 中台不神秘它就是“公共的零件库”你可以把中台理解成一个高质量的公共零件库。以前每个生产线都自己开模做螺丝钉现在统一建了一个零件厂螺丝钉做得又便宜又标准所有生产线按需领取。万一哪天市场需要新型号零件厂调整模具所有生产线同步受益。但是请注意零件库不是越多越好更不是越全越好。很多人一听说中台就兴奋恨不得把订单、支付、库存、会员、营销、客服全部收拢到一个大平台里结果平台越做越重改一个功能要协调十几个团队上线周期从一周拉到一个月。这个坑太常见了后面我会专门讲。2. 中台为什么会出现——被“重复建设”逼出来的任何架构思想的流行背后都有一把辛酸泪。中台之所以火是因为前些年互联网公司多元化扩张业务线从一条变成十条原来的软件开发方式彻底撑不住了。2.1 业务线越来越多重复造轮子的成本藏不住想象一家公司本来只做团购后来开始做外卖、做旅游、做电影票。每开一条业务线都要建一套用户系统、支付系统、订单系统、促销系统、消息系统。说起来都是“基于现有组件改造”实际上每个项目组都有自己的实现方式。我见过一个真实场景一家公司同时有五个项目组每个项目组都维护了一套独立的“优惠券引擎”。有的用规则引擎有的写死判断逻辑有的甚至用数据库存储过程实现。五套系统的接口五花八门业务规则互相矛盾同一张券在不同业务线里的过期时间算法都不一样。最离谱的是等项目一多没人说得清到底哪套是对的想修一个历史 bug 得翻五个仓库。前台的业务跑得越快底下的债务就堆积得越快。每个月的发版日各个项目组都在改自己的支付回调、改自己的用户权益、改自己的消息模板人力全部耗在“重复造轮子”上真正能给业务带来增量的事情反而没时间干。2.2 单体、微服务、中台一条被逼出来的演进路径最早的时候大家习惯写一个大型单体应用所有功能揉在一个工程里代码全部拉通。业务简单的时候没问题业务一复杂一个工程几千人维护合并代码都能吵起来。于是微服务出现了——把大系统拆成小服务按业务边界隔离团队各管一块。微服务解决了一部分问题但它没有解决“不同业务线之间公共能力怎么统一”的问题。订单服务拆出来了但是外卖线有外卖线的订单服务旅游线有旅游线的订单服务依然是各建各的。微服务解决的是单个系统内部的“职责分离”中台解决的是跨多条业务线之间的“能力复用”。所以可以这么理解演进逻辑单体是每个人家里都挖一口井微服务是每栋楼里做一个供水房中台是整个小区做一套统一供水系统按需接水管到每户。技术是手段“公共能力共享”才是目的。2.3 中台本质上首先是组织问题其次才是技术问题很多人把中台理解为“上几个系统、写几套服务”这是最大的误解。如果团队仍然是“前台项目组自己说了算绩效各管各的业务各自垂直垄断”中台根本建不起来。我举个例子。某家公司的“会员积分”功能被中台化了按理说所有业务线都应该接入。但是某一个强势业务线的负责人觉得中台返回的字段不满足他们需求而且他们要等排期干脆自己重新开发了一套积分系统。结果半年后公司里有两套会员积分系统财务对账的时候数据对不上。后来复盘的时候发现问题的根子不在技术在于没有从组织上规定“哪些能力必须由中台提供前台不能私自另起炉灶”。中台必须伴随组织边界的调整。得有明确的治理机制谁是中台的负责方哪些能力归中台管前台想要新能力怎么提需求冲突了谁拍板。没有这些中台就是空中楼阁。3. 中台常见形态——别一上来就“全都要”中台这个词被玩坏的一个重要原因是大家把一堆类型混在一起讲。至少有几个常见的形态需要区分清楚不然讨论半天可能说的根本不是同一个东西。3.1 业务中台把通用的业务能力抽出来业务中台是最接近“中央厨房”概念的一种。它沉淀的是各个业务线都需要的通用业务能力比如用户账户、订单交易、支付结算、商品管理、营销活动、库存中心。以“订单交易”为例。电商业务有订单外卖业务有订单线下零售也有订单。虽然场景细节不同但“创建一个订单 → 锁定库存 → 发起支付 → 支付回调 → 物流履约”这个主干流程是一致度很高的。业务中台要做的就是把主干流程统一实现把差异部分做成可配置的扩展点。常见的做法是把订单拆成“订单核心”和“订单场景”。订单核心中台化管理负责订单创建、状态流转、金额计算订单场景由前台业务自己实现负责外卖的“预计送达时间”、电商的“运费模板”、零售的“自提核销码”。这样既保留了共性又允许场景差异。3.2 数据中台不是建数据仓库那么简单数据中台和业务中台经常被混为一谈实际上它们的目标不同。业务中台是让业务跑得更快数据中台是让数据发挥价值。很多公司一拍脑袋把所有数据汇总到一个大数据平台然后对着屏幕看一堆报表就说自己建了数据中台。这是本末倒置。数据中台的核心是“数据资产化”和“数据服务化”。什么叫数据资产化你得把散落在各个业务系统的用户数据、商品数据、交易数据统一清洗、建模、打标签形成一套口径一致的数据标准。否则业务部门看的“用户数”和财务部门看的“用户数”不是同一个数字讨论起来全是扯皮。什么叫数据服务化就是不能只让数据分析师自己用 SQL 查表而是要把常用的数据能力包装成接口比如“用户画像查询”“商品推荐向量”“实时订单指标”让前台业务系统可以按需调用。比如推荐系统需要用户最近30天的品类偏好直接调用数据中台的画像服务而不必自己写复杂的数仓查询。这里有一个“某零售平台”的例子。它们有线上线下两条业务线大家都有会员运营需求。之前线下和线上各看各的会员数据一个用户在线下是金卡会员、在线上却是普通用户体验非常割裂。后来建了统一的数据中台打通全渠道会员身份定义统一的会员等级规则两个业务线都从数据中台拉取会员数据。这才让“全渠道会员通”落地。3.3 技术中台、算法中台和其他乱七八糟的“中台”业务中台和数据中台是两条主线除此之外还有技术中台、算法中台甚至组织中台。技术中台比较好理解就是把各个项目组都要用的技术基础设施沉淀成公共能力比如统一的消息队列、统一的分布式事务框架、统一的日志平台、统一的对象存储。以前每个项目组自己搭一套监控系统现在统一建一个“技术平台”项目组开箱即用。算法中台专门沉淀通用的算法能力比如人脸识别、文本审核、智能推荐、风控评分。这些算法能力训练一次、多次复用。比如“文本审核”能力社区发帖要用用户评论要用私信聊天也要用没有必要每个场景各训练一套模型。这里要特别提醒一句中台不是一个筐不是什么都能往里面装。我看到有的公司把项目管理工具、工单系统、财务报销也归到“中台”里这其实是内部服务平台跟“支撑前台快速迭代”的中台根本不是一回事。强行叫中台只会让概念更加混乱。3.4 类型之间怎么选取决于哪个环节最痛很多团队问“应该先建业务中台还是数据中台”这个问题没有标准答案只能看痛点。如果你们公司现在最大的痛是新业务线开发周期太长每个项目都要从零开发用户、商品、订单那么应该优先做业务中台。如果痛点是管理层看不到全局数据各部门报表口径打架数据资源浪费严重那么应该优先做数据中台。如果你们的主营业务强烈依赖智能能力比如个性化推荐、内容审核那么算法中台就是第一优先级。如果你们的主要问题是系统稳定性差技术基础设施重复建设严重那就先建技术中台。我自己见过的最典型的错误是公司业务还在摸索期核心商业模式都没跑通却花重金把业务中台、数据中台、算法中台一次性全建了。结果中台团队比业务团队还大前台做任何小改动都要过中台排期整个组织的迭代速度肉眼可见地慢下来。中台建设必须跟着业务成熟度走切忌一步到位。4. 建设中台的完整思路与实操要点如果你想在团队里推动中台化或者至少让自己想清楚这件事我建议按下面的思路走一遍可以规避掉大多数天坑。4.1 动手之前先回答四个问题问题一你们目前有多少条业务线有没有超过三条如果只有一条业务线那中台的价值非常有限因为“共享”的前提是“有人来共用”。问题二各业务线之间是否存在大量重复代码、重复系统、重复团队你可以做个盘点统计不同项目里功能重叠度最高的模块比如支付、登录、权限、消息、文件上传看看是不是每套系统里都有一份。问题三中台化能够带来的效率提升能不能抵消“集中化”带来的协调成本这是最核心的账。集中意味着走流程、排期、协调如果业务场景本身差异化极大、变化极快集中化的中台反而会成为瓶颈。问题四公司高层有没有足够的决心推动组织调整如果老板觉得“中台就是搭一套系统技术团队自己搞就行”那我可以明确说这个中台大概率做不成。中台建设首先是治理层的工程其次才是技术层的工程。4.2 五步落地中台盘点、抽取、沉淀、接入、治理第一步是盘点能力地图。别急着写代码先把公司所有业务系统的核心能力列出来用矩阵的方式标出哪些能力在多个业务线里重复出现。做这一步最常见的工具就是一张大表纵轴是能力会员、订单、支付、库存、营销、消息横轴是业务线交叉位置标出“是否自建”“技术栈”“关键负责人”。第二步是选取试点场景。千万不要一上来就把所有能力中台化先选一个重复程度最高、业务逻辑相对稳定、改造成本可控的能力。我强烈建议从“用户账号”或者“消息推送”入手这两个模块边界清晰部门归属争议小容易快速见效。第三步是公共能力沉淀。把试点能力的公共部分抽离出来做成中台服务。这一步要特别注意两点一是明确对外接口协议尽量一次定好避免频繁破坏性变更二是定义业务扩展点给前台留出定制空间。第四步是分批次接入前台。任何中台服务上线初期都要经历磨合期别指望一刀切强制切换。可以先选一个团队配合度最高的前台业务试接入跑通流程、验证稳定性再逐步推广到其他业务线。第五步是建立持续治理机制。中台不是建完就一劳永逸它的接口会被越来越多的团队依赖所以必须有变更评审、版本管理、兼容性保障机制。很多中台团队忽略这一点改一个字段名就敢直接上线结果把下游的所有业务线全部搞挂了。4.3 中台团队怎么搭架构组、平台组、接入组的分工组织设计上至少要三类角色。第一类是“架构治理组”负责制定中台的技术标准、接口规范、数据模型人数不需要多但必须是在公司里有技术影响力的人。第二类是“平台功能组”负责核心功能的开发维护按能力域划分小队比如用户小队、订单小队、支付小队。第三类是“接入支持组”有点类似技术顾问的角色专门帮助前台业务接入中台解决接入过程中的各种问题。很多中台团队把这三种角色混在一起中台工程师既要做平台开发又要做接入支持结果每天疲于奔命代码质量也很难保障。我见过做得比较顺的团队是让“接入支持组”和前台团队物理坐在一起办公随时响应和解决接入问题这样中台推进阻力会小很多。这里必须提一个组织上的红线中台团队不能只考核“自己交付了多少功能”还要考核“下沉能力被多少前台团队复用了”甚至要考核“前台业务因为用了中台节约了多少开发时间”。否则中台会自娱自乐做出一堆没有业务使用的高大上服务。4.4 技术层面的几个务实建议技术选型不要追新很多团队一上中台就搞服务网格、搞 K8s、搞全链路异步化结果基础能力没沉淀先把复杂度拉满。中台的核心是业务能力的复用不是技术细节的炫技。接口设计尽量以 http JSON 为主如果你觉得内部服务性能有瓶颈再考虑更高效的通信协议。尽量让中台的 API 做到无状态方便水平扩展对跨服务的调用要加链路追踪否则出了问题就变成“甩锅大会”。数据层面最容易出问题。多个业务线共用一套中台数据库的时候必须严格区分“中台数据”和“前台数据”。中台只保留最核心、最公共的数据比如用户 ID、账户余额、订单主状态前台的个性化数据比如用户在某业务线自己定的“偏好标签”“收藏夹排序”坚决不放进中台。过去见过一个团队中台把用户标签全接走了结果每个前台业务都要传额外的自定义字段接口变得臃肿得令人窒息。另外中台服务一定要设计好容错机制。中台一旦核心宕机影响的是所有接入的业务线所以必须做降级方案。最典型的做法是前台调用中台超时的时候快速失败并降级到本地兜底数据保证核心流程还能走通而不是让全网用户一起报错。5. 中台落地中的常见坑与排查心得前面讲了方法和框架这些是我综合复盘很多团队之后的经验总结。下面这部分的“坑”大部分是我自己或者身边朋友踩过的真实教训拿出来当反面教材比成功经验更有参考价值。5.1 最大的坑中台变成了“大后台”前台反而被拖慢中台建设最讽刺的结局是原本为了“让前台更快”而建的中台最后变成了前台最大的瓶颈。早期某个做本地生活的平台把订单、支付、商户、营销、消息五个核心域全部中台化然后所有需求都要通过中台排期。结果前台要做个“满减活动”中台说营销组件排到三周后前台要做个“新客立减”中台说支付流程改动需要评估一周。前台团队实在受不了开始采取“绕过中台、另开旁路”的方式做应急功能系统里出现了越来越多“中台管不到”的黑洞逻辑。这个问题背后的本质是中台的能力池跟不上业务的快速变化。中台服务很容易陷入“公共性”的执念什么功能都想要通用化一套逻辑覆盖所有场景结果每个场景的适配成本全部转移到了前台。更合理的方式是中台只做“稳定且通用”的部分把易变的部分通过插件化、可配置化、甚至直接下沉给前台实现。5.2 共性抽取的度抽得越狠崩得越惨建设之初“共性抽取”是大家最喜欢做的事。设计师们聚在一起恨不得把 80% 的功能全部抽成公共组件。我见过一个团队做“消息中心”把站内信、短信、App 推送、邮件模板全部抽象成一套引擎配置项多到运营根本看不懂最后连最简单的“给特定用户发一条短信”都要提前配置半天。正确的做法是做“差异分析”。把各业务线的相似流程排在一起逐项对比哪些环节是完全一样的哪些是结构相同但参数不同的哪些是结构本身就不同的。完全一样的才放进中台参数不同的做成配置项结构不同的坚决不管。有些团队把精力花在抽象上而忽略业务实际使用的频率这个方向就反了。5.3 数据中台最容易翻车的三个点数据中台单独拿出来说因为它的坑和业务中台完全不一样。第一个坑是“口径混乱”。同一个指标有的部门按下单时间统计有的按支付时间统计有的按发货时间统计。没建立统一的数据字典之前面板上显示的数据都是各说各话。数据中台建设第一步永远不是搭建引擎而是梳理指标体系、业务口径、维度定义把“用户”“订单”“GMV”这些名词定义清楚。第二个坑是“数据质量不受控”。业务系统的数据脏是常态但从前没人管。数据中台一旦上线前端业务直接消费数据服务脏数据的危害会被放大。比如一个用户有两个重叠账号画像服务查询时没有做 ID 合并推荐的商品完全不相关。数据质量是数据中台的生命线必须有专门的数据质量监控及时性、完整性、准确性每一个维度都要有可观测的指标。第三个坑是“业务没有用起来”。很多数据中台团队埋头做数仓建模构建了一堆主题域但业务方看得一头雾水不是嫌数据不够细就是嫌查数据太慢。数据中台不是建成一个“取数平台”就完事而是要把数据能力和业务场景深度绑定。最有效的推动方式是选定一两个高价值场景先落地比如“用户全生命周期管理”让业务方直观感受到数据的价值之后推广自然顺畅。5.4 衡量中台价值别只看“建成了什么”要看“复用了多少”中台项目启动之后很多团队爱汇报“已经建成了 20 个中台服务”。但这个数字毫无意义。真实有效的度量指标应该是有多少业务线正在使用这些服务、这些服务为前台节约了多少人力、中台服务的复用率从月初到月末有没有变化。我一个朋友所在的团队引入了两个指标。一个是“前台平均接入一个新业务线的时长”从原来的 3 个月降到 2 周这是最直观的体验。另一个是“重复代码率”通过静态扫描统计各个系统公共模块的重复度从原来的 40% 降到 12%。这两个指标比“上线了多少个服务”实在得多。还有一个容易忽略的评估维度是“返工成本”。中台的接口设计如果有问题返工成本是乘数的因为所有接入方都要跟着改。因此中台团队在接口设计上要格外谨慎建议重大接口升级时多花时间做评审和兼容方案不要怕“慢”慢一点写清楚后面省下的时间是好几个量级。6. 没有中台的公司怎么办——轻量级实践思路看到这里你可能会想我所在的公司只有一条业务线或者团队只有几十个人中台是不是跟我完全没关系其实不是。中台的思维方式是可以降维使用的。6.1 先别上中台概念把“公共能力”梳理出来小团队不需要建设一个组织中台但是可以建设一个“公共能力清单”。每开一个新项目先对照清单看看有哪些能力是之前已经做过的可以直接复用或者稍微改改就能用有哪些能力是全新的需要考虑沉淀到公共模块里。比如你是一个做多个小程序的技术负责人三五个小程序都要做“登录授权”与其每个项目复制一份“登录工具类”不如单独抽一个“登录模块包”统一维护发布到团队内部代码仓库。这就是微缩版的中台思想把重复劳动变成一次开发、多处复用。6.2 用“共享组件库”和“服务分组”代替宏大平台小团队最怕在组织上搞“中台部门”。两三个人的中台小组被前台团队追着提需求日子很难过前台也不满意。更现实的做法是把公共代码放到共享仓库让每个业务线自行引用由一位核心成员负责组件库的维护和技术决策。比如你团队里有三条业务线都用同一套“后台管理脚手架”你可以把这套脚手架抽成独立的代码仓用版本号管理。业务线升级脚手架时自己选择合适的时间窗口不强制同步。这样既享受了复用的红利又避免了集中式平台带来的“被迫排期”问题。6.3 演进路线从模块复用 → 服务沉淀 → 真正的中台轻量实践的起点是代码级复用演进到一定程度后如果发现多个系统都需要通过网络接口来调用公共能力就可以把公共能力升级为独立服务。多个独立服务越来越多逐步形成服务目录这时候再考虑成立专门的小组去治理这些服务这就离真正的中台越来越近了。这条路是一步步走出来的不是老板一声令下“我们要建设中台”就能跳级实现的。我看到过很多公司连代码复用都做不好就敢直接组建几百人的中台团队最后的结果往往是中台产出跟不上业务需要业务线怨声载道项目草草收场。6.4 给想推中台的朋友几句掏心话这些年关于中台的讨论起起落落前几年很多人疯狂追捧这几年又有很多人唱衰。我的看法比较简单中台不是银弹也不是骗局它就是一套“识别并沉淀公共能力”的思路。真正让中台失败的往往不是技术选型不对而是组织无法承载共享的复杂度。如果你所在的公司多条业务线之间有明显的重复建设有价值稳定的公共能力有愿意在组织层面做出调整的决策者那么中台确实值得认真做。反过来如果业务还处于快速试错阶段团队规模也不大那么对“中台”保持敬畏用轻量共享的方式慢慢演进比一步到位更稳。我个人在实际操作中的体会是中台项目最怕“两头不靠”既没有真正解决前台的痛点又增添了大量的跨团队协调成本。所以不管你参考了多少方法论最后一定要从小范围试点做起用第一个成功案例去说服更多的业务线用看得见摸得着的效率提升来证明价值。这条路走起来没有捷径但每一步都算数。
阅读完成 · 觉得有帮助？
