中台的“酒”瓶

酒瓶和水

中台的概念在今年突然很火，持续地火。产品不蹭一下中台的热点，自己都觉得不好意思。于是乎，看到了高矮肥瘦的各式各样的瓶子，都说是中台的酒瓶，里面有新瓶装旧酒的，更多的是装些果汁，矿泉水，不少的直接装自来水，甚至只装空气。只要不打开看，放在架子上，装扮得五光十色，十分喜庆。

需求是第一导向

中台是个概念，是个名词，尚无权威定义，本文也不打算讨论何为中台。下定义的人多了，但被认可要靠权威，我们顶多能发表下看法。公司里面已经聚合的能力集，无论有没有中台的概念，它就摆在那，叫能力云也罢，叫中台也好，它都老老实实地杵在那里。

碰到更多的是蹭热点，言必称中台，恍惚贴上中台的标签，身价上涨。红红火火的程度，以至于这个功能好像挺不错，可不可以抽出来做中台，那个能力也很好，要不要也弄过来做中台。这些话听多了，我其实很想说，同学，你想多了。

任何产品的第一导向都是需求，成为中台不是说这个功能好不好，是否可以独立出来，这写只是成为中台的充分条件。我们需要意识到下面几点：

一、有没有成为中台的需求。

中台的最重要目的是避免重复造轮子。我们首先要看有多少人需要这样轮子，而不是说能不能做出个轮子。也就是说首要考虑是要不要的问题，而不是能不能的问题。即是有多少项目有这个需求，以及如果真成为中台，有多少项目会去用。

如果我们在公司内部做一个需求调研，问将某某做成中台好不好，多半好；问你们会用吗，不少答会。但实际做出来后，可没那么多人捧场。将接入中台作为一种可选方案纳入考虑，和最终决定是否采用中台，两者的差距不言而喻，但在调研问卷分析，经常会被忽略。如果两者数据基本一致，那针对的就是痛点问题，又或者简单粗暴的领导要求。

反过来思考，如果我们要决策是否使用某中台，我们需要考虑，这个功能是否与我们核心业务紧耦合，其流程是否视为黑盒。一般来讲，数据中台、运维中台都不会触及我们的上层的业务；而能力中台，其内部实现的流程和我们业务解耦，是我们业务调度或者业务编排的一个单位，也就是说在开发的过程中，我们不需要调整该功能的内部流程，增加新的参数或者特性，中台应能覆盖我们的需求，无需个性化定制，并在性能上提供足够的支持。

二、有没有成为中台的共享基础设施。

和大厂有自己的数据中心不同，小公司的基础设施通常不是自建的，可以是在某某公有云，某某IDC机房，客户自有机房，即使在在同一个某某云上，可能是公司自己租的，也可能是客户指定的，可能是在深圳节点，也可能是在上海节点。如果多个项目的生产环境无法在同一个基础设施上，就存在两个问题：一是网络联通问题；二是网络性能问题。

我们要考虑在生产环境的实际部署中，业务节点和中台节点的网络是否能满足需求。

三、建设中台能不能节省成本。

中台的一个重要目的是节省成本，集中力量办大事。将共性的抽离出来，作为平台实现，不用每个项目组开发，另外将分散到各个项目组从事相似工作的开发人员集中起来，可以构建一个功能更为完善，性能更为强大的平台。

但请不要忘记，中台本身是有成本的，而且成本还不小，需要有专门的中台团队来进行开发和维护，存在跨团队合作（如，想中台团队提需求）的沟通和时效成本。最终能否节省成本，在于边际效益，接入的项目越多，中台成本摊分越薄。所以，中台适合大厂，对于小公司，先算一算帐，到底是增加成本还是节省成本。

选择和演进

前面讲到中台是有成本的，需要单独的运维。就开发而言，项目内部一个边界清晰的模块，要独立出来成为一个平台，成为一个多个项目共同使用的内部产品，也不是那么容易。最大的就是模块和产品的差异：

1. 作为一个模块用于某个项目，相当于单租户；作为产品用于多个项目，就是多租户了，就要有租户的配置、管理、授权，不同的统计视图，独立的运维系统，这些在单项目内都无需考虑。
2. 原来的一些控制功能，如限流，是由项目统一实现，例如在第三方接入网关中实现，模块本身可以不考虑，但是作为平台产品，这类的控制功能就必须要有。
3. 作为平台，服务的量级不同，量变引发质变，很可能会引发实现的架构的不同，需要进行重构。

中台并不是解决重复造轮子的唯一方法。

最简单的就是代码复用。以java为例，就是封装为jar包，提供其他项目组使用。我们在自己的项目中也会复用到很多开源项目的代码，例如json的解析，如此细小的功能，有时会让我们忽略掉，其实这也是个开源项目。

人员复用也是一种变相的代码复用。对于某方面资深程序员，专职从事某特定领域的开发，被不同的项目组共享。他可以根据各项目不同的需求，快速地定制地开发出各项目的所需。

进一步，可以采用第三方接入的方式。对于一个服务提供方来说，除了推广自己的应用外，还可以把服务以 API 方式开放出来，让更多的应用接入自己的服务。也就是某个项目开发出来的业务或功能，如果其他项目组所需，是可以采用第三方接入的方式，通过Restful API接口来接入该服务，相关授权方式比较流行的是OAuth2.0。

如果项目的某业务或功能集有越来越多的内部第三方接入，并慢慢地以此为主要的请求来源，就可以开始考虑中台化。这是逐步演变，水到渠成的过程。对内服务，我们称之为中台，对外服务，我们称之为云能力。很多时候，内和外的界限是模糊，有内有外，反正就一称呼，不要太纠结。

天花乱坠：数据聚合

在各类的中台中，数据中台比较特殊，我总有种以中台之名实施数据霸权的感觉。

“中”就是在“前”和“后”之间。一般来讲，输入是项目A，输出也是项目A；输入是项目B，则输出为项目B，项目A和项目B的数据是隔离的。然而，数据中台实现的是数据汇聚，从不同的项目中获取数据来源，将这些数据综合起来，一起进行数据分析，在更宏大的视角中得到更精确的图谱。

数据为王，数据中台在大型互联网公司中具有很高的价值。很多时候，已经不是“前”和“后”的中间，仅仅将项目作为一个数据源。

一旦将各方的数据汇聚，想象的空间就大了，至于多大，看心有多大，可以天女散花，可以天花乱坠。