技术中台构建，别把自己骗了

技术中台构建——这四个字一出来，就自带光环。但我今天偏要泼点冷水。很多公司把技术中台当成了万金油，仿佛上了中台就能解决所有问题。结果呢？钱花了，人累了，业务却在原地踏步。甚至更糟。 我见过一个真实的案例。某大型集团，业务线有五六条，彼此之间有一套重复的用户体系、订单体系。高层一看，这不行啊，太浪费了，立刻拍板要建技术中台。于是，抽调了各个部门的精干力量，成立了中台部。轰轰烈烈搞了一年多，经费烧了几千万，最后却只产出了一些毛坯级别的公共服务。业务方怨声载道，因为中台不仅没有让他们的接入更简单，反而多了很多流程。最后，中台部被解散，成员各回各家。 你说这怪谁？怪高层的盲目？怪中台的宏大设计？还是怪业务的抗拒？我觉得都有。但最核心的问题在于，他们违背了中台建设的初衷——**解决业务问题，而不是制造新的问题**。 技术中台分层架构与核心组件图

一、先搞懂中台到底要解决什么

不是所有公司都适合建中台，这句话我说一万遍都不够。技术中台构建的第一性原理，应该是 **“公共能力资产化”**。也就是把多个业务线重复建设的东西，抽出来统一建设。如果你们公司只有一条业务线，或者各个业务线之间的共享诉求很弱，那你建中台就是自娱自乐。 我有个朋友在创业公司，他们一开始就搞中台，结果就是拖慢整个产品迭代速度。因为中台团队要和多个业务方对齐需求，光沟通成本就占了三分之一。后来，他们索性把中台拆了，每个业务自己管自己的，反而跑得更快。所以，中台不是必需品，而是规模化后的奢侈品。别本末倒置。 有调研数据说，七成以上的中台项目最终沦为鸡肋。这话我信。那些失败的项目，大多不是技术不够，而是压根没想清楚要解决什么问题。

二、组织架构比技术架构更关键

技术圈的人都爱聊技术，但技术中台构建九成以上的失败案例源于组织层面的阻力。你要知道，中台的本质是权力的再分配。原来每个BU可以自己掌控的技术资源，现在要集中到中台，你猜他们愿不愿意？当然不愿意。所以，如果没有一把手的强力支持，你连想都不要想。 我自己在做咨询时，经常给企业提一个简单的建议：**让各业务线的负责人参与中台的设计与评审**。别让中台团队闭门造车。只有让业务方有参与感，他们才会把中台当成自己的作品，而不是殖民者。 此外，激励机制也很重要。有些公司鼓励业务团队贡献代码和组件，比如贡献一个公共模块可以获得额外绩效。这办法很土，但很有效。中台的构建不是几个人的事，而是全公司的事。

三、技术实现要克制，不要炫技

不得不承认，很多技术人员有怪癖——总想用最新的框架和工具。什么Service Mesh、无服务器架构、高并发利器，看见就想上。但技术中台的首要目标是稳定和易用。你整一堆分布式微服务，结果业务方调用还得搞半天，谁会用？ 我的经验是：**能用简单的方案，就不要搞复杂的架构**。比如，如果你的中台服务并发量并不高，那用单体应用+数据库索引优化就够了。别为了体现K8s的价值，强行把应用拆成几十个容器。这不是构建中台，这是表演技术。 技术中台与业务中台数据流转示意图 有一个思路值得参考：采用“薄中台”的策略。中台只保留最核心的共享能力，比如用户、认证、支付、消息等，其他业务相关的逻辑统统下沉到业务线。这样，中台的边界清晰，职责单一，就不会变成一个臃肿的大怪物。说白了，技术中台构建就是一场“减法”的艺术，而不是“加法”的热闹。

四、用数据说话，中台的价值要可以被度量

四、用数据说话，中台的价值要可以被度量 我见过太多的中台项目，验收报告写得天花乱坠，但实际却没什么用。为了避免这种情况，你在规划阶段就要定好度量指标。我的建议是，至少追踪以下三个指标：**服务复用率、业务接入耗时、系统可用性**。你不用追求绝对极致，但必须要有趋势。 举个例子，如果第一年服务复用率只有10%，第二年涨到了30%，这就说明中台在起作用。相反，如果接入耗时反而比之前更长，那就说明中台做得太烂了，需要反思。 最后，我想说的是，技术中台构建不是一场运动，更不是一块遮羞布。它是一个需要长期打磨的技术资产。别指望一蹴而就，也别因为短期看不到成果就放弃。如果你真的下决心要做，那就请尊重它的复杂度，从一个小痛点开始，一步步来。不然，你只会又一次验证“中台是个坑”这个说法。 共勉。