关注
鸿蒙技术社区
，回复
【鸿蒙】
送
定制T恤
（限量20件，先到先得）
，还可以
免费下载
鸿蒙
入门资料
！
👇
扫码
立刻关注
👇
专注开源技术，共建鸿蒙生态
图片来自 Pexels
自从 2015 阿里巴巴提出中台概念和战略，“中台”这个技术术语逐渐火热起来。
尤其是从 2019 年开始，各类技术大会、各类公众号都在大力宣扬中台，出版社也趁着热点赶紧出版各类中台书籍，一时间中台有“旧时王谢堂前燕，飞入寻常百姓家”的感觉。
如果你跟人聊技术的时候，不发表一些中台的言论，不讨论一些中台的问题，那肯定会显得你技术有点落伍了！
如果我们仔细阅读这些文章，可能会发现一个有趣的现象，绝大部分谈中台的都是做中台的，很少看到用中台的人出来评价。
从人性的角度来讲，做中台的肯定不会说中台不好，毕竟还要靠这个恰饭，王婆卖瓜不自夸的话，买瓜的人自然会少。
偶尔有几篇说中台有问题的文章，例如《中台翻车纪实：一年叫停，员工转岗被裁，资源全浪费》、《中台，我信了你的邪 | 深氪》。
也很快会有人跳出来说“你们能力不行，所以中台没做好”、“中台是一个业务、组织、技术的协同，你们肯定是组织没保证”……
总而言之，现在到处都能看到做中台的人说中台如何如何好，偶尔有几个跳出来说不好的都会被质疑能力不行！
按照我的技术理念来看，没有完美的技术，没有放之四海皆好的技术，如果你只能看到一项技术的好处，而看不到坑，那实际上很可能就会掉到坑里去。
我虽然没有真正负责做过中台，但我做过平台和中间件，更为特别的是，我参与了两个基于中台的业务项目，一个项目是将手游交易系统迁移到电商中台，另一个项目是在支付中台上从 0 到 1 搭建一个钱包。
这两个项目让我亲自实践了一下在阿里和蚂蚁的中台上做项目，让我有机会近距离观察中台的运作机制，在一次次与中台的讨论、PK、撕逼的过程中，对中台也有了更深的理解和认识。
从我个人的经历和理解来看，目前关于中台的很多说法是言过其实、模棱两可、甚至是错误的，接下来我将给大家谈谈实际上的中台到底是怎么运作的，会有哪些坑。
由于我真正就是用的阿里电商中台和蚂蚁的支付中台，因此不用质疑中台能力不行和组织能力不行才会有我说的那些问题。
关于中台的价值，你看到的是这样的：
可以让各业务部门保持相对的独立和分权，保证对业务的敏感性和创新性；另一方面，用一个强大的平台来对这些部门进行总协调和支持，平衡集权与分权，并为新业务新部门提供生长的空间，从而大幅降低组织变革的成本。中台部门提炼各业务线的共性需求，最大限度地减少“重复造轮子”。
来源《一文读懂「中台」的前世今生》
实际上的中台是这样的：
①业务部门并不独立
基于中台的业务会被分为不同优先级，大业务对于中台的影响力远远大于小业务，核心业务对中台的影响力远远大于新业务。
形象点来说，中台抱大业务的大腿，小业务抱中台的大腿，因为中台也是有 KPI 的，中台的 KPI 怎么来？
当然是大部分了来源于支持的业务了，大业务天然会有 KPI 数据上的优势。
这会导致什么问题呢？大业务的创新不管是不是共性的，中台会鼎力支持，毕竟判断是不是共性需求是中台判断的，而不是每次有个新业务的时候拉上所有业务方来评估和投票。
小业务就比较悲催了，中台要拒绝你，只需简单一句话“你这个业务不通用”，“你这个需求太特殊”。
如果小业务不服气能怎么办？没什么办法，不会存在仲裁委员会之类的机构，就算有，你去仲裁的时间都够你自己把业务实现 5 遍了！
就算中台认为你的需求是共性需求，如果你是小业务，很可能也会以优先级的原因被排在很后面，这里的“很后面”可不是几天几周，很可能就是几个月半年了！
而恰恰很多初创业务一开始规模肯定是比较小的，基于中台的开发模式很可能会制约创新业务的快速发展，除非这个创新业务一开始就有重量级人物挂帅，对中台能够有足够的影响力。
②中台并不总是能够提炼共性需求
注意这里的需求不是指电商中台里面“交易”这个粒度的需求，而是指“交易”系统里面一个个实际的功能点，你要是坚持说“交易”是共性需求，这实际上是一句正确的废话。
事实上，提炼共性需求主要是中台从 0 到 1 的建设的时候，因为这个时候已经有多个业务需求的样本存在，哪些是共性哪些是个性是比较容易分析出来的。
但一旦建成后后续的业务发展和创新，中台和业务方天然存在对共性需求的不同诉求。
业务方总是期望将自己的需求划为共性需求，因为这样就能够让中台出人来实现需求。
中台总是期望先不要把需求划为共性需求，而是等到多个业务都有类似需求的时候再由中台来抽象提炼，这样才能最大化复用，否则中台每个需求都认为是共性需求的话，中台会累死。
而事实上几乎不太可能出现多个业务同时提出某个需求，除了国家颁布的法律法规相关的需求外，绝大部分业务需求都是由某个业务方先提出来的。
这个时候中台是无法判断是否为共性需求的，只能又回到前面说的潜规则来操作：优先满足大业务，怠慢小业务。
反正大业务的需求不管是不是共性的，做了后数据肯定好看，中台 KPI 有保证；小业务就算以后被证明是共性的，前期做了也没多少数据，中台很可能费力不讨好。
③中台的“轮子”会不断变化
很多朋友看到“避免重复造轮子”就以为中台把轮子造好了，业务方只管用就可以了，而实际情况是中台确实把轮子造好了。
但是它每隔一段时间就会把轮子换一遍，例如中台的数据模型、接口、架构等其实都是需要根据业务发展不断变化的。
为了达到中台“复用”的目标，通常情况下中台在推出新轮子后，就不会再长期维护老轮子，否则如果中台同时维护 4~5 个相似的轮子，复用就无从谈起。
这就要求基于中台的业务都必须在某个时间段内完成轮子的切换，相当于是业务方进行了一次被动架构演进。
当然，如果没有中台，业务方的架构肯定也要随着业务的发展而演进，那这和跟随中台被动演进有什么区别呢？
