关于中台的说法一直是众说纷纭，这里我们更加深入分析一下到底中台好不好，到底为什么有的中台行，有的中台不行，技术架构上都大同小异，那什么会导致一样的架构不同的结果呢，原来我们除了技术架构，缺少一个真正核心要素：你的业务和组织架构是否需要阿里一样架构的中台，你的团队是否有一个能够实施切合业务实际中台的 Leader 或者架构师。
中台，早已有之，在银行系统，在各行各业中台这波操作早已开始操作，就是复用，组件化，治理公共化，没有那么神奇，每个研发人员最起码的编程思维；但是，为什么阿里的中台就能风风火火，并且产生了很大的效果，那是因为阿里的业务体系大到很大了，各自为战的造轮子已经太浪费资源了，所以有一批人专门抽出来做这些公共服务，并且用一种组织机制和技术机制来告诉大家，你用这个组件只能调用这个，不能再造轮子，那么对这个体系的管理和支撑就需要很大人力，再加上云计算的主要业务，对阿里来说也是资源复用的；
所以在考虑阿里一样的中台架构的时候，先想想，是不是业务也达到阿里一样的程度了？是不是需要和阿里一样的中台架构才显得自己专业？实施专业中台架构需要额外的人力和组织来保障，你是否找到了一个足够专业的架构师？即使是 Leader 也必须充当架构师的角色，没有这个架构师，光看光鲜的技术，那是不行的，所以市场上自然有了，你家的中台不行，人家的不错；重要的事再说一遍：或许你要的不是一个高贵的中台架构，你要的是一个专业可靠的架构师告诉你在当前情况下该怎么架构。与其迷信或者摇摆，不如先把自己的业务搞清楚，搞透彻。
什么是中台？
中台就是公共服务平台，数据中台就是将数据加工以后封装成一个公共的数据产品或服务。
虽然中台架构早已有之，但是马云阿里让这种技术架构有了一个统一的名词，并让它声名远播，是对整个技术社会的贡献。
没有中台的时代
在传统 IT 企业，项目的物理结构是什么样的呢？无论项目内部的如何复杂，都可分为 “前台” 和 “后台” 这两部分。
什么是前台？
首先，这里所说的 “前台” 和 “前端” 并不是一回事。所谓前台即包括各种和用户直接交互的界面，比如淘宝购物页面，手机 app；也包括服务端各种实时响应用户请求的业务逻辑，比如商品查询、订单系统等等。
什么是后台？
后台并不直接面向用户，而是面向运营人员的配置管理系统，比如商品管理、物流管理、结算管理。后台为前台提供了一些简单的配置。
前台、后台、用户之间的关系，可以用下图简单表示：
在当时，项目的发展相对稳定，并不需要那么快速的去迭代和试错，所以这种结构并没有什么问题。
在互联网快速发展的今天，企业之间的竞争越来越激烈。只有以用户为中心，快速响应用户的需求，不断迭代和试错，才能让企业在竞争当中立于不败。
但是，现实情况下……
在传统的前台 - 后台架构中，各个项目相对独立，许多项目都在重复发明同样的轮子，即让项目本身越来越臃肿，也让开发效率越来越低。
这种时候，为提高开发效率，我们有必要整合出一个中间组织，为所有的项目提供一些公共资源。而这个中间组织，就是人们所说的 “中台”。我们可以看到，中台不仅包含服务器端的中间件，更包含一些业务中的业务公共件，本质始终没有改变：复用，减少开发维护成本，减少业务出错几率；要说真正牛气的中台就是云计算 + 云业务 SAAS 了，通过自由组合解决所有公司的业务场景。
中台解决了什么问题？
用户和用户的需求永远是善变的。依稀记得 “80 后是垮掉的一代” 的说法的你，现在看到的却是 “被 10 后毁掉的 90 后父母” 的感叹。
主流用户的变化，不会因为某个年代人的话语权高低而稳定下来。而即便是同年代的用户，在随着现代社会发展和各行各业互联网服务的滋养中又进化细分成了出不同的支流，需求全然不同，呈现场景化、碎片化的特征。
为了不被善变的用户所抛弃，企业不得不跟随着用户；为了满足用户而尽可能积极地响应用户需求的变化，发展新业务、提供新服务。这就给企业的前方业务端提出了挑战：必须做到快速响应、灵活运转。
但要作为一个能承接大量新业务和新服务的大体量企业，业务想要做到量大又灵活，必定需要靠企业内部科学有序体系的稳定支撑。
所以，企业前方市场总是会趋于变化无序，而企业内部支撑总归要趋于稳定有序，两者必定冲突。
企业发展到一定程度，组织架构和层级必然不断膨胀扩张。各大事业部下各大部门，就像一个小型组织一样，各占山头，势必会出现屁股决定脑袋的现象：这事就算对公司有好处，但对我们部门 KPI 没好处啊，那我不做。
大企业内部各处都是墙 —— 部门墙、业务墙、数据墙。更不用说那些一味的内部赛马的绩效考核机制，势必更加加剧部门间的相互封闭。而一些原本可以快速提供的用户服务，却需要多重对接，无法快速拿出产品方案，耗费很大的成本和极长的时间。一个原本可以共用的服务，被不同部门重复建设。
业务中台和数据中台的关系
无论是业务中台还是数据中台，都是在企业 IT 系统架构演进过程中形成的，并从企业自身 IT 系统规划、建设、运营、运维等多年的经验中提炼出来的共性能力。业务中台和数据中台作为两个轮子并肩构建了数字中台，支撑前台对会员的从营销推广、转化交易到智能服务业务的闭环，促进企业业务的提升和发展（如图所示）。数字中台对内连接企业的后台系统，诸如 ERP、人力资源、协同办公、财务管理等。
中台的建设方式和要点
1. 封装式
2. 重构式
中台构建三大要点
网易中台微服务架构
百度中台
总结和思考
看完以上内容，看完以上中台，看上去丰富多彩，或者有些杂了，其实都是一个问题：复用，他们的只是根据他们的业务总结出来的，所以自己公司要什么样的中台是不可以照搬的，是需要学以致用的。
特别是 BAT 的中台建设，是不是可以窥见一斑，连百度腾讯都没有完全模拟阿里的中台，其他公司的照搬结果可想而知了。让茅台老总勃然大怒的中台项目，到底有没有照搬阿里的是没有详细报道的，但是显然受了阿里大中台的一些影响，人家家大业大，都是应用业务系统，自然需要大中台；
而国酒茅台，一般情况下是不是业务系统内业务代码和底层技术代码复用就可以了？也许并不是茅台 CIO 的主意，也不能因为市场上什么火就学什么，就像深圳有一家公司觉得 GO 很火，把原本完善的业务系统全部换成 GO 一样，毛泽东不是说：一切是从实际出发嘛；我们不能否认中台的优点，前提是你的业务有足够的财力来保障其正常有序正确的搭建和实施，用什么样的架构，用什么样的中台，中台做到什么程度，不是中台的问题，不一定是你需要中台，而是你更需要一个合格的架构师。
