来源：HelloJava

自从2015年阿里开始中台战略后，这个词就成为了一直火热的词，直到前段时间阿里的1+6+N的调整，拆中台成为热门话题，那到底要不要建设中台，还是要把已经建了的中台拆了呢，这个取决于中台的作用到底是什么，和你所在的企业的阶段是否匹配。

阿里中台的起源和supercell的故事被各种文章提了无数遍，作为阿里中台一路的观察者吧（我做中间件、基础架构这些准确来说其实不是中台），说些我自己看到的。

观察
中台分为业务中台和数据中台，这两个其实不太一样。

业务中台
我在07年加入淘宝后，淘宝当时是从单体应用到分布式架构改造的过程中，这次改造需要把一些大的业务逻辑的部分从单体应用中提取出来，成为独立的系统，例如用户、交易等，承担这个工作的团队就是当时新组建的共享业务中心的小团队，也就是很多文章里都会提及到的阿里业务中台的前身。

到了08年底09年初的时候，发生了一件在阿里技术层面比较大的事，是淘宝商城和淘宝的技术底层合并，内部代号为五彩石的项目，在这个结构下，淘宝商城、淘宝的交易、用户等就是同一套体系，这个我觉得对后来的业务发展是起到了很好的帮助的，这个项目完成后，就形成了淘宝、淘宝商城的业务基于大量共同的业务中心而构建，彼此也可以很方便的互通（例如不存在淘宝的用户、商城的用户，也不存在淘宝的商品、商城的商品分开展示/交易等），这里可以看到，中台对于需要互相打通的业务，是会有比较明显的帮助的（这也是后来为什么阿里在收购了一些业务，都会要求业务改造为基于中台），当然，业务要打通除了中台这种比较重的做法外，也还有一些比较简单的基于API的做法，但那种做法在数据层面的一致通常会是个挺麻烦的问题。

随后的很多年都基于这样的结构发展，过程中确实也碰到了很多的调整，例如淘宝商城也就是后来的天猫，B2C的玩法和C2C有很多的不同，而之前的业务中心更多的还是基于C2C的玩法设计的，导致了这个过程中系统复杂度不断上升、效率也有了挺大的影响，内部其实也一直有争论有些业务中心系统是不是还是应该拆开，各自独立建设，这事到了2015年阿里开始推行大中台、小前台的战略时，自然也就明确了。

在2015年之后的发展中，中台越来越大，支持了阿里越来越多元化的系统，随之面临的挑战也越来越大，中台在系统架构上也做了多轮的调整和努力，以尽可能在前台业务要的快速响应和中台的可复用层面做平衡，但后来的几年刚好是阿里在电商领域面临激烈竞争的几年，且份额不断失守，一部分的责任就归到了中台造成的响应速度上了，后来也能看到阿里各种改变，例如允许某些特区业务的技术可以选择不基于中台。

直到现在阿里1+6+N的拆分，看到业务中台团队很多归入到了业务公司中，应该算是选择了在业务竞争激烈的情况下，解决问题的方法。

数据中台
数据中台我了解的比较少，只能按自己的简单感受说说，阿里应该是在09年左右开始就非常重视数据，当时就已经要求整个集团的业务数据统一收集起来、统一治理，这个必须说早期都没看出有什么作用，但到了移动时代后，这个确实是发挥了非常大的作用的，人群更为精准的推荐、搜索等，到了现在的AI时代，就更了，手头的非公开的高质量的数据，搞不好会成为最后业务还能有差别的最关键的因素。

总结
总结下，我会觉得业务中台比较适合两种场景：
1. 业务互通，对于需要把一些共同数据统一管理，避免各个系统独立，导致一些共同数据不一致的场景，基于中台的方式去构建还是很有必要的，如果没有太多数据层面的诉求，那基于API做打通就是更为轻量又有效的方法（在落地上因为没有涉及到团队权益的重新划分，通常也会更容易）；
2. 业务多元化且平稳，需要更多的追求效率的阶段，这个时候中台显然可以有助于减少人力，不过竞争形式实在是多变，一旦有竞争激烈的苗头，最好还是选择保响应速度为先，重复建设/人力投入暂且放在更低的优先级看待。

数据中台的话，我觉得还是很有必要建设的，因为数据其实只有越全面才会越有价值，如果都是分开的孤岛，那挺难的，并且数据治理也是个超级复杂的活。