“中台”火了，可是它到底是个啥？

互联网的发展日益壮大，复杂性业务越来越突出，服务中台的概念被逐步的拉上历史舞台，那么中台到底是什么呢？

1.中台是什么？

中台这个名词，通俗来讲，其实也可以看做一种后台，只不过由于业务越来越复杂，使得一部分业务进行了分离，最终产生了中台这个概念性的东西。

借用别人的话来说：中台的产生，并非完全是自顶向下的战略设计，也并非是为了追随某种行业风口，而是随着公司业务高速发展、组织不断膨胀的过程中暴露的种种问题需要被解决，所产生的一种解决方案。

那么，中台到底是什么呢？

中台本身就是一种后台，但是相对以往的前端--后台架构，中台的加入形成了前端-中台-后台的模式。在原有的基础上，中台的增加在一定程度上可以约束整体向上的业务接口，向下又可以兼容底层的服务实现。但是有人就会吐槽，我单独拿出来一个服务来专门做这个事情，也可以达到同样的效果啊，为什么非要搭建一个中台来做呢？

2. 为什么需要中台

需要中台的原因，是为了解决问题，那么中台到底能解决什么样的问题呢？

基本可以概括为两个：“重复造轮子”和“前后端交叉性建设”。

第一个问题存在于，中台本身的出现，是由于互联网红利的驱动，带来了大规模的业务扩展，但是由于扩展过快，而导致各种重复建设的情况出现。简单来讲，许多业务需求或功能需求高度类似、通用化程度很高，但是由于没有专门的团队负责规划和开发，大量的系统重复开发、重复建设，导致复用性低、效率低、产研资源浪费、用户体验不统一。

第二个问题则属早期业务发展过程中，为了解决一些当下的业务问题，垂直的、个性化的业务逻辑与基础系统耦合太深，由于没有平台性质的规划，横向系统之间、上下游系统之间的交叉逻辑也非常多，这样导致在新业务、新市场的拓展过程中，系统没法直接复用，甚至没法快速迭代。说白了，就是之前欠下的技术债，当回归到问题本质的时候，却没有办法解决。这样中台的出现就有了一种新的解决方案。

3. 中台能做什么

中台可以看做是一种业务应用，主要起到的是一个连接作用。简单讲，中台类似一个变速齿轮，目的是起到一个承上启下的作用，将前台的快速响应和后台的复杂，稳定可靠，变化周期相对较慢的矛盾适配起来，快速驱动业务创新的同时，又保持了IT架构的稳定。

从表面上来看，中台和平台一样，都是对外提供开放接口。但是，实际的情况是，中台的核心特性，从本质上来看，有一条关键标准：是否能够复用。重复利用，这才是“中台”的源起。

从这一条标准来看，我们又引申出了3点：首先，复用本身，针对的是通用的功能能力，可以大大的提高整体的开发效率，避免了重复性建设。再次基础上，会对业务逻辑进行解耦，

一个功能的修改可能会影响很多方面。只有将需要大量交互的功能独立，从应用中拆解出来，这样可以使得应用之间耦合度大幅下降。而大量的解耦势必会带来敏捷的业务开发，大型的应用会做到业务拆分，最终适应于中台能力的业务模块。

4. 中台的挑战是什么

那么最终的问题是，如何做中台呢？中台的挑战有哪些？

首先我们要明确的是，中台的产生并不是从开始就有的，而是经过不断的迭代发展，最终复杂业务无法被现有架构满足的情况下，才会有中台的介入。因此，中台的开发，势必要解决历史包袱的问题。

在业务部门或者以业务为导向的产研部门，最核心的目的就是达成业务目标，要求你速度足够快、功能高效地解决当下的业务问题，当前业务发展的效率是最关键的。至于说，这个功能将来有没有可能适用于别的场景，有没有可能解决别的问题，这个问题实在是没那么重要。大量的业务堆积，可以无法有效的筛选出适当的业务模型，甚至多个业务部门之间的耦合，并不能很好的协调，这些都将会是中台带来的挑战。

而在中台启用后，敏捷化的开发业务需求，将会以适配中台服务为导向进行扩展，这一部分往往与高效开发相冲突，这种矛盾体系下，中台是否会拉低整体的开发效率，也是应该思考的问题。

最后一个，也是最重要的问题，中台的对外接口，如何适应大众化的业务需求，业务的动态变化随时可能带来业务扩展，而这些扩展是否能够被中台所容纳，仍旧是一个很难界定的难点。是业务包容中台，还是中台包容业务，这都将会成为一个很难的看点。