关于中台，可能都是正确的废话

如来说：世界，即非世界，是名世界 - 《金刚经》

“中台”这概念：

无奈现在它铺天盖地的，被大谈特谈，已成气候。西谚有云，如果你不能打败他们，你就加入他们（if you cannot beat them, join them）。巨头互联网企业擅长炮制概念并迅速占领制高点，你必须在他们的语义下去描述、讨论事物。

另一方面，也可以这么看，互联网企业一些概念的提炼抽象，让传统行业在把业务搬上互联网的过程中有了明确的思考框架和方法论。“中台”这个概念最大的存在价值，就是充当“指导思想”让传统企业有方法的采用一些技术架构和一些平台去建立“中间层”，形成从 Web 2.0 时代以来的互联网前台“店面”到本世纪初乃至上世纪 90 年代的历史遗留核心系统之间的价值链路的平滑过渡。 

从技术上看，对于传统行业的企业而言，从信息化向数字化过渡的进程中，需要

• 解决“属于不同世代的异构技术系统与互联网入口连接”的问题

• 解决“信息化时代形成的信息孤岛、烟囱”问题

• 解决“经营管理与展业获客线上化”问题。

怎么解决这些问题？打造新链路、引入中间层。

先把“台”字去掉 – 从中间层说起

著名计算机科学家 David John Wheeler 有句经常被引用的名言 “All problems in computer science can be solved by another level of indirection“ - 计算机科学中的任何问题都可以通过加上一层间接层来解决（图灵奖得主 Butler Lampson 在 1993 年的图灵奖演讲中最早引用了这句话，从而传播起来）。

在计算机世界，中间层就如一顿烧烤 - 没有什么事儿是一层间接不能解决的。如果有，那就是两层。

中台也好、中间层也好、中间件也好，是解决一些问题的有效方法、自然选择，想一想，当你靠着一套十多年前的证券柜台交易系统、银行核心系统、保险出单系统，试图在互联网上开门做生意，你会去把这些基于封闭技术（例如采用非 x86 的主机、缺乏技术接口和数据接口）的稳定系统进行“云化”的改造吗？一个可行的解决方案，就是在你的网上“门店”和这些“稳态”系统之间做技术缓冲带、中间层，也是很朴素、很合理的办法。

从中间层演变成中间“平台” – 就是这么朴素自然、顺理成章

最迟至 2015 年，证券行业的第一个实际意义上的中台雏形就出现了。

2013 年，是所谓互联网金融的元年，券商也开启“电商”、“互金”的线上展业之路。此时的集中交易系统，首次面临互联网链路上的并发要求、可用性、安全性挑战。以前的柜台系统，交易时间外停机，周末和交易所联调测试，维稳思维主导下，外部接入系统都不能随便直连。可是券商一旦开启互联网业务，那就是 24x7 打开门做生意：

• 高可用性问题出现。客户在非交易时间无法通过互联网柜台查询自己的持仓和账单、在周末居然看到自己账户被临时测试数据弄的面目全非而误以为出现系统问题等等，都是完全可能发生又完全不可以接受的，分分钟引起投诉，如何保障客户服务 24x7 可用？

•  高响应与高并发问题出现。电商部开始通过互联网销售爆款理财产品，并以秒杀方式进行促销，经常导致计算资源请求的突发性高峰。传统交易系统性能以交易委托笔数和并发交易事务数量的执行为衡量，却不适合响应海量用户在线交互频繁的、“会话型”（session）高并发请求。如何支持良好的用户体验、弹性响应海量用户访问、支持用户会话的高并发？

• 信息安全问题出现。只要在互联网上开了一个口子，你会发现自己的核心业务系统与互联网之间就会形成链路，无论是多么的间接。如何做好信息隔离和保护？

2013 年，朴素自然顺理成章的，我们引入了前置在核心交易系统之前的技术层，对交易柜台进行了缓冲、封装、解耦、隔离，让互联网入口过来的请求，得到更加符合互联网环境的处理。显然，这个技术层必须采用互联网企业常用的分布式架构，这个架构的特点，就是 Reactive（反应式架构）- 消息驱动（message-driven）、弹性伸缩（elastic）、即时响应（Responsive）和回弹性（Resilient）。这一年，我们制造了由五花八门服务组成的中间层，我们的技术团队也以“反应式宣言”（Reactive Manifesto）为技术准绳。

2014 年，我们发现上面这个技术层越来越厚，因为互联网上的新业务功能越来越丰富，除了扛的住互联网的流量外，我们还需要更加规范、更加可控的去实现这些功能。于是我们想到了微服务、服务注册发现与治理、熔断/流控/隔离/委托/代理/链路跟踪等等。朴素自然顺理成章的，出于整理日益繁复、彼此互相依赖甚至循环依赖的服务条理化的朴素想法，我们建立了技术研发的最佳实践与准则（例如 Heroku 的 12 Factors）。这一年，中间层服务的规范、工具链初步形成。

2015 年，日益丰富的互联网业务的高度敏捷诉求与传统后台系统的维稳导向已经产生矛盾，朴素自然顺理成章的，出于对日益复杂的中间层的可运维性、可监控性的担心，我们考虑到了 DevOps（距该概念诞生的 8 年后）。利用已经研究了两年的对容器化技术的知识积累，这一年我们落地了基于容器与容器编排技术（K8S、Rancher）构建的 PaaS，现在中间层不再仅仅是一堆没有标准规范的服务，而是一个支持不可变基础设施（Immutable Infrastructure）、容器编排、数字化指标监控、服务治理，配备先进工具链的平台化中间层。

最早的时候这中间层并没有重点考虑让专门岗位人员对其进行运转管控，其中更多是”承前启后”的一些技术服务。但因为贴近互联网的各种业务场景，自然而然我们需要设置业务参数、需要结合 CMS（内容管理系统）发布营销之类的内容、需要监控分析用户行为、需要通过积分机制对事务进行度量和对人员进行奖惩，电商/互金部部门人员逐渐承担了这些岗位职能，成了这个平台化中间层的主要管理者。通过一个不断完善的商业运营系统（BOSS – Business Operation Support System），电商部对内调度与赋能经纪业务人员，对外向市场进行营销推广，甚至延伸到赋能外部合作伙伴（例如银行），同时对 IT 提出数字化运营的系列功能需求与设计方案。2016 年，一个兼具技术能力和业务能力的平台初步成型。

所以，回溯一下这个“朴素自然顺理成章”的过程，它是这样的：

• 我们要在互联网上开门做生意了。可是我们的技术系统是异构的（相对于互联网的分布式架构），是 Web 1.0 时代甚至是 Client/Server 时代的产物。怎么办？引入一个间接层，封装一下、转接一下，对接互联网吧

• 互联网上的业务越来越多，尤其是移动互联网出现、开启数字化时代，这间接层越搞越复杂，变成一大坨了。怎么办？需要建立规范、需要服务治理。这时候微服务、容器化技术应运而生，正好拿来用一用

• 可是光有微服务、容器化也不行啊，这些都是底层技术，它怎么解决数字化业务带来的敏捷化诉求、怎么解决信息孤岛问题实现横向连通呢？这个时候，我们就需要一个真正的技术平台，它能解决开发、测试、交付、上线一体化问题，才能有希望“敏捷”起来。此外还需要建立 API 管理机制、数据标准，让构建在平台上的新服务不会形成信息孤岛。DevOps 来了

• 技术平台有了，逐渐发现它不仅仅是一个技术连接方案，它还需要让业务人员而不仅仅是技术人员介入。开始的时候，是让非技术人员在平台上设置业务参数，然后是让业务岗位在平台上设置互联网业务规则 – 这已经是在进行一些运营性质的工作，再发展下去是让经营管理者实时在线查看数据和调整运营策略… 越来越多的运营工具出行在平台上供业务部门使用，这个时候技术平台已经成为一个技术载体，在它的基础上承载了各种岗位角色的协作

一切都是自然生长出来的，并非魔术般的从帽子里掏出一只兔子。

何谓之“台”？

“平台”这两个字，肯定是过去二十年来最被滥用的词汇之一，无论在技术界还是商界。IT 人有个倾向，喜欢把什么劳什子系统都称之为平台，以彰显其重要性、核心性，可以承载许许多多的东西…

什么是平台？平台就是你搭戏台，让别人唱戏，再引来观众看戏。你或者向戏班收舞台租赁费或票房分成，或者向观众收门票，或者你牛的话两边收费。

技术平台，也是符合上述“搭台唱戏”的基本特征：平台搭建者对技术接口作充分开放、逻辑抽象，定义出插件化的机制，然后让插件开发者开发插件，形成非常丰富的插件生态甚至插件市场，最后让用户自行按需选择适合使用的插件。

优雅的技术平台，把“契约式设计”（Design by contract）、“松散耦合”的原则运用到极致，不仅分离出平台的稳定内核和插件化周边生态，更有甚者把内核本身实现成平台的第一个插件。平台本身只是一堆契约、协议、接口、框架，它貌似没有实际业务价值和运行能力，它是“空”的；但是平台又是抽象、提炼了各式其色的业务功能的共性与精髓，它又是“有”的。佛说：平台，即非平台，是名平台。“空有不二”！

技术平台的特点是：

• I don’t call you. You call me – 作为平台，我不会去调用你的接口，而是提供钩子（hook）、回调（callback）、事件订阅机制让你作为第三方进行调用。金融机构的平台是业务逻辑自洽的、边界清晰的，而 IT 则是平台提供者而不是系统集成商，应该在对业务抽象的基础上制定接口，实现“外挂”（谁实现则是另一个问题，也不见得需要一些所谓强势开发商软件商的配合）。而传统的系统集成思维缺乏对平台化的认识

• 插件化、生态化 – 微信和它的小程序、苹果手机和它的应用商店，就是典型的平台和插件关系，以及大量插件形成的开发生态、商业生态。这种插件化、生态化思路，同样适用于企业软件系统，就看你的技术架构是否设计得当

• 多种角色的参与：平台设计者与维护者、插件提供者、应用开发者、用户

业务平台的特点是：

• 建立在技术平台基础上（平台型的业务过去并不依赖于系统，没有技术支持的平台型业务模式一向存在，可是现在没有技术平台支撑的业务平台已经越来越难以想象）

• 连接多边、促进交互和交易，例如 Uber，司机和乘客就是平台的利益双边。平台通过巧妙、合理的策略，通过同边网络效应、跨边网络效应，促使平台的“滚雪球”

”台”，显然应该支持很多 Actor（“角儿”）的表演。

“中台”概念的最大价值是作为方法论

首次从互联网企业加入到非互联网企业的技术人，可能会惊讶的发现，在互联网业一些常规的、标配的东西如“分布式架构”之类在传统行业尚算新生事物，但也不能完全归结于先进与落后的问题，是技术系统在互联网出现之前和之后所面临的业务环境以及服务客户的方式不一样。一旦传统线下业务被“卷入”到线上，大家在探索如何把历史遗留系统更有效、更合理、更安全的对接互联网的过程中，其实都是在不断的建设和优化间接层或者说中间层。

“中台”这个概念，对促进本来不熟悉互联网技术生态的一些行业和机构主动去采用分布式、云原生、平台化的解决方案实现间接层、中间层，还是挺有价值的，作为指导思想也好、方法论也好、参考案例也好，能起到正面的启迪作用。虽然中台应该是自然而然产生的，不是削覆就履、也不是按图索骥拿着概念去凑架构凑方案，但是稍微刻意的“中间层平台化”的意识也值得称道。

中台，即非中台，是名中台

（佛说：我没说过这话，但我是这么个意思。。。）

作为技术人的自我反省，我们经常追求一个技术或者技术方法论而忘记了它的目的，正如高僧为我们指明了月亮的位置而我们只执着于那根指着月亮的手指…

就像早年的“大数据仁波切”一样，现在也出现很多“大中台仁波切”，借用一个术语“_____”（此处可填空：大数据、人工智能、中台、云计算、区块链…）仿佛能魔术般的解决一切 …

技术中台、业务中台、数据中台、AI 中台… - 这些都是浮云而已。平台，不过是一堆的规范、标准、框架、规则、最佳实践，它本身没有做什么最具体的事情；可是它是对业务的抽象与精炼，是资源的匹配、交易的撮合、生态的连接，它又促成了一切。

当云原生（cloud native）的技术架构成为企业标配，当企业自身成为云原生的数字化企业，例如你未来的“纯种”、云原生核心交易系统通过一系列的间接层、中间件与你的客户及合作伙伴实现了全云端连接，你的员工就是在它上面进行日常的企业经营与运作，“中台”也就没什么值得独立强调、大书特书了 – 前中后台也许早就不再是今天这般的定义。

中台 – “不忘初心、牢记使命”

事实上过度聚焦中台，立项搞“中台建设”以及谈论中台的成败，听着就怪别扭的。这就是执着于把指向月亮的手指当作了月亮本身。

云山雾罩之下，中台的“初心”，不过是用间接层解决一些不同历史时期的异构技术的连接问题，然后在这些间接层越来越复杂、越来越厚、越来越重要的时候，如何通过框架、规范、治理手段、工具链去把它们管理好，并且在互联网的倒逼之下，它必须与时俱进的支持云计算、支持敏捷，因为它是“稳态”世界异构系统对接“敏态”世界的转换器。

不敏捷、非云原生的方案，都不是真正的中台。

中台也不仅仅是一堆无人干预的中间件技术，它逐渐成为一个自动化半自动化、人为介入、多人协作的环境，越来越多的业务员工甚至外部客户发现自己通过各种工具在中台上展开日常工作，于是中台不再仅仅是技术解决方案，它承载了新的岗位与人员，甚至有应运而生的运营部门。它成为了企业数字化的枢纽 – 但在此之前它首先对组织结构、经营管理的转型产生了诉求。

现阶段，中台已经过了技术人自说自话、以打造技术系统为导向的时期。对于后来者，中台作为一种方法论，首先是要做好业务架构设计。

什么是“业务架构”？ " 涉及一个以上组织，按某一共同的目标、通过信息交换实现的一系列过程，其中每个过程都有明确的目的，并延续一段时间 "。看看几个关键词：

• 组织：业务涉及到的人或者组织，每一项业务应该由多个人、多个角色来完成

• 目标：做某项业务的目的和价值，换言之，为什么做这项业务，做好这项业务要达到的目标是什么。

• 过程：过程就是业务过程，一项业务由多个过程组成

找出利益相关者（业务的受益方是谁，为什么要做这个业务），整理出业务流程（一段时间内相对固定，每个流程都会再往下分解成子流程）。

中台，就是我们首先对业务架构进行合理抽象，其次才是对其平台型技术架构设计遵循与采用时俱进的最佳实践（例如采用云原生技术栈、反应式框架）。

新鲜的概念之下，其实都是些本来该严谨执行的老方法。

作者：凡泰极客 CEO-梁启鸿