有位同行领导问了一个非常好的问题：在我们中台研究中为什么要刻意区分中台和平台，这么做有什么意义？这是一个非常非常好的问题，也是我们中台研究的一个重点，也是我们非常希望解释清楚的一个问题。要解释清楚平台和中台的区别，需要从中台的本质和目的说起。中台本质上是一种架构方式，目的是为了实现复用，减少重复投入，提升效率。在中台架构中，平台处于什么样的位置，起什么作用是中台研究需要厘清楚的问题。如果把这些问题考虑清楚了，也就容易理解中台和平台的区别了。

中台本质和目的

中台的本质是一种分布式应用系统分层架构方式。有企业直接分为前-中台架构，也有企业分为前-中-后台架构。不管分为几层，这其实并不是一种新的技术或架构，只不过在企业规模化发展到一定阶段，企业资源（数据、应用、人力等）如果无法实现复用，其交互和协作成本和代价往往是级数增长，不得不调整来实现资源复用以提升效率的方法。简单地思考一个问题：设想数据散落于不同的系统之中，这势必会带来数据的大量冗余。随着企业规模的不断扩张、系统数量的不断增长、系统交互的频繁复杂、数据量的爆炸性激增等等，仅仅冗余数据就可能会导致成数倍数十倍的浪费。前些年的 SOA-ESB 架构就曾尝试从业务层面的集成来解决这样的问题，但 ESB 最大的缺陷是没有从数据层面考虑，只做业务系统集成而没有触达数据，数据依旧散落于各个单体系统中。ESB 通过加层集成的方式来尝试解决复用问题，但加层集成的方式也使系统层次复杂化，响应链路变长，响应延迟增加，从而导致很多 ESB 项目并不成功。而中台的思想是包括从数据层面来重构企业整体架构，这就解决了单体系统数据散落的问题，从数据层和业务层实现了复用。另外应用系统还涉及很多的公共组件和能力，比如日志、认证和权限、配置、消息、安全等，这些公共的技术组件往往是可以复用的。这也使很多人误把平台当作了中台。虽然中台和平台在内容上有重叠的部分，但其概念是有本质区别的，不能混为一谈。业务、数据、公共技术组件的可复用能力提取就是中台的能力。从而以重构的方式从架构层面彻底解决了业务、数据、公共技术组件的复用问题。

中台架构层次划分

中台复用的粒度

软件一直都在尝试实现复用，从代码复用、函数复用、类复用到组件复用、服务复用、平台复用等不同层级和粒度的复用，各有优缺点。对于分布式中台架构来说，哪种复用粒度是合适的？哪种复用粒度的价值最高？从这些年技术的发展来看，云计算解决了算力问题，使数据可以通过分布式计算来支撑大数据运算需求，有了大数据才带来了人工智能的快速发展。云计算的云原生技术：容器、微服务、DevOps 等为中台架构的复用粒度提供了一种很好的解决方案，那就是服务化或微服务化（微服务粒度是另一个概念）。服务层级的复用粒度更适合中台架构。从数据、业务、公共技术组件层次可以推导出可复用的数据服务、业务服务和技术服务，从而构建起数据中台服务、技术中台服务和业务中台服务。通过中台服务的编排而实现敏捷构建业务应用（实际就是应用 client 端），从而支持响应企业业务的敏捷变化和变革，快速实现数字化和智能化转型。

技术组件、数据、业务流程服务化以实现可复用

中台可复用服务来自哪里？数据服务来自于各系统融合后的可复用数据抽象和提取，比如说客户数据，多个业务系统都会用到客户数据，因此客户数据就可以构建为可复用数据服务，从而也实现了数据的一致性和完整性。其实这也是主数据建设的主要任务。主数据就是企业内共享和复用的数据，以企业主数据来构建中台数据服务，是一个相对比较好的方式。技术中台服务则来自于公共的技术组件，比如说登录认证，每个业务系统都需要登录认证模块。传统单体系统每个业务应用都要开发一遍登录认证，这就造成了大量的重复建设和浪费，如果把登录认证提取为中台公共认证技术服务，每个系统都可以共享使用这个服务，不但提升研发的效率，而极大地减少重复建设和投入。中台业务服务则意味着业务流程的新建或者业务流程的重构。业务服务的设计有个简单的方法，就是通过梳理业务流程来找出流程交叉点，这个交叉点就是一个业务服务（或叫业务服务操作 Operation）。例如在不同的业务流程中都会用到“客户信息查询”，这个“客户信息查询”就可以作为客户业务服务的一个操作。通过这样方式比国外某著名企业所推的 DDD 简单的多，也更符合企业实际业务逻辑。

平台支撑中台架构

既然中台架构中合适的粒度是服务化，那么无论数据服务、公共组件服务、业务服务都需要有相应的平台来支撑运行。数据服务需要数据库或数据仓库或大数据平台等来支撑，公共组件服务需要诸如日志平台、认证平台、权限平台、配置平台、安全平台、消息平台来支撑，即便是服务通过编排的轻量应用客户端，也需要部署于不同的渠道来触达不同的客户，比如 App、Web、微信小程序等，都需要这些平台和工具的支撑。因此我们说“平台支撑中台”，用平台能力支撑着中台可复用服务，以及前台轻量应用。从中台架构来说，这些平台、工具就是中台架构中的“后台”运行支撑平台。

从架构角度，每个平台或系统都可能划分为前、中、后等不同的层次，其实中台架构层次并没有从根本上脱离“业务表示层、业务逻辑层和数访问层、运行支撑层（包括数据存储层）”这样的架构层次划分。中台是从架构角度来说的，而平台是从技术角度来说的，平台和中台是完全两个概念。平台的架构可能分“前、中、后台”，只不过新的“中台”概念被赋予了新的内涵，涵义更广。不过从企业系统落地的可行方案来看，需要明确区分这两个概念才能更好的去实施“中台”，才能使“中台”具备落地可行性。

系统架构层次与中台架构层次

中台架构中的前台或前端是“轻量应用客户端”，中台或中间层是可复用服务（可以是微服务，也可以是 ESB 服务等），后台或后端是支撑这些可复用服务运行的工具或平台，因此可以说“平台支撑中台”。这些平台一方面支撑着中台可复用服务，另一方面也意味着平台支撑着中台架构。

以重构的方式，意味着企业业务系统会逐步被重构的服务和应用取代，拆分为数据服务、业务服务和应用 Client，以及基础的技术组件服务。数据实现融合，以标准化的治理的数据存储于数据库或数据平台之中，彻底解决了数据散落的问题。不再有一个一个独立的单体系统，而是实现了高度复用的中台服务和前台轻量应用客户端。根据业务需要通过服务编排敏捷响应业务变化需求。

系统架构演化趋势

明确区分中台和平台的好处

第一、明确了中台和平台的概念和区别，在进行中台建设时就能有的放矢，不会混淆。中台是从架构角度来说的，明确了中台架构，也就知道了架构的前、中、后台各是什么，就有了明确的方向。建“中台”就是建设“可复用服务”，这使中台建设的目标非常明确。有了可复用服务，就能通过编排来快速构建业务应用。随着可复用服务量的增加，会带来业务应用研发质的变化。

第二、松耦合了平台和中台可复用服务，明确了可复用能力的粒度。以平台作为可复用层次，则显得粒度过粗，在复用时也需要很多额外的工作。比如说消息平台，是可复用于各个业务系统的。但要使用这些平台，需要使用其提供的 API 来实现对接，API 一旦变动，则使用这些 API 的服务就需要改变，这就带来了很多工作量。而在平台之上提取、抽象、封装一层可复用服务，源于平台而高于平台，比如“消息批量发送服务”，其支撑平台可以是 Kafka、RabbitMQ，ActiveMQ 等等，则通过封装的可复用服务 API 可直接用于业务应用的编排。底层平台的变化对业务应用来说是透明的、不可见的。

第三、中台和平台分离，则更好地实现自主可控，不再受制于人。松耦合中台可复用服务和平台之间的关系，则在更容易更换中台下的支撑平台，对上层业务应用不可见，从而根据需要而采购或研发支撑平台，不再因为受制于某厂商的产品而迟迟难以有进展。

第四、契合系统架构演化趋势。自云计算解决了算力问题，我们可以不需要过多关注基础设施资源。不管通过 ESB 集成，或者通过微服务重构，都在解决业务、数据、组件的融合复用问题。系统架构演化趋势是从单体架构走向分布式融合架构。中台服务架构提供了一种可行的分布式融合架构落地方式，为企业业务系统的架构和建设提供了可行方案。