我的中台的理解

在思考这个问题很久之后，我终于悟了，跟大家分享一下。

• 第一，我们要理解，「中台」是一个完全中国土生土长的概念。也就是说除了中国在其他任何地方都没有这样一个概念。这意味着，「中台」这个词的定义权和解释权是完全国有的、独有的。
• 第二，有说法把「中台」视作是「微服务」的一种，这是错误的。虽然「微服务」的定义真的是五花八门，但相信对于「微服务」是要「把服务拆小并独立运作」这件事，大家都没有异议。而「中台」，虽然中文博大精深，但无论「中」指的是「中间」还是「中心」，都与「独立运作」背道而驰，而「中心」则更是违背了「拆小」的思路。所以，「中台」绝对不是「微服务」的一种，而且是反其道而行之。
• 第三，也有说法把「中台」视作是「分久必合，合久必分」的，这倒是符合中台的定义，但其合理性值得商榷。这种说法的隐含意思是一个已经高度分布式的架构，是可以再「合」起来的。这怎么说，除非业务要垮杆了，否则用脚指头想想这都不可能好吗？一个已经服务细致拆分，形成内部复杂网状结构的分布式架构，以及与之对应的研发组织结构，除非是翻天覆地的暴力革命，是不可能再合起来的。任何一个了解软件工程，有深刻技术背景的人都不可能说得出这种话来。

那么，如果删掉所有这些虚头巴脑的东西，中台到底在说什么？

最后，终于发现问题所在：「中台」根本就不是一个技术和架构的概念，而是一个业务概念。拿它去跟 ESB、微服务去对比，本身就不合适。可要是把它当做是一个业务概念，就很好解释了。

为什么大家都需要支付，就要把支付拆成一个「中台服务」？

其实这并不是意味着支付变成了一个架构上的「单点」，而只是说「支付」这个功能应用化了（或者说 API 化了），大家都可以调用，仅此而已。至于这个应用本身是一个分布式的，还是集中式的，还是与其他服务共享底层架构，其实根本没有所谓。

如果接受这样一个设定，那么我们可以大概梳理出现在各种「中台」介绍中的思路，解答一些问题。

为什么只有中国有「中台」这个说法？

因为在别的地方，这个东西根据场景的不同，会被叫做 SaaS、API、应用层服务、微服务、ESB，甚至可能被叫做「标准」。比如之前有个场景，有国内记者问微软 AI 的老板「微软有没有 AI 中台？」的时候，后者完全不明白在问什么，但如果问题变成「微软的 AI 有没有开放的 API？」或者「微软有没有应用层的 AI 服务，比如语音转文字、语场景识别？」相信后者马上就可以做出解答。

既然「支付」可以是「中台服务」，那么「大数据」是不是也可以「中台服务」，「订单」呢？

一个事情是不是可以拆成一个单独的服务，跟公司业务所处阶段有很强的关系。新成立的公司或者全新的业务，什么服务都不拆是最好的，这时候也不存在中台不中台的问题。稍微发展之后，或者大公司的新业务，很有可能在一开始就严格要求全面 API 化，这个时候一套完整的、公开的 API 其实就已经是一个所谓的「中台服务」。

比如早在 2002 年，亚马逊就曾经有著名的「人形 API 命令」（The Human API Mandate），贝索斯要求所有的服务都必须 API 化，并在一开始的时候就考虑对外开放 API 时的需求（安全、验证等），这已经是完全把服务推向 SaaS 的方向去了。

对于「大数据中台」，我表示深刻怀疑。

大数据以及 Hadoop 生态等的出现和蓬勃发展，本身就是分布式计算的最佳证明。如果我们仍然需要通过一个统一的中心来规划数据的收集、存储、整理、统计，那就相当于用分布式计算来做了集中化的事情。这个就上升到意识形态了，你信教堂，你就得教堂，你信集市，你就得集市。我个人相信大集市，小教堂。

对于「订单中台」，我同样表示深刻怀疑。

「订单」是无数应用都会需要用到的资源，毫无疑问对于能横向看到顶层设计的人，会有强烈的把订单做成一个公共服务的倾向，这一点和「支付」非常类似，没有毛病。可是，「订单」又是一个高度定制化的资源，每个业务对于订单的定义、理解、语义要求都非常不一样，这让抽象变得极其困难。而且订单几乎都与核心业务直接相关，如果要抽象出一个订单中台，很大程度上会要求订单团队对所有核心业务都要有深刻理解，应用和业务越多，这个事情变得越不显示。

此外，抽象意味着对所有调用你的服务负责。如果一个服务发展了，需要新的字段，应该怎么办？如果一个服务删除了，需要删除某个字段，应该怎么办？这么多服务都要定制订单，哪个优先？这些问题本来都是各自团队去思考解决，但现在都变成了订单团队的问题。而订单团队本身是不产生业务价值的，所以其价值判断（换句话说就是 KPI）会变得非常困难。

所以，把订单做成中台，无异于把原来已经封装好的服务中的一个组件抽出来做成了一个公共服务，这其实人为的增加了复杂度。

当然，也有说法，说「订单」中台只需要「最基本的字段」，而实际的定制化全部发生在服务。

这个说法倒也没错，但请问，如果一个订单里面只有一个订单号，这个还叫订单中台么？不能了吧，没这么简陋的中台。如果说加上最基本的产品和价格呢？好，那么，没有价格的占位的订单怎么办？拼团的价格不停在变的订单怎么办？订单合并怎么办？没有产品的，比如住宿的订单呢？比如演唱会的订单？产品是使用名字还是 SKU ID？

最后就会发现，这个订单中台，要不然特别复杂而且低效，要不然就简单到其实只是存了一个共键而已。为此，我对订单中台这个事情深刻怀疑。

个人对于什么样的东西可以拆成中台，有这么一个简单的判断。

一个事情，如果它本身是自给自足的，脱离内部输血之后，它还有存在的必要，有人愿意为它提供的服务付费，那么它就是可以拆成中台。在这个定义里面，没有技术成分，这是一个纯业务的定义。

比如「支付」。这是一个大家都需要，然后业务非常简单、稳定，可以做到业务无关（买包子、住酒店、买个 App 都一样支付），而且大家会愿意付钱，避免自己去撰写和维护这种与自身核心业务不强相关的代码。这就是一个非常合理和中台服务选择。

可话说回来，按照这个定义，很尴尬的就是，我们会发现「中台」这个词语根本就没有存在的必要。因为同样一个事情，我们可以问「什么样的服务可以被拆成一个 SaaS 服务或者开放 API」其意思是完全一致的，而且这是一个全世界通用的话术，大家都明白。

还有「开发工具」中台呢？

不是做技术出身的朋友说「开发工具」中台，我还能理解，做技术的说这个，真的有点接受不了。

你想要一个托管的编程平台，或者托管的持续集成的流水线，甚至一些集成的开发环境，这些都是现成，早就熟透了的东西，并不新鲜。

你想要容器管理，云管理，自动化运维，DevOps，工具链，这些也是早就有了的东西。

你想要一个前端数据聚合、整理，甚至把后端的部分能力前移的工具，Backend-for-Frontend 也是早就有的东西，GraphQL 完全可以用起来。

完全不需要发明什么开发工具中台、技术中台的新概念。

总而言之，就是：

• 如果把「中台」视作为一个技术、则架构概念，无法解释它的反潮流性。
• 如果把「中台」视作一个业务概念，则它和 SaaS、API（化）、应用服务（化）等现有成熟概念没有区别。
• 很多讲述「中台」理念的文章都有过度抽象和错误建模的倾向，而且很多时候在讲述的「用中台解决问题」其实仅仅是「原来我们根本没考虑建模和 API，现在开始考虑了」这样老生常谈的事情。