不是你需要中台，而是一名合格的架构师（附各大厂中台建设PPT）

Posted 2022-01-27 肉眼品世界

导读：年前，关于中台的说法，众说纷纭，以36氪影响力、国酒茅台、离职CIO、失败项目等诸多热点，迅速成为热文，在朋友圈转发；而后又有很多说《不是中台不行，是你家的中台不行》，后面的说法其实不错的，这里我们更加深入分析一下到底中台好不好，到底为什么有的中台行，有的中台不行，技术架构上都大同小异，那什么会导致一样的架构不同的结果呢，原来我们除了技术架构，缺少一个真正核心要素：你的业务和组织架构是否需要阿里一样架构的中台，你的团队是否有一个能够实施切合业务实际中台的Leader或者架构师。

更多优质内容请关注微信公众号“肉眼品世界”（ID：find_world_fine）

中台，早已有之，在银行系统，在各行各业中台这波操作早已开始操作，就是复用，组件化，治理公共化，没有那么神奇，每个研发人员最起码的编程思维；但是，为什么阿里的中台就能风风火火，并且产生了很大的效果，那是因为阿里的业务体系大到很大了，各自为战的造轮子已经太浪费资源了，所以有一批人专门抽出来做这些公共服务，并且用一种组织机制和技术机制来告诉大家，你用这个组件只能调用这个，不能再造轮子，那么对这个体系的管理和支撑就需要很大人力，再加上云计算的主要业务，对阿里来说也是资源复用的；所以在考虑阿里一样的中台架构的时候，先想想，是不是业务也达到阿里一样的程度了？是不是需要和阿里一样的中台架构才显得自己专业？实施专业中台架构需要额外的人力和组织来保障，你是否找到了一个足够专业的架构师？即使是Leader也必须充当架构师的角色，没有这个架构师，光看光鲜的技术，那是不行的，所以市场上自然有了，你家的中台不行，人家的不错；重要的事再说一遍：或许你要的不是一个高贵的中台架构，你要的是一个专业可靠的架构师告诉你在当前情况下该怎么架构。与其迷信或者摇摆，不如先把自己的业务搞清楚，搞透彻。

什么是中台

中台就是公共服务平台，数据中台就是将数据加工以后封装成一个公共的数据产品或服务。

虽然中台架构早已有之，但是马云阿里让这种技术架构有了一个统一的名词，并让它声名远播，是对整个技术社会的贡献。

没有中台的时代

在传统IT企业，项目的物理结构是什么样的呢？无论项目内部的如何复杂，都可分为“前台”和“后台”这两部分。

什么是前台？

首先，这里所说的“前台”和“前端”并不是一回事。所谓前台即包括各种和用户直接交互的界面，比如淘宝购物页面，手机app；也包括服务端各种实时响应用户请求的业务逻辑，比如商品查询、订单系统等等。

什么是后台？

后台并不直接面向用户，而是面向运营人员的配置管理系统，比如商品管理、物流管理、结算管理。后台为前台提供了一些简单的配置。

前台、后台、用户之间的关系，可以用下图简单表示：

在当时，项目的发展相对稳定，并不需要那么快速的去迭代和试错，所以这种结构并没有什么问题。

在互联网快速发展的今天，企业之间的竞争越来越激烈。只有以用户为中心，快速响应用户的需求，不断迭代和试错，才能让企业在竞争当中立于不败。

但是，现实情况下......

在传统的前台-后台架构中，各个项目相对独立，许多项目都在重复发明同样的轮子，即让项目本身越来越臃肿，也让开发效率越来越低。

这种时候，为提高开发效率，我们有必要整合出一个中间组织，为所有的项目提供一些公共资源。而这个中间组织，就是人们所说的“中台”。我们可以看到，中台不仅包含服务器端的中间件，更包含一些业务中的业务公共件，本质始终没有改变：复用，减少开发维护成本，减少业务出错几率；要说真正牛气的中台就是云计算+云业务SAAS了，通过自由组合解决所有公司的业务场景。

中台的起源

中台是最早由阿里在2015年提出的“大中台，小前台”战略中延伸出来的概念。它的灵感来源于芬兰的小公司Supercell，这家公司仅有300名员工，却接连推出爆款游戏，是全球最会赚钱的明星游戏公司。

由于阿里业务的繁杂和量比较大，在中国，阿里巴巴率先提出了“大中台，小前台”的战略：

2015年年中，马云带领阿里众高管拜访了Supercell。2016年6月，腾讯宣布以86亿美元收购Supercell公司84.3%的股权。

Supercell的神奇之处在哪里？恰恰是这家小公司，开创了中台的“玩法”，并将其运用到了极致。这家看似很小的公司，设置了一个强大的中台，用以支持众多的小团队进行游戏研发。这样一来，各个团队就可以专心创新，不用担心基础却又至关重要的技术支撑问题。

Supercell的CEO潘纳宁更是将一个游戏公司按照一个专业运动队的方式来管理。他认为管理层的唯一使命是获得最好的人才，为他们创造最好的环境，给他们自由和信任，帮助他们摆脱困境，让公司成为一个最好的人才可以产生最大影响的地方。

其他的一切，包括财务目标，都是次要的。因此Supercell构建了完全颠倒的管理结构。传统的管理结构是一个金字塔形的，CEO往往处在金字塔的顶端。而Supercell最大的创新之处，在于其管理结构完全是上下颠倒的。潘纳宁最引以为豪的标签是：“行业里最没有权力的CEO”。

Supercell的整体架构采用“开发者领导”的模式。300人的团队被分成若干个小团队，5-7个游戏开发者组成一个小团队，开发自己的游戏，以最快的速度推出公测版，检测游戏受用户欢迎的情况。

这些小团队又被称为“细胞cell”，Supercell则是这些细胞的集合，这也是Supercell公司名的由来。由此可见，中台不是单纯的系统或平台，更是组织架构的重组和变革。

然而，企业的经营过程由多方面因素的共同作用。那么中台建设能解决多少问题？

中台解决了什么问题？

痛点一：企业前方市场与企业内部支撑的冲突

用户和用户的需求永远是善变的。依稀记得“80后是垮掉的一代”的说法的你，现在看到的却是“被10后毁掉的90后父母”的感叹。

主流用户的变化，不会因为某个年代人的话语权高低而稳定下来。而即便是同年代的用户，在随着现代社会发展和各行各业互联网服务的滋养中又进化细分成了出不同的支流，需求全然不同，呈现场景化、碎片化的特征。

为了不被善变的用户所抛弃，企业不得不跟随着用户；为了满足用户而尽可能积极地响应用户需求的变化，发展新业务、提供新服务。这就给企业的前方业务端提出了挑战：必须做到快速响应、灵活运转。

但要作为一个能承接大量新业务和新服务的大体量企业，业务想要做到量大又灵活，必定需要靠企业内部科学有序体系的稳定支撑。

所以，企业前方市场总是会趋于变化无序，而企业内部支撑总归要趋于稳定有序，两者必定冲突。

痛点二：前台与后台的冲突

企业前方市场和企业内部支撑的冲突，必定带来在系统层级上的前台和后台的冲突。

前台：企业前方市场的管理平台，是企业的终端用户直接使用或交互的系统。比如像微信、QQ、淘宝这样的APP；

后台：企业内部支撑的管理平台，是企业管理核心能力的系统。比如像企业ERP管理平台、企业财务管理平台等系统。

前台是对接用户的，所以系统需要快速响应前端用户的需求，快速创新、快速迭代。简而言之：快速建设、错了就推翻重来、不能耗费太大成本。

后台是企业对内的，为了支撑前台越来越多的业务，后台不断地建设，系统不断庞大地起来。所以后台系统需要扎实稳定，建成之后往往不能随意改动。简而言之，是需要耗费大力成本建设的基础能力、不能轻易推翻、改动成本极大。前台系统和后台系统的特点决定了，两者的冲突不可避免。

痛点三：大企业的通病（各占山头、重复建设）

企业发展到一定程度，组织架构和层级必然不断膨胀扩张。各大事业部下各大部门，就像一个小型组织一样，各占山头，势必会出现屁股决定脑袋的现象：这事就算对公司有好处，但对我们部门KPI没好处啊，那我不做。

大企业内部各处都是墙——部门墙、业务墙、数据墙。更不用说那些一味的内部赛马的绩效考核机制，势必更加加剧部门间的相互封闭。

而一些原本可以快速提供的用户服务，却需要多重对接，无法快速拿出产品方案，耗费很大的成本和极长的时间。一个原本可以共用的服务，被不同部门重复建设。

中台的类型有哪些

中台的分类不同的厂家有不同的分法，但都大同小异，总结起来都是业务中台，技术中台，技术管理中台，组织架构中台；

按照目前普遍的说法，中台分为6类：

数据中台：提供数据分析能力，帮助企业从数据中学习改进，调整方向。

业务中台：提供重用服务，例如用户中心、订单中心之类的开箱即用可重用能力。

算法中台：提供算法能力，帮助提供更加个性化的服务，增强用户体验。

技术中台：提供自建系统部分的技术支撑能力，帮助解决基础设施、分布式数据库等底层技术问题。如中间件，分布式存储，AI，负载均衡等基础设施

研发管理中台：提供自建系统部分的管理和技术实践支撑能力，帮助快速搭建项目、管理进度、测试、持续集成、持续交付。

组织中台：为项目提供投资管理、风险管理、资源调度等支持。

各大厂中台架构

学习大厂经验，是指导我们工作必要的方法（由于篇幅有限，我们将展示主要典型厂家案例分析，后面会附带大部分大厂中台架构PPT连接），但是切不可照搬照用，包括我们自己发的内容，一定要结合自己的实际情况实际处理，不能因为这样好那样好折腾了自己的团队，最好的中台是你自己的团队，相信自己的团队，构建自己的想要团队，帮助他们与他们一起进步，或许这是比高贵中台更重要的事情。

这里收集了一些各大厂中台建设的详细PPT，核心一点：要不要中台，要怎么样的中台，多吸取知识，实际情况实际出发，具体怎么做，找一个合适的架构师把，其他都是众说纷纭，没有好坏，只有最适合；不迷信，不盲从，充分认知和技术积累，逐步实施。

01

阿里：“大中台、小前台”战略

业务中台是阿里巴巴首先提出的作为企业IT架构的转型之道。站在阿里巴巴集团全局的角度，业务中台是从整体战略、业务支撑、连接消费者和业务创新等方面进行统筹规划。因此业务中台深深内含了阿里巴巴做为电商交易的主营业务。业务中台关注的更多的是如何支撑在线业务。

阿里的“大中台、小前台”战略，驱动着：新零售、金融、物流、营销、旅游、健康、大文娱、社交八大战略。

而中台架构，也逐渐升级成为“数据中台+业务中台”，即“双中台”战略。

大家耳熟能详的，淘宝、天猫、聚划算、盒马、阿里健康等业务，背后都有中台架构的支撑。

数据驱动业务的典型场景

以《微微一笑很倾城》这部剧为例，这部剧播放10天破60亿播放量。在购买决策以前，通过舆情分析、文学内容排行榜监测，锁定了题材和内容的受关注程度，就找到了符合标签特性的《微微一笑很倾城》。

这部剧在视频平台播出期间，分析了第一波追剧的观众标签画像，将该剧推荐给有类似标签的人群，观众基数越滚越大，形成了现象级热播剧。

同时，根据观众留言标签聚合，又招到了类似的剧集进行购买，把这一题材剧集及时推出，也取得不错的播放率。

阿里数据中台体系的核心要素

阿里数据中台体系核心要素包括：数据资产化、创新敏捷化、平台智能化、服务产品化。下面展开分享。

数据中台：数据资产化

OneID体系，以业务/自然对象+萃取标签为架构构建，实现统一数据，即：用户统一、企业统一、商品基础数据统一等等。

OneData体系，以业务板块+业务过程+分析维度为架构构建，业务数据指标维度的统一，杜绝一个指标多种定义。

实现数据的统一采集，接入等。

阿里巴巴一开始通过淘宝作为平台方连接商家和消费者，进行电商交易活动。随之发展出淘宝商城即后来的天猫。天猫本质上还是电商交易平台。既然都是电商交易平台，就都涉及售前、售中和售后的业务流程。

业务中台围绕以交易为核心所关联的领域组成。交易的对象是商品，商品通过店铺售卖给会员，交易的凭证是订单，在线交易需要支付，成单后需要货品出库和物流派送等，售前需要营销促销活动吸引流量加强转化，售后用户会对店铺、商品进行评价等。由此，典型的业务中台表现为由多个业务服务中心组成，如图3-3所示。

▲图3-3 一个典型的由服务中心组成的业务中台

会员中心服务于用户的消费全生命周期，为用户提供特定的权益和服务，企业可以通过会员中心进与用户进行互动，培养用户忠诚度。主要能力包括：

会员运营管理：会员注册、个人信息维护、会员注销、会员卡办理等相关能力。

会员体系管理：会员体系的创建、积分规则、成长值规则、等级、权益等相关能力。

客户服务管理：包括客户的新增、导入、查询等相关能力。

积分交易管理：包括积分获取、核销、清零、冻结、兑换等相关能力。

商品中心提供管理商品核心数据的能力。围绕商品构建商品关联数据，诸如商品版本信息、商品品牌、商品属性、商品类目等。主要能力有：

品牌、类目、属性管理：包括对商品品牌的维护、查询，前后端类目的维护，属性及属性组管理等相关能力。

产品数据管理：包括对产品模板的创建、编辑、查询、禁用等相关能力。

商品数据管理：包括创建商品、修改商品、查询商品等相关能力。

商品发布管理：包括商品发布、上下架（即时+定时）等相关能力。

交易中心负责企业业务交易订单的整体生命周期管理，包括加入购物车车→订单生成→合并分拆→流转→支付→发货→退换货→完成。所有电商业务的核心系统都是围绕交易订单进行构建的。主要能力包括：

购物车管理：包括购物车商品添加、编辑、查询、校验等相关能力。

正向交易管理：包括交易订单生成、发起支付交易订单、商品发货管理、上门自提及核销等相关能力。

逆向交易管理：包括商品换货、退货、退款等相关能力。

订单数据管理：包括交易订单数据、支付记录、发货记录、换货记录、退款记录等数据管理能力。

交易流程编排：支持交易流程节点的配置化，便于根据业务场景的不同设置与之匹配的流程。

评价中心提供对评价主体对象、评价规则/等级、评价内容、评价操作的管理能力，从而满足了不同角色的评价用户对评价内容的发布、追加、平台审核、平台申诉等需求。主要能力包括：

评价内容管理：包括评价的主体对象管理、评价规则配置、评价等级、评价标签配置管理等相关能力。

评价操作能力：包括评价的发布、修改、追加、回复、申诉等相关能力。

评价监管能力：包括评价发布审核、申诉审核、评价屏蔽等监管相关能力。

店铺中心提供企业店铺主体管理、店铺管理、类型管理、经营对象管理等能力以支持企业为其商户用户提供线上门店，同时也支持商户管理、店铺会员、店铺会员等级管理、店铺装修等。主要能力包括：

商户管理：包括商户单个、批量开通，商户审核，商户基本信息维护等相关能力。

店铺管理：包括店铺开通、店铺基本信息维护、店铺审核、店铺会员等相关能力。

支付中心给下游商户输出标准的支付服务，提供代付代收、财务对账等服务。通过对接多个主流渠道，稳定输出微信、支付宝、银联等支付能力。主要能力包括：

支付能力：包括创建支付订单、接收渠道通知、渠道订单查询等基本支付能力。

支付路由：包括支付渠道管理、支付方式管理、支付商户和应用开通管理等相关能力。

资金账户：包括资金账户管理、充值维护、提现等相关能力。

营销中心提供商家的活动计划、申报、审批、执行、核销的全链路管理，也提供了基本的促销能力，如优惠券活动、满减买赠等。主要能力包括：

活动模板管理：包括营销活动的策略模板、规则配置、条件、动作模板等相关能力。

活动管理：包括具体活动的基本信息配置、人群圈选、商品管理、触发条件等相关能力。

优惠券管理：包括优惠券的发放、领取、查询、使用核销等相关能力。

赠品管理：对于满赠、买赠活动，提供赠品维护、查询、启用、禁用等相关能力。

库存中心提供仓库、库存、货品、单据（入库单/出库单/盘点单/盘点盈亏单）、审核（调拨/盘点），包裹、货品运费、物流运输、接入第三方物流公司的服务能力。主要能力包括：

仓库管理：包括服务区、仓库、仓位及其关联管理等相关能力。

货品管理：包括货品进货入库、销售出库、调拨入库、调拨出库、调拨审核等相关能力。

货品盘点：包括盘点单生成、审核、查询等相关能力。

履约管理：包括库存检查、发货单创建及查询、包裹物流查询、运费管理、物流状态跟踪等相关能力。

建设了一套中台系统，则可同时运用在多个电商平台的开发设计和服务中。因此，中台可以为同时建设运营多套电商平台的互联网企业节省系统建设和运营成本。因为既可以避免功能重复建设，又可以通过全渠道打通会员、增加流量、互相促进，还可以减少运营成本和人员。有了中台，再发展电商相关应用就会变得更加容易。比如，阿里巴巴发展出的聚划算。

如果使用传统的系统思维来设计业务中台，很有可能只是将原先隔离的各业务系统通过微服务的方式，强行集成在一起，如图3-4所示。这种方式构建的微服务不是纯粹的领域建设，而是一个系统的粒度层次。比如PMS会涉及用户和订单，OMS也需要关注会员和订单，CRM同样涉及会员。

因此，按此方式建设的所谓中台，它的各组成部分还是互相交叉重叠的，并不能体现中台是能力共享平台的核心理念。所以，只将企业业务系统做了一个大一统的集成，并不是中台。

▲图3-4 传统思维下所建设的“业务中台”

03 数据中台定义及建设内容

数据中台是什么？

数据中台与数据仓库有什么区别？

数据中台到底怎么与业务中台融合？

这三个一直以来是人们问得最多的问题。本节将试着对这三大问题进行一一解读。

在回答数据中台是什么这个问题之前，先了解一下大家比较熟悉的数据仓库是什么。在以BAT为首的互联网公司蓬勃发展起来之前，国内三大运营商对于数据仓库的建设走在其他行业的前面。

早在2011年的时候，中国移动集团公司就组织编写了指导各省公司建设数据仓库的纲领性文件《中国移动NG2-BASS3.0建设规范》。在文件中明确将中国移动的业务分成了7大业务板块，按照功能将数据资产划分为三层：数据层、功能层、应用层。这是很典型的数据仓库建设的分层模式，如今的数据中台数据分层建设模式也延续了数据仓库的分层建设规范，后面会详细讲到。

数据中台：服务产品化

以数据体系为基础，包括：营销数据体系、内容数据体系、商家数据体系、供应链数据体系、流量数据体系等。

形成了多个数据分析产品，包括：行业分析产品、活动分析产品、内容分析产品、流量分析产品等。

向上赋能业务、赋能平台、对双11大促的支持。

数据中台：OneData方法论驱动的平台智能化

在OneData方法论驱动下，实现平台智能化：

OneModel。100% 消除指标二义性，分钟级代码自动生成。

OneID。全域连接、立体刻画，分钟级标签萃取。

OneService。主题式数据服务，简化 80% 数据查询。

数据中台：创新敏捷化

通过数据中台，能够为企业提供快速创新的能力，让企业低成本试错。

从产生新思路-->通过数据中台工具赋能，快速验证-->创意演进成新的成熟平台。

企业数据中台：“欲速则不达”的陷阱

左边是企业数据“烟囱”的现状，大量低水平的重复建设。右边是“伪”数据中台，“形”统而“神”不统。

企业数据中台：方法论+自动化支持的逐层构建

是时候表演真正的数据中台了，右边是3个One方法论、数据服务平台化、数据资产的充分融合。

图3-5是应用层规划的内容，详细规划了每个应用领域的数据应用。但是仔细研究可以发现，这些数据应用几乎全是“分析”，也就是解决了事后“看数据”的问题。

▲图3-5 中国移动数据仓库分层模型

再来看看图3-6中阿里巴巴的数据中台支撑的数据应用层，除了通用的数据分析以外，还包含了“个性化推荐”、“风险评估”、“预警监控”等与业务紧密结合的数据赋能业务的应用。而这些丰富的赋能业务的数据应用必须依赖数据中台提供的强大的数据服务支撑。

▲图3-6 阿里巴巴数据中台总体架构图

通过上面的对比不难看出，数据中台与数据仓库最大的区别就是数据中台更加贴近业务，不只提供分析功能，更重要的是为业务提供服务，与业务中台或者业务系统（老旧系统）链接更加紧密了。

就拿大家比较熟悉的“千人千面”案例（如图3-7所示）来说，除了要整合业务系统产生的用户基础属性、订单、评价、加入购物车等行为数据，还要通过埋点的方式实时获取用户偏好浏览、搜索、分享商品等行为数据，经过数据中台一系列的数据加工处理后，最终以微服务的形式提供。

在业务系统每个需要呈现商品给目标用户的数据服务处，已不是简单的、一成不变地去商品库查询数据，而是调用数据中台提供的商品推荐接口，以此来根据不同的人群偏好、浏览历史、商品相似度等数据来为每个人推荐他最感兴趣的商品。试问这种业务、数据紧密联动的场景在数据仓库时代又如何能做到呢？

▲图3-7 数据中台与外部系统交互

在介绍完数据中台与数据仓库的区别之后，我们再回过头谈谈数据中台到底是什么。首先说说数据中台不是什么。

第一，数据中台不等于大数据。近些年来，“大数据”这个名词可能是被提及最多的词汇之一，大数据甚至成为国家战略。同时，“数据中台”也正是在大数据概念兴起之后应运而生的。因此，不可避免的，相当一部分人把数据中台和大数据划等号，一提到数据中台，天然的就想起Hadoop、Spark等大数据处理技术，这样的想法是不对的，这些大数据处理技术只是数据中台的基础设施提供者。大数据技术的大行其道，加速了数据中台战略成熟。

第二，数据中台也不是一个研发工具。最近一段时间，在市面上流行着一种说法，说某某公司有一个数据中台产品，可以直接卖给某某客户。这种说法是在忽悠客户。实际提供给客户的仅仅是一个可视化的研发工具而已。数据中台一定是整合了企业自身的数据并经过加工、治理后形成的企业自身的数据资产平台。试问，根本还没了解客户到底有什么数据的情况下，如何能说自己有一个数据中台产品呢？

那么如何定义数据中台呢？我们也曾尝试在网上找到一个标准答案，找过首倡“数据中台”概念的阿里大咖们寻求标准答案。最近网络媒体上各种数据中台分享、解读、峰会纷纷扰扰，各种解读真是乱花渐欲迷人眼，但都没有得到一个很精炼、标准的数据中台定义。但越是没有标准，越是被人问得多，这就是为什么开篇提到的第一个问题就是“什么是数据中台”。

经过这些年来对数据中台的一腔热血，也曾经为此翻阅大量资料，力求言简意赅，力求精准定义，我们认为：数据中台是一个用技术链接大数据技术能力，用业务链接数据应用场景的能力平台。

“链接能力”是数据中台的精髓。作为一个处在中间层的能力平台，“链接”是其根本的任务。

在业务层面需要尽可能链接各种数据源作为其生产资料；

同时，由于生产数据的场景越来越多，覆盖了线上、线下等多渠道，各数据生产资料之间也需要进行链接，才能形成全域的数据；

数据在数据中台这个平台上按照标准的模型进行规范的加工处理后需要服务于多种场景，同样需要我们提供标准的数据服务接口将数据与应用场景链接起来。

因此，链接是数据中台的根本能力，也是数据中台的价值所在。

04 业务中台和数据中台的关系

无论是业务中台还是数据中台，都是在企业IT系统架构演进过程中形成的，并从企业自身IT系统规划、建设、运营、运维等多年的经验中提炼出来的共性能力。

业务中台和数据中台作为两个轮子并肩构建了数字中台，支撑前台对会员的从营销推广、转化交易到智能服务业务的闭环，促进企业业务的提升和发展（如图3-8所示）。数字中台对内连接企业的后台系统，诸如ERP、人力资源、协同办公、财务管理等。

▲图3-8 业务中台与数据中台双轮驱动的数字中台支撑前台业务

业务中台抽象、包装和整合后台资源，转化为便于前台使用的可重用共享的核心能力，实现了后端业务资源到前台易用能力的转化，为前台应用提供了强大的“炮火支援”能力，随叫随到。业务中台的共享服务中心提供了统一、标准的数据，减少了系统间的交互和团队间的协作成本。

数据中台接入业务中台、后台和其它第三方数据，完成海量数据的存储、清洗、计算、汇总等，构成企业的核心数据能力，为前台基于数据的定制化创新和业务中台基于数据反馈的持续演进提供了强大支撑。可以认为数据中台为前台战场提供了强大的“雷达监测”能力，实时掌控战场情况，料敌先机。

不过数据中台所提供的数据处理能力和之上建设的数据分析产品，也不局限于服务业务中台。数据中台的能力可以开放给所有业务方使用。

从前台应用的角度，业务中台所提供的“炮火支援”能力和数据中台所提供的“雷达监测”能力是一体的，并不是截然独立的。业务中台与数据中台相辅相成，互相支撑。对于业务方来说，自己产生数据，并同时消费自己的数据，在消费自己的数据时又在继续产生数据，从而形成数据闭环。

打个比方，业务沉淀数据是产矿，将数据导入到数据中台是探矿和挖矿，数据中台对数据进行建模等加工处理是对矿物的加工提纯，通过数据服务指导业务的开展则是矿产再生的过程。业务中台和数据中台只是技术实现方式不同，但它们一起组成了支撑业务创新的两只轮子，缺一不可。 

02

华为数据中台

03

网易中台博弈与演进

04

百度中台

百度中台：百度由于是以搜索基础为核心的业务，那么其他业务在没有发展起来的时候投入的资源就不会那么多，和阿里的情况不一样，阿里有一个重要的产业：阿里云，那么它就必须建设强大的中台，同时阿里的各个业务线都是比较壮大，那么这个中台做好就能给各个业务线提供比较强的支撑。而百度，是以搜索技术为核心，其他业务都没有强大到阿里这种程度，就显得没有花大力气建设统一的大中台，但百度具有深厚的技术能力，业务视角， 中台提供了灵活的可定制业务框架， 使得业务可以聚焦业务特有逻辑的开发；中台还提供了可以复用的业务组件， 使得业务可以通过配置化来复用优秀的中台能力；中台还提供了完备的文档建设、视频教程， 支持业务快速上手、快速迭代， 同时还提供了面向全流程开发效能提升的完整自动化工具链。系统架构图如下：

（图片来自网络，版权归原作者）

（图片来自网络，版权归原作者）

现在，百度不但深耕了搜索，更加加速移动化，也扩展了更多的流量入口，包括小程序、百度云，贴吧，独立站等，随着产品思路的调整，产品形态日趋复杂，如果这些业务都能发展壮大，百度的大中台战略会推进等更好，但是目前百度的重心还是加速移动化，抢占移动搜索入口很重要，至于大中台可能不是其当务之急，小部门内小中台已经足够使用。

05

腾讯中台

腾讯：中台战略，All in产业互联网

腾讯和百度有些类似，是以即时通讯为核心的应用，这个本身就是一个大中台，不像阿里都是以业务模块为核心的购物，金融应用，自然阿里对于大中台的需求会更强烈。但是，腾讯又在发力腾讯云，所以从业务上讲又比百度更加重视大中台，所以形成了目前BAT目前这几种中台格局。大中台是阿里的核心业务，百度搜索是核心业务，腾讯即时通讯和社交是核心业务，所以各自对大中台的诉求程度不一致。

「在产业互联网大厦里，腾讯提供从毛胚房到精装房的各种行业解决方案，让企业不管规模大小、不管需求多少都能拎包入住。」近期在2019腾讯全球数字生态大会上，腾讯公司高级执行副总裁、云与智慧产业事业群（CSIG）总裁汤道生这样形容腾讯的服务能力。

在人口红利临近发展瓶颈的时候，大公司们都开始思考新的增长点。对于年届20岁的腾讯来说，新的增长点总办的老板们看来已经想得很明确了——产业互联网。从To C到To B，将是腾讯未来最大的关键词——而在汤道生眼中，腾讯的「中台」，则无疑是支撑腾讯掌握产业互联网大局的中流砥柱。

自去年CSIG成立以来，腾讯通过成立技术委员会来加强技术共享和协同，并设立「开源协同」和「自研上云」项目组来推动公司技术的整合、公司产品的开源与云端化。

在去年5月21日的大会上，汤道生介绍了自去年CSIG成立以来，腾讯通过成立技术委员会来加强技术共享和协同，并设立「开源协同」和「自研上云」项目组来推动公司技术的整合、公司产品的开源与云端化。

整合带来的最大好处就是技术的标准化，而这一切显然是为其中台战略做铺垫——标准化意味着腾讯可以更高效地把自己的能力交付给客户。

大会中，汤道生公布腾讯开放的中台能力包括数据中台和技术中台。其中，数据中台包括用户中台、内容中台、应用中台等；技术中台包括通信中台、AI中台、安全中台等。企业与开发者可以灵活地把这些技术应用到业务场景中。

而在技术中台方面，虽然腾讯过往并没有明确解释其具体的落实方案，但从名字上我们也可以看出一些端倪——通信中台基于的是腾讯从QQ和微信两端积累下来的即时通信技术；AI中台则基于腾讯三大AI实验室的技术，涵盖了光学文本识别、人脸识别、图片识别、音频识别、文本分析等方面的技术；而安全中台则是腾讯基于其安全运营经验和安全数据库为方便企业进行高效安全管理而打造出来的一站式大数据和智能化安全管理平台。

用户中台，指的是一整套囊括了用户增长、用户沟通、用户数据保护、会员管理等方面的客户管理工具。

内容中台则是腾讯以企鹅号为中心，为合作伙伴和内容创作者提供高效的内容生产工具。

应用中台，是腾讯旗下的应用宝以「分发中台」作为核心功能全面向合作伙伴开放，打造全新的应用分发生态，提高应用分发效率。

技术中台，虽然腾讯过往并没有明确解释其具体的落实方案，但从名字上我们也可以看出一些端倪——通信中台基于的是腾讯从QQ和微信两端积累下来的即时通信技术。

AI中台，基于腾讯三大AI实验室的技术，涵盖了光学文本识别、人脸识别、图片识别、音频识别、文本分析等方面的技术。

安全中台，则是腾讯基于其安全运营经验和安全数据库为方便企业进行高效安全管理而打造出来的一站式大数据和智能化安全管理平台。

05

其他大厂中台

阿里全体系中台架构分享

滴滴业务中台构建实践

【中台实践】滴滴大数据研发中台的最佳实践.pdf（附下载链接）

小米中台架构分享，小米市值2690亿是因为这群可爱的人

农业银行：银行业中台系统的建设思路

【PPT】阿里巴巴数据中台实践分享

我花 10 个小时，写出了小白也能看懂的阿里数据中台分析！

京东物流AI智能大脑中台系统架构

【干货分享】企业数据中台整体介绍及建设方案(文末附52页pdf下载链接)

阿里专家讲中台：技术中台-分布式架构在蚂蚁金服的实践

看完以上中台，看上去丰富多彩，或者有些杂了，其实都是一个问题：复用，他们的只是根据他们的业务总结出来的，所以自己公司要什么样的中台是不可以照搬的，是需要学以致用的

结论思考

看完以上内容，特别是BAT的中台建设，是不是可以窥见一斑，连百度腾讯都没有完全模拟阿里的中台，其他公司的照搬结果可想而知了，至于茅台是不是照搬阿里的是没有详细报道的，但是显然受了阿里大中台的一些影响，人家家大业大，都是应用业务系统，自然需要大中台；而国酒茅台，一般情况下是不是业务系统内业务代码和底层技术代码复用就可以了？也许并不是茅台CIO的主意，也不能因为市场上什么火就学什么，就像深圳有一家公司觉得GO很火，把原本完善的业务系统全部换成GO一样，毛泽东不是说：一切是从实际出发嘛；我们不能否认中台的优点，前提是你的业务有足够的财力来保障其正常有序正确的搭建和实施，用什么样的架构，用什么样的中台，中台做到什么程度，不是中台的问题，不一定是你需要中台，而是你更需要一个合格的架构师。

参考资料：

[1]程序员小灰：什么是中台

[2]部分图片和内容来源于网络收集，版权归原作者所有

厉害了！阿里P8架构师用4大技术文档带你深入解读爆火的中台战略

前言

根据百度指数搜索“中台”，可以发现中台这个概念从2019年5月21日起突然火了起来，并持续火爆。如果对2019.5-2020.7进行一次关键词盘点的话，中台绝对要算一个。

从概念的认知，到实战经验的分享，再到中台战略引起的思考，一些优质图书陆续出版，系统性、多角度地对中台进行解读。

整理起来总共分为四大中台技术文档：企业IT架构转型之道、架构真经、架构即未来、微服务架构设计模式，因为内容实在是太多了，所以小编只把部分知识点整理出来给大家介绍一下，每个小节都有更加细化的内容。

一、企业IT架构转型之道

主要内容

本文从阿里巴巴启动中台战略说起，详细阐述了共享服务理念给企业业务发展带来的业务价值。接着会分享阿里巴巴在建设共享服务体系时如何进行技术框架的选择，哪些重要的技术平台支撑起了共享服务体系，这也是迄今为止对阿里巴巴集团中间件体系对外最全面系统的介绍。除了技术层面之外，本文还分享了阿里巴巴内部的一些经验和实践，如组织的架构和体制如何更好地支持共享服务体系的持续发展。

最后结合两个典型案例来介绍如何在实际工作中应用共享服务体系。一个案例是国内某大型国企进行互联网转型的尝试和探索，最终走上成功转型之道的过程;

另一个案例是国内某零售企业如何基于阿里巴巴提供的企业级互联网架构重构企业IT架构，在短期内快速重构供应链、SCRM等平台，打造了企业全渠道分销平台，为该企业在竞争最为激烈的零售行业构建了差异化的竞争优势。希望通过这两个案例使读者更真切地看到共享服务体系项目落地的过程，以及它在企业互联网业务和IT架构转型过程中所起到的重要作用。

目录

二、架构真经

主要内容

本文旨在帮助工程师、架构师和管理者研发及维护可扩展的互联网产品。给出了一系列规则，每个规则围绕着不同的主题展开讨论。

大部分的规则聚焦在技术上,少数规则涉及一些关键的思维或流程问题，每个规则对构建可扩展的产品都是至关重要的。这些规则在深度和焦点上都有所不同。有些规则是高级的，例如定义一个可以应用于几乎任何可扩展性问题的模型;其他的则比较具体，可能用来解释-种技术，例如怎么修改HTTP头来最大化内容缓存。在本文中，我们增加了成功的互联网产品公司中首席技术官和企业家的故事，这里涉及的公司既包括初创企业也有财富500强公司。这些故事有助于说明规则是如何形成的，以及它们为什么在海量事务处理环境中显得如此重要。没有什么其他故事可以比亚马逊更能说明在互联网上急速扩展所遇到的需求和挑战。

目录

三、架构即未来

主要内容

本文分成五部分。

第一部分重点介绍组织、管理和领导。提拔经理和领导通常是根据其在专业领域里的才能来决定的。例如，提拔工程方面的领导和经理的决策，常常根据他们的专业能力，而并没有给予足够的时间和资源培养他们在业务、管理和领导方面的才能。虽然他们可能在架构和技术扩展性方面表现得还不错，但是在组织扩展方面的专业能力常常是浅层次的甚至是不存在的。我们希望本书能为这些经理和领导奠定基础,促进他们成长和成功。

第二部分重点讲述那些有助于处于高速成长阶段的公司扩展其技术平台的过程。讨论的话题从技术问题的解决方案到危机管理,也包括指导架构决策和确保平台可扩展的原则。

第三部分重点讨论技术和架构的可扩展性方面。本文介绍了专门从事顾问与咨询业务的AKF公司研发的具有知识产权的模型。这些模型旨在帮助机构通盘考虑可扩展性需求和其他的选择方案。

第四部分讨论云计算等新技术，也涉及一些高速成长的公司所特有的问题，诸如海量数据的增长、数据的成本、规划数据中心时需要考虑的问题、优化监控策略贴近客户体验等。

第五部分详细解释如何计算最常见的--些技术指标，包括系统可用性、容量、负载和性能的计算方法。

本文中的经验和教训既不曾在实验室中设计和验证，也不基于理论。相反，工程师、技术主管和组织为了确保实现理想、事业发展和系统的正常运转，经过多年艰苦卓绝的努力，通过设计和实施，把这些经验教训付诸实践。作者有幸以多种角色成为这些团队的一个部分，有的时候作为参与者，其他时候作为旁观察。我们已经看到阅读本文并学以致用所带来的成功，也看到了不愿意或无法应用这些经验所导致的失败。

本文旨在传授经验教训，并把你和你的团队带到成功的道路上。我们坚信本文所传授的知识和经验对于各个层面的工程和产品人员，不论是独立贡献者还是CEO,都很有价值。

目录

四、微服务架构设计模式

主要内容

本文的目标是让架构师和程序员学会使用微服务架构成功开发应用程序。

文中不仅讨论了微服务架构的好处，还描述了它们的弊端。读者将掌握如何在使用单体架构和使用微服务架构之间做出正确的权衡。

本文的重点是架构和开发，适合负责开发和交付软件的任何人(例如开发人员、架构师、CTO或工程副总裁)阅读。

本文侧重于解释微服务架构的设计模式和其他概念。无论读者使用何种技术栈，我的目标都是让你们可以轻松读懂这本文。你只需要熟悉企业应用程序架构和设计的基础知识即可。特别是，需要了解三层架构、Web应用程序设计、关系型数据库、使用消息和基于REST的进程间通信，以及应用程序安全性的基础知识等概念。本文的代码示例使用Java和Spring框架。为了充分利用它们，读者应该对Spring框架有所了解。

本文内容由13章组成。

第1章描述了所谓“单体地狱”的症状，当单体应用程序超出其架构时会出现这种问题，这可以通过采用微服务架构来规避。这一章还概述了微服务架构模式语言，这也是本文大部分内容的主题。

第2章解释了为什么软件架构很重要，描述了可用于将应用程序分解为服务集合的模式，并解释了如何克服在此过程中遇到的各种障碍。

第3章介绍了微服务架构中强大的进程间通信的几种模式，解释了为什么异步和基于消息的通信通常是最佳选择。

第4章介绍如何使用Saga模式维护服务间的数据-致性。 Saga 是通过传递异步消息的方式进行协调的一系列本地事务。

第5章介绍如何使用领域驱动设计( DDD)的聚合和领域事件等模式为服务设计业务逻辑。

第6章以第5章为基础，解释了如何使用事件溯源模式开发业务逻辑，事件溯源模式是一种以事件为中心的设计思路，用来构建业务逻辑和持久化领域对象。

第7章介绍如何使用API组合模式或命令查询职责隔离(CQRS)模式，这两个模式用来实现查询分散在多个服务中的数据。

第8章介绍了处理来自各种外部客户端请求的外部API模式，例如移动应用程序、基于浏览器的JavaScript应用程序和第三方应用程序。

第9章是关于微服务自动化测试技术的两章中的第-章，介绍了重要的测试概念，例如测试金字塔，描述了测试套件中每种测试类型的相对比例，还展示了如何编写构成测试金字塔基础的单元测试。

第10章以第9章为基础，描述了如何在测试金字塔中编写其他类型的测试，包括集成测试、消费者契约测试和组件测试等。

第11章介绍了开发生产就绪服务的各个方面，包括安全性、外部化配置模式和服务可观测性模式。服务可观测性模式包括日志聚合、应用指标和分布式追踪。

第12章介绍了可用于部署服务的各种部署模式，包括虚拟机、容器和Serverless 模式。还介绍了使用服务网格的好处，服务网格是在微服务架构中处理服务间通信的一个网络软件层。

第13章介绍了如何通过采用绞杀者( Strangler)模式逐步将单体架构重构为微服务架构，绞杀者模式是指以服务形式实现新功能，从单体中提取模块将其转换为服务。

在学习这些章节的过程中，读者将了解微服务架构的不同方面。

总目录

四大中台技术文档总结

企业IT架构转型之道

架构真经

架构即未来

微服务架构设计模式

这四大中台技术文档：企业IT架构转型之道、架构真经、架构即未来、微服务架构设计模式，已经整理打包好，需要完整版内容的朋友，可以转发此文关注小编，查看微信公众号【程序员高级码农】来获取！！

送给读者的话

我一直以来都信奉再好的技术和框架如果不给企业带来业务价值，就没有太大意义，所以本文更多是从技术架构解决了什么问题，企业收获了哪些业务价值的角度进行说明和阐述，并没有描述太多晦涩的理论、算法和模型。

“他山之石，可以攻玉”，希望更多的企业IT管理者、架构师、立志成为架构师的技术人员能从这四份文档中获取有价值的信息，进而对自身职业发展和所在企业业务发展有所帮助。

对于有一定技术背景，希望对互联网架构有一个整体了解的读者，这四份文档更是不错的选择，赶紧抓紧时间获取学习吧。