好像就有一只无形的手，将“微服务”、“平台化”、“中台化”撮合在一起

原来除了我们熟悉的“前台”和“后台”外，居然还有个“中台”这样一个神奇的存在。

中台到底是什么？会不会又是另一个Buzzword呢？这个从名字上看像是从前台与后台中间硬挤出来的新断层，它与前台和后台的区别和界限到底在哪儿？什么应该放到中台，什么又应该放到前台或是后台？它的出现到底是为了解决什么问题呢？

在有些人眼里：中台就是技术平台，像微服务开发框架、Devops平台、PaaS平台，容器云之类的，人们都叫它“技术中台”。
在有些人眼里：中台就是微服务业务平台，像最常见的什么用户中心，订单中心，各种微服务集散地，人们都叫它“业务中台”。
在有些人眼里：中台应该是组织的事情，在释放潜能：类似于企业内部资源调度中心和内部创新孵化组织，人们叫它“组织中台”。

中台的核心本质
一句话：中台的核心本质就是：业务为本、网络连接、数据智能。

中台迷思

• 在有些人眼里：中台就是技术平台，像微服务开发框架、Devops平台、PaaS平台，容器云之类的，人们都叫它“技术中台”。
• 在有些人眼里：中台就是微服务业务平台，像最常见的什么用户中心，订单中心，各种微服务集散地，人们都叫它“业务中台”。
• 在有些人眼里：中台应该是组织的事情，在释放潜能：平台型组织的进化路线图 (豆瓣)中就提出了平台型组织和组织中台的概念，这类组织中台在企业中主要起到投资评估与投后管理的作用，类似于企业内部资源调度中心和内部创新孵化组织，人们叫它“组织中台”

更多的情况是大家为了响应企业的“中台战略”，干脆直接将自己系统的“后端”或是“后台”改个名，就叫“中台”。

对于中台的理解：

• 现阶段中台的概念，几乎可以与“产品”划等号；
• 中台并非企业实现数字化转型的根本需求，平台才是市场所需要的东西；
• 不能跟风创业，要有自己的视野和理念；
• 现在过分夸大中台的能力，其实中台只是数字化建设过程中非常小的一部分；
• 思想与视野不要被中台的概念所禁锢，企业需要的是数字化平台，并非中台。

前台、中台、后台的定义

• 前台：由各类前台系统组成的前端平台。每个前台系统就是一个用户触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站，手机App，微信公众号等都属于前台范畴。
• 中台： 中台是真正为前台而生的平台（可以是技术平台，业务能力甚至是组织机构），它存在的唯一目的就是更好的服务前台规模化创新，进而更好的响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接。它是在前台与后台之间添加的组“变速轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁。它为前台而生，易于前台使用，将后台资源顺滑流向用户，响应用户。它提供了比前台更强的稳定性，以及后台更高的灵活性，在稳定与灵活之间寻找到了种美妙的平衡。中台的本质是业务能力的沉淀，它对于企业提高需求响应、降低定制成本、实现弹性稳定、实现系统互通、提升运营效率和降低资源成本具有独特的优势，而中台的成功建设，需要组织、技术和相应的方法论的支撑。
• 后台：由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。

什么是“大中台、小前台”

阿里巴巴 “大中台、小前台”机制的提出，某种程度上是从传统的事业部制向准事业部制的转换。就阿里巴巴而言，“前台”就是贴近最终用户/商家的业务部门，包括零售电商、广告业务、云计算、物流以及其它创新业务等；而“中台”则是强调资源整合、能力沉淀的平台体系，为“前台”的业务开展提供底层的技术、数据等资源和能力的支持，中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑。

前台和中台本质上是工作分工的问题。比如，某部门要开发一款App，是部门内部（大前台）自己组织一套技术、产品、设计、运营的团队，还是集团为其提供资源（大中台），由专门的技术团队来帮助其开发、设计产品等等。

阿里的中台

阿里的中台大约有十几个共享业务单元，包括用户中心、商品中心、交易中心等。淘宝、天猫、聚划算等 25 个大型业务应用都是由中台的共享业务单元支持的，共享业务单元则由阿里云平台支持。

共享业务单元的划分原则其实不是可以简单掌握的，要综合考量设计、运营和工程因素，尽可能遵循「高内聚、低耦合」、「数据完整」、「业务可运营」和「渐进」的原则。阿里在划分中台时非常重视其业务价值和基于业务的设计，而且有业务架构岗位，每个共享单元都有业务架构师。但总体来讲，其业务架构仍然是领域性的。

阿里系统要解决的核心问题是高并发、可扩展，也就是说，规模带来的复杂度对阿里而言更具挑战性。因此，业务通过中台进行共享支持后，基础设施必须能够消解这种压力。阿里采用去中心（也就是去 ESB）的 HSF 分布式服务框架，以支持服务的点对点调用，解决 ESB 可能产生的瓶颈问题；采用微服务设计方式，提高变化响应，并通过大力推行 DDD（领域驱动开发）设计模式，提升设计效率；自研设计了分布式数据层框架 TDDL（Taobao Distributed Data Layer，又称「头都大了」）以及分布式数据库 DRDS；研发了支持分布式事务处理的 AliWare TXC；支持高效故障定位和运维监控的鹰眼平台；实现了限流和优雅降级设计，以及做保障的全链路压测平台、业务一致性平台等。这是一套完整的基础设施，提供针对电商业务特点的支持。

阿里中台是其自身在业务不断发展的过程中演进和磨合出的架构，其架构即体现了电商的业务特色，也包含了完整的技术支持体系。由于其灵活支持和快速响应能力，成为了互联网架构的优秀实践案例和设计标杆。

数据业务双中台

阿里中台主要体现为由业务中台和数字中台并肩构成的双中台，并肩扛起了所有前台业务。

• 业务中台将后台资源进行抽象包装整合，转化为前台友好的可重用共享的核心能力，实现了后端业务资源到前台易用能力的转化。
• 数据中台从后台及业务中台将数据流入，完成海量数据的存储、计算、产品化包装过程，构成企业的核心数据能力，为前台基于数据的定制化创新和业务中台基于数据反馈的持续演进提供了强大支撑。
• 业务中台与数据中台相辅相成、互相支撑，一起构建起了战场强大的后方炮火群和雷达阵。

移动中台

移动中台是构建在业务&数据中台之上，为更好更快的利用中台能力、快速迭代移动端产品，又生生的挤出（或是说沉淀）出了一个新的中台层。

技术中台

技术中台就是将使用云或其他基础设施的能力以及应用各种技术中间件的能力进行整合和包装。过滤掉技术细节，提供简单一致、易于使用的应用技术基础设施的能力接口，助力前台和业务中台数据中台的快速建设。

研发中台

软件开发是一项工程，涉及到管理、流程、测试、团队协作等方面。如何将企业的开发流程最佳实践沉淀成可重用的“能力”，从而助力创新性应用的快速开发迭代，也是我们看到的很多企业正在做的事情，我们可以管这种关注与开发效能管理的平台叫做研发中台。如果说技术中台为前台应用提供了基础设施重用的能力，那研发中台就为前台应用提供了流程和质量管控以及持续交付的能力。

组织中台

组织中台很像企业中的内部风投和创新孵化机构，为前台组织和团队构建创新型前台应用提供类似于投资评估（项目甄别）、投资管理、投后管理（孵化与风控），真正从组织和制度上支撑前台组织和应用的快速迭代规模化创新。

中台战略的成功、能否实现技术架构与组织架构的匹配，是一道绕不过去必须要迈过的门槛。从阿里成立共享事业部，海尔的人单合一、职能并联到近期大家关注的腾讯的组织架构重构都是这些企业在这方面做出的努力。

一切以”以用户为中心的持续规模化创新”为目的，将后台各式各样的资源转化为前台易于使用的能力，帮助我们打赢这场以用户为中心的战争的平台，我们都可以称之为中台：

• 业务中台提供重用服务，例如用户中心，订单中心之类的开箱即用可重用能力，为战场提供了强大的后台炮火支援能力，随叫随到，威力强大；
• 数据中台提供了数据分析能力，帮助我们从数据中学习改进，调整方向，为战场提供了强大及时的雷达监测能力，帮助我们掌控战场；数据中台主要是提供基础数据处理能力和很多的数据产品，给所有业务方去用，也就是说相当于数据中台也是，对前端业务主要输送的是数据产品。
• 移动及算法中台提供了战场一线火力支援能力，帮助我们提供更加个性化的服务，增强用户体验，为战场提供了陆军支援能力，随机应变，所向披靡；
• 技术中台提供了自建系统部分的技术支撑能力，帮助我们解决了基础设施，分布式数据库等底层技术问题，为前台特种兵提供了精良的武器装备；
• 研发中台提供了自建系统部分的管理和技术实践支撑能力，帮助我们快速搭建项目，管理进度，测试，持续集成，持续交付，是前台特种兵的训练基地及快速送达战场的机动运输部队；
• 组织中台为我们的项目提供投资管理，风险管理，资源调度等，是战场的指挥部，战争的大脑，指挥前线，调度后方。

中台架构

从中台应用的形式架构来说，首先是会基于云的基础设施上，能够动态的基于云的利用，来解决我们刚才说的高迸发大数据的挑战。

在此基础上，在中台环节更多地会强调用微服务架构快速适应变化的方式，来解决数据不互通，或者能力不重用的问题。当然，这在整个中台的建设过程当中，我们也希望要用互联网的开发工具，通过敏捷组织和我们持续集成、持续交付的方式来提升我们整体的研发效率。所以，可能也会涉及到研发中台等这些技术层面的东西。

对于我们中台架构的建设来说，更多强调的是在微服架构和分布式部署。所以，这里我们大家常规或者大家普遍讲的中台主要是包括业务中台、数据中台和技术中台，这个是在数字化层面说的中台。

中台理解成是把企业的资源整合转化为前台，就我们业务前台使用的能力，主要是支撑前台业务的快速变化，最终目的还是要提升企业的用户响应力。

中台架构的转型或者升级策略

第一种：固旧立新

保留原有的系统，利用新建的系统来做中台架构的试点，或者叫搭建，逐步沉淀能力。为旧有的、已有的系统改造重建，迁移到综合架构做好基础。我们在很多企业是这么做的，包括中国石化、宝洁，包括原来阿里做的中国化工集团都是类似这种方式。就是旧的系统不动，新建的系统就用重开架构来建设，逐步沉淀能力的方式，逐步去把旧有的系统进行迁移改造。

第二种策略：平滑迁移

保持现有系统正常运行，在中台层面逐步沉淀中台的共享服务中心，或者叫能力中心。完成中台建设以后，前端界面不动，把前端应用，逐步把调用关系改到中台来，实现升级改造。这种方式就对于前端的运行是不影响的，也就是我们的用户操作是无感知的。就实现了中台升级的迁移，所以我们叫平滑迁移。

第三种策略：不破不立

把原有的系统，那些不能满足业务要求的，利用中台架构全部重新构建。这种策略把原有的体系都会颠覆掉。

对于中台建设,组织、技术和方法论三者不可或缺

从组织的角度，中台需要整合资源，让懂业务人参与，其次，在BU、BG、企业、集团各个层次都可以建设中台，但必须是各层次的一把手工程，否则难以调配资源。

从技术层面，建设在线业务中台需要微服务、DevOps、分布式事务和云原生技术体系的支撑，建设数据中台则需要指标管理、数据服务、元数据管理、数据仓库开发与管理、数据质量管理、数据安全管理、数据资产管理，以及大数据计算引擎、数据集成/同步/交换引擎、敏捷BI系统等一整套典型的支撑技术。

作为能力的沉淀，除了工具，中台无疑需要流程/规范/方法论。目前业界存在许多相关的方法论，如六边形理论、领域驱动设计（DDD）、指标设计方法论等，但大都与技术相关，在中台组织层面尚无成熟的方法论。

云技术上半场是：

1. UI层：移动App、微信小程序
2. 逻辑层：分布式微服务、分布式消息中间件
3. 数据层：分布式关系数据库、分布式NOSQL数据库
4. 数据层：实时大数据计算平台
5. 基础设施层：虚拟化、容器

云技术下半场应该是：

• UI层：IoT智能硬件传感器、麦克风语音交互、摄像头视觉识别
• 逻辑层：人工智能关联推荐&最佳资源调度
• 数据层：跨链区块链
• 基础设施层：量子计算（感觉有点梦幻，真的嘛？）

采集数据手段：

• 智能硬件传感器收集
• 摄像头视觉识别收集
• 麦克风语音交互收集
• 互联网爬虫收集
• 互联网OpenAPI来收集

观点：中台已死

• 中台是为了解决技术响应业务效率的问题的。是阿里业务和技术复杂度到一定程度的体现。中台如果能得到解决，阿里必然在业务系统的设计能力上得到升华。不但能快速提升现有业务的响应和扩张能力，而且会有足够的兵力投入到下一个战场。
• 判定中台成功的一个另外的显著指标是996，是不是更严重了，还是减轻了
• 现在宣布以云为主，被集成，不做SAAS
• 中台本是为业务而生。云没有多少这个需求。名词偷梁换柱，实现内容为云而不是业务系统。是遮羞布。
• 阿里云不甘心只卖云，所以搭上“中台”这么一个高大上的噱头；但阿里云本身没有足够的实施能力、也没有意愿掺和低价值的系统外包，所以扶植一群小弟帮自己落地；小弟的水平有高有低、甲方爸爸的心情时好时坏，最终中台项目普遍效果较差；第一轮坑央企、第二轮坑行业头部企业、到现在第三轮轮到中小企业的时候大家都不想白白上当了。。。所以，找个台阶下，回归云服务本质。。。不过中台建设的风潮还没结束，之前扶植的小弟还嗷嗷待哺，所以干脆放手，让小弟们自己产出各种解决方案，阿里云挑一些还算好看的一起推广，以达到“共同繁荣”，实则自生自灭去吧~~

相关资料：