2.3 揭开中台神秘的面纱

2.3.1 通过一个做菜案例读懂中台

既然前面已经强调了这么多前后台模式的弊病，那么号称能解决这些问题的中台解决方案到底是什么呢？让我们以做菜这一通俗的例子来快速理解中台！

如果将互联网公司的研发中心比作一个厨房，将研发新产品的过程比作做菜的话，我们就可以很容易地理解这个概念了。

首先请大家想一个问题，在一家客流量非常大的餐厅中，我们要如何缩短客人的等餐时间呢？

相信很多人的第一想法就是增加多名厨师，但是对大多数的餐厅而言单纯增加厨师是不实际的，因为随之而来的是很高的人力成本，而且每天业务高峰期只有中午和晚上这两个时间点，虽然在饭点我们解决了这一问题，但是在一天中其他的时间里新增的这些厨师就显得非常冗余了。

正确的做法是将做菜这个任务拆分，从多个环节来思考。做菜流程如图2-4所示。

这样拆分后，我们可以发现，无论做任何菜系，买菜与配菜都是共有的两个步骤，我们完全可以只增加一位配菜的小哥来代替厨师去进行部分环节，这也就是现在主流的餐厅组织架构。改造后的做菜流程如图2-5所示。

这样，我们每一位厨师新做一道菜时就没有必要从买菜、洗菜、切肉这些基础的环节开始，而是完全可以直接使用他人切好的肉片和洗好的菜下锅，唯一需要关心的就是如何在搭配调料上研究出不同的创意。厨师的做菜速度大大提高，并且在成本上大大缩减。

回到研发流程上来看，负责买菜的人其实就是我们研发的后台人员，他们帮助我们解决基础的原料问题，可以让我们稳定不断地从外部获取材料，保证内部供给。而厨师是我们的一个个前台业务人员，他们要做的就是根据不同地区不同口味烹饪出对应的菜系。

在企业业务多元化后，我们就可以将洗菜、切菜、配菜这些半成品的生产过程统一交给中台去完成，做菜的时候作为前台业务人员的“厨师”只需要告诉中台自己需要什么材料，当然这里的配菜小哥就是我们的中台，这样就大大加快了业务的完成速度。

所以说，有了中台之后我们的前台业务就可以去快速完成迭代，不需要每个服务都要求后台从0到1开始提供，而是根据不同业务需求去使用中台生产的对应半成品进行二次加工。

让我们再站在架构的层面来看看中台对整个系统业务所起到的对接简化作用。

假设我们经营一个电商平台。在我们未使用中台的时候，每一个前台的用户终端都需要与后台进行一次对接，如图2-6所示。

而后台的每一个模块都需要维持与前台业务的关联，并根据不同业务的前台特征去加入适配部分。这样造成的结果：

后台的每一个模块都需要加入与前台适配的部分，从而大大增加了开发量。

每个前端在启动时需要分别对接不同的后台模块，也加大前台启动时的工作量。

当后台进行升级或架构调整时还需要考虑与前台的对接，并进行逐一的调整。

当我们引入中台后，让中台作为一个对接层，帮我们去统一对接前台的不同终端，同时对后台各个子系统进行统一的封装，让前台能无感知地使用各项服务而不需要单独设计通道，我们的系统也就简化成了如图2-7所示的这个样子。

通过对比，我们能清楚地看到中台对于公司的整个业务架构起到了非常大的简化作用。

因此，用一句话来概括中台模式：中台的核心本质就是向前台业务提供服务共享，目标是更好地支持前台业务方进行规模化创新或大规模试错，从而更好地响应市场需求。同时在这里简单提一下，一般性中台实现的手段是微服务架构、敏捷基础设施和公共基础服务。

中台作为一种产品设计思路或系统架构思路，并不受限于公司的规模。理论上讲，任何一家即将或者正在面临业务高速增长状态的企业，都值得利用和借鉴中台的思路，将目前业务当中大量可复用的功能和场景进行梳理，为业务的高速增长做好准备。

2.3.2 中台解决方案的完整定义

在理解了中台的概念之后，至此我们就可以用较为严谨的语言来给“中台解决方案”下一个定义：

中台解决方案=能力输出+标准化中间件

（1）第一部分：能力输出

对于一家企业来说，其能力可以包含多个维度，常见的例如计算能力、技术能力、业务能力、数据能力、运营能力、研发能力等。

而所谓“能力输出”就是要规划出什么是公司的核心竞争力，理清楚公司发展的战略目标与未来公司的主要业务会拓展到哪些方面，在这些业务层面中去提炼那些以共性存在并会在每个新开拓的业务中被不断使用的模块，然后将其归类到中台中进行统一建设，而不是把所有能力都进行复用化。

这也就是中台的一个重要的意义：为不同的前台业务提供可以重复使用的能力，形成一次建设、多次使用。

例如，我们规划了公司的核心方向是视频方向，未来可能涉及的业务形态：

在线视频。

视频直播。

短视频。

分析上面的业务形态后，我们不难判断出要抽取的基础模块包括：

在线视频编辑。

视频压缩。

多人点播。

视频断点续播。

视频账户体系。

在完成这样的划分后，我们就可以通过中台去统一实现这几个通用模块了。

值得提一下的是，虽然这里在说中台要考虑复用性和扩展性，但是要考虑多少、考虑多深就是一个非常考验产品经理功力的地方了。

还是举上面的例子来说，我在设计一个视频社区App的积分商城系统时，需要将商城交易方式抽象为能力，这里我们大体上可以按关联程度高低抽象出如表2-1所示的3种商城交易方式。

但是同样的疑问来了，我们仅仅为了支持一个积分商城而需要将中台的扩展能力放大到开始考虑股票交易才用到的撮合交易模式吗？

当然，这里举的案例比较极端，因此我们能快速完成判断。但是在具体的中台规划中我们会碰到很多这种复用范围大小的决策，此时我们必须按照公司的核心业务规划来严格定义中台的能力，避免在中台出现过度建设的现象。

这里也用一句话来概括：可复用性和复用深度是衡量中台建设好坏的重要指标。

（2）第二部分：标准化中间件

在我们确定了公司的业务发展需要哪些能力之后，中台解决方案的另一个组成部分就是需要将每个能力进行封装，形成统一的可供前台业务端快速使用的中间件。

这里的“统一”具体表现在如下的两个方面：

不同终端中的叫法与含义。

定义统一化的输入输出。

为什么要统一呢？

在以往的前后台模式中，同一家公司内的不同项目组（如直播项目组、短视频项目组等）各自为战的时候，经常会出现一个事物在不同项目中因为场景化的需求而出现多个称呼的现象。

这也是原来不同项目组想要复用对方的模块时遇到的一个巨大的障碍，它导致无法快速对接，只能重新开发、重复建设。

就拿现在任意系统中随处可见的“用户昵称”这个字段来看，在不同项目组的应用中可能叫“用户名称”“用户昵称”“称号”“化名”等；而在数据库中又可能有不同的字段名称，如“username”“UN”“name”等。

因此，我们需要一个中心化的产物帮助我们定义好这些通用属性，使其在公司中不同的业务端都能统一。

面对这种现象，在有了中台后，我们就可以通过定义标准化的中间件来解决。假设以后公司内部孵化的项目组再次要使用“用户昵称”这个字段，无论具体是什么业务前端，都会采用一个叫法、一种存储，这样不仅能直接使用之前项目的模块，同时还可以和公司内部的管理系统快速完成对接，这就是中台所起的作用。