自去年CSIG成立以来，腾讯通过成立技术委员会来加强技术共享和协同，并设立「开源协同」和「自研上云」项目组来推动公司技术的整合、公司产品的开源与云端化。
腾讯的技术委员会，对标的是阿里巴巴的中台事业部，而不是外界所解读的对标阿里“达摩院”。整合带来的最大好处就是技术的标准化，而这一切显然是为其中台战略做铺垫——标准化意味着腾讯可以更高效地把自己的能力交付给客户。
20年来，腾讯在深耕互联网的发展历程中积累下丰富的经验和领先于业界的技术，而开源和上云意味着腾讯正将基于这些经验和技术所构建起来的中台能力开放给客户，助力各个领域的企业和开发者搭建数字化的业务平台，提升竞争力。
腾讯开放的中台能力包括数据中台和技术中台。其中，数据中台包括用户中台、内容中台、应用中台等；技术中台包括通信中台、AI中台、安全中台等。企业与开发者可以灵活地把这些技术应用到业务场景中。
可以说，腾讯是铆足了劲来打造其中台战略了。这当中的缘由有两点：
1. QuestMobile上个月发布的数据显示，2019年3月，中国移动互联网月活跃用户（MAU）规模达到11.38亿，同比增速首次跌破4%。互联网时代的流量红利正在逐渐消失已经成为一个行业共识，如何在存量经济时代维持可持续发展，腾讯给出的答案是重点发展To B业务。
腾讯在此时开放中台能力，目的就是为了在产业互联网发展前期争取到更多B端客户在自身平台上搭建各自的To C产品，这一举措显然对其未来能否掌控市场大局至关重要。我们甚至可以认为，未来流经这些基于腾讯中台而搭建起来的产品的流量，也是未来各大互联网巨头必须要争取的流量。
2. 中台战略命门在于数据。流量流经腾讯中台也意味着会有各种数据经由中台产生，在进行数据脱敏（去除涉及隐私的敏感信息）之后，腾讯可以将这些数据反过来用于提升自身的产品和技术水平，从用户群体行为分析，到算法优化，到AI训练，未来产业互联网的发展，没有一行不需要大数据。
腾讯开放中台功能，一方面是推动发展产业互联网战略的需要，另外一方面，也可以说是为了维持其领先的技术和内容优势地位的需要。
02 百度：建立可复用的中台能力
百度的中台，实际是从平台建设的基础上发展起来的。之前的产品形态相对确定，因此可以提供完善的平台化能力，来满足这些相对确定的需求；如果有新的需求，那么就直接在系统核心模块增加功能、扩展能力即可。
现在，百度不但深耕了更多的搜索结果，满足用户更完善的获取信息甚至服务的需求，也扩展了更多的流量入口，包括小程序、独立站等，随着产品思路的调整，产品形态日趋复杂，之前的平台化的思路就行不通了。
原有系统核心模块无法满足业务多样性的扩展需求， 一些扩展成本非常高、上线和维护的风险特别大，使得之前的系统优势转换为了制约当前业务发展的缺陷。而转为中台战略，使得团队同时高效高质量的支持更多业务，成为可能。
百度中台的技术思路：提供完备的通用能力、定制能力，持续完善领域技术沉淀能力。
业务视角， 中台提供了灵活的可定制业务框架， 使得业务可以聚焦业务特有逻辑的开发；中台还提供了可以复用的业务组件， 使得业务可以通过配置化来复用优秀的中台能力；中台还提供了完备的文档建设、视频教程， 支持业务快速上手、快速迭代， 同时还提供了面向全流程开发效能提升的完整自动化工具链。
系统架构图如下：
业务方最直接看到的是展现策略统一框架、在线排序统一框架、内容加工统一框架，以及可以通过框架配置化使用的丰富的业务组件；这些业务组件沉淀了大量的领域知识和经验，可以极大加速业务的创新和迭代。
在架构升级的背后，包含了个人和团队的能力矩阵的升级。团队之前从事的偏基础架构的工作，关注的是架构的可用性、性能、成本等核心指标。团队转型到业务驱动后，使得团队除了继续承担架构的核心职责外，还要持续为业务交付可持续增长的技术方案，这对团队提出了更要的要求。
中台架构的阶段成果：月级别孵化新的垂直搜索产品，完成线上小流量；用不超过一个季度的精雕细琢，完成产品的全流量上线。这个时间包含了业务从学习系统，进行开发，然后部署整套系统到生产环境，并完成线上效果验证的全流程；对于熟悉中台系统的同学，这个周期会更短。
为了追求效率的卓越，百度还专门成立了研发效率团队，聚焦全流程、全周期的效率提升， 包括建设了在线的 debug 系统、离线的 trace 系统，都是帮助业务能够自助和高效的追 case、查问题；百度还建设了统一集成开发环境，实现开发环境和仿真环境的自动打通，实现低成本的产品效果验证， 这种例子还有很多。最终为业务提供了卓越的研发效率。
中台架构，提供的不仅仅是简单的生产工具和开发方式的升级，而是逐渐完善的技术体系，为业务带来的是生产力的升级，为业务带来了质变的研发效能提升。
03 小米的三大中台建设：业务+数据+技术
1. 业务中台：从业务说起
在中台建设中，需要规范化的服务接口、一致整合化的数据、容器化的技术组件以及弹性的基础设施。并结合业务情况，判定是否真的需要中台。
小米参考了业界优秀的案例包括移动中台、数据中台、业务中台、技术中台等，再结合其业务发展历程及业务现状，整理了中台架构的核心方法论，一是企业如何共享服务，二是如何为业务提供便利。
通过中台架构方法论和规划方法论，小米信息部提出了小米业务中台建设三年战略，包含了持续优化、构建中以及待新建的系统，纵向分为企业战略、业务执行、业务支撑、数据治理四部分。
在2018年成立时，系统还是比较分散的；在2019年，主要围绕中台的架构调整、技术体系下沉，强化运营配置中心三方面，实现绝大多数的共享服务，让小米复杂的业态共享一套体系，更好的支持业务；在2020年，期望整体完善，不断的持续优化。
2. 数据中台：数字化转型的核心
今天大家都在谈数字化转型，数字化转型是转什么？从企业内部来讲，是想如何把一切都数字化，大企业讲数字化转型是很难的一件事情，但现在有些小企业已经做得非常好。系统很简单，但是可以把企业的百十家或者几百家店铺的每一个动作、每一次上下架，甚至是每次的价格变更，每个操作人员的动作，都放到系统里面做记录。
数字化转型，业务是基础，核心是数据。在数据分析及使用过程中，小米主要面临3大问题：
从数据整体来讲，一般分为数据采集、数据清洗，形成数据集市，最后数据分析员才可以在BI去做分析，并提出改进流程，提高业务发展。下图是小米数据中台的架构，底层是大数据平台的基础，在大数据的基础之上搭建了一系列的应用。
为了解决以上数据问题，小米信息部成立了X DATA团队专门做数据，更方便地让分析人员在系统上直接分析全部门的任何数据、做报表。只要在权限管控内，分析人员直接得到对应的数据并进行数据分析。小米想从业务端沉淀数据，在共享到X DATA大数据分析，然后发现问题在反馈到业务系统中解决问题。
在数据中台上还需要运用一些关键技术，包括：大数据离线计算、趋势预测、实时计算、自然语言处理、可视化分析、图像识别等。
数据中台对业务运营产生的价值，主要体现在生产监控、日常运营、经营管理、战略管控等方面。
通过对数据中台的建设，小米真正意义上开始走上数据驱动的路程。数据驱动小米的设备研发、生产、供应链、销售、服务以及IOT和互联网业务，产业+互联网格局逐步成熟。
数据驱动小米进步，体现在精细化运营、智慧物流探、产业互联网等方面。现在全球都在建仓，到底在什么地方建仓合适，怎么去建仓？这都是要数据分析才能得出。
未来，大数据是为人工智能准备的。
3. 技术中台：更敏捷的开发效率
前面讲的都是偏业务线、偏分析的，但核心最终还是要回归到IT的本质，更敏捷的开发效率才是IT最终的目标。在早期烟囱式的建设中，企业拥有众多的研发团队，但团队人员的基础不一样，工具不一样，面临：重复建设、质量无保证，横向打通困难、技术栈混乱，严重阻碍业务中台建设等问题。
业务&数据中台拥有强大炮火群，为前台业务快速响应直接提供支援，而技术中台是为中台服务提供高度模块化零件&武器库，大幅缩短业务中台建设时间，提高业务中台稳定性。
小米通过技术下沉，把最标准的东西沉淀出来，包括IaaS(容灾、机房、数据中心)、PaaS(中间件、研发平台、数据平台)、监控、开发过程的代码，全部陈列到底层，形成技术中台。
04 字节跳动：移动研发中台，效率提升7倍
卫哲，曾在公开分享中提到：今日头条的崛起很大程度在于今日头条是大互联网公司中第一个率先实现强中台的公司。今日头条强就强在前台放四五个员工，就能做出今天抖音这样的产品来，在传统的互联网公司做不到，没有几十、几百个人，是做不出来的。
移动研发中台。字节跳动的研发中台从业务纬度划分包括组件平台、CI/CD、应用管理平台，目前还在规划整合预审平台、发布平台。其中组件平台提供了通用的组件管理方案整合公司内所有的组件、CI/CD 平台使用了自研的分布式云编译专利方案，以头条为例可以提升接近 700% 的编译速度。
无线研发平台是一个具有标准化开发、接入维护流程和辅助工具，实现一键集成、持续反馈和迭代的中台服务，针对业务开发过程中遇到的构建速度慢、代码准入复杂、测试回归效率低等问题提供了一站式的解决方案。
其中从业务开发角度，中台提供了增量构建、二进制调试、容器化、自动解耦等功能，解决之前构建速度慢，调试周期长等问题；从 CI/CD 角度，使用自研的编译方案，测试出包效率在业务无感知和改动情况下，提升了数倍。
在大型业务中为了保证正常地发版，往往都是 QA 同学作为最后的验证。之前 QA 同事每到一次验收日经常要等到半夜才下班，究其原因主要是构建测试包速度太慢，在大型业务中构建一次测试包可能要花费几十分钟甚至小时级的，因此针对这一痛点，字节跳动自研了编译方案，在业务无任何改动情况下，将单次打包实践缩短到 3-5 分钟。
中台的出现是为了在解决技术架构与业务架构慢与贵的矛盾，进行业务‘配速’而生，合理的中台技术必然是以解决当前的业务与技术矛盾为出发点的，因此在中台的实践中，不必一味的去效仿，需要根据当前的业务痛点以及技术架构进行实践，设计一套最符合自身需求的中台服务。
05 滴滴：构建最合适的业务中台
滴滴业务中台的架构实践。在谈具体对策与实践之前，先来看看整个业务中台的架构设计，如下图：
整个的架构设计分几个边界的上下文，好处在于把相关性不强的逻辑拆开，同时在一个相关性下面，通过分层对业务进行更好的建模。
调度层作为入口去牵引多个业务线，业务流程层为调度层做服务，状态智能层用来支持上面的两层。
在对业务和产品进行更好建模的基础上，进行了“五化”：服务化、异步化、配置化、插件化、数据化。
1. 服务化
服务化很常见，以下单为例，如下图：
下单流程能够调用很多服务，在多个层次，以接口层次结果进行拆解。
2. 异步化
对每个事件的非核心或不需要实时反馈给客户端的逻辑进行拆解，核心的主流程会变简洁。对非核心的逻辑在事件上做订阅之后，进行二级处理。
以结束订单为例，如下图：
结束订单的时候有很多逻辑要做，但是都是通过 MySQLBinlog 处理或 MQ 处理。
3. 配置化
服务化和异步化能解决很多迭代效率的问题，但由于系统、业务的复杂性，各个业务都有些差异，体现在不同的产品线、城市、区域、时间等等。
配置化的核心是对这些进行建模，把每个对象模型化，抽象成 ID，在不同的服务化里把这些可配置的能力进行抽象。
具体抽象过程，如下图：
第一级抽象采用的是类 iptables 的规则引擎判定产品分类，第二级的规则引擎由模块自定义。
所有配置化都是用的自生成平台，要配置什么，自定义配置即可，这个过程是动态进行的。
当前业务中台已经可以支持上千个配置点，比如不同层次的计价规则不一样、不同产品线的车样子不同、不同的场景，如拼车和接送机，管控规则也不一样等等。
4. 插件化
配置化解决的是业务线差异问题，但如遇到逻辑差异较大的情况，就要做插件，统称为 FPI
在 FPI 的能力上，不同的团队可以开发很多插件，在特定的配置点下，对它的逻辑进行加载。
真正业务流程到这儿，可以调起它对应的插件做出来。对于一些没有差异化需求的业务，可以用开发的 default 逻辑，这是更极端的灵活性的体现。
有灵活性的体现后，团队还可以做一些组织上的调整，原来每个服务或者平台是一个垂直化的架构，有些团队是横向，是 FT，有些 FT 是接送机 FT，专门做接送机的事情。
通过插件的形式在每个系统加载它的插件，它就可以跟着业务思考、跟着产品思考这个业务该怎么走、这个产品怎么演化。
相对的逻辑是更加专注的，这也带来很好的组织结构对中台的适应性。
5. 数据化
在大数据时代，数据是不得不考虑的问题，所以在业务中台，要实现全局打通，本质是要把数据打通。
所以我们制定了离线分析与在线决策的方案，如下图：
第一个是离线做分析，可以做数据血缘、模型训练，同时可以把它放到在线决策层面，构建很好的智能客户引擎和交易引擎，这个可以干预，因为干预可以让升舱或者多业务线的清单成为可能。
业务中台从无到有，到被应用的实践过程中，积累了很多实战经验。主要分享以下几点：
06 京东：打造共建、共享、标准化的数据中台
2018年底京东零售数据中台成立，目的就是对京东零售内部的数据体系进行全面梳理，建立以数据驱动业务增长的新引擎。
1. 数据中台：破除企业数据孤岛
在企业业务发展过程中所累积的大量数据，往往分散在各个业务单元和组织内部，形成一个个"数据孤岛""数据烟囱"。而数据中台是着眼于企业数据资产汇集、数据算法迭代、数据能力输出的根基平台，以数据指引业务决策并驱动业务增长，是破除数据孤岛的关键策略。
京东数据中台负责人黎科峰介绍，目前京东集团已形成零售、数科、物流、保险、健康等多元化的业务格局，各业务都进入到精细化运营阶段，对于数据精细化运营提出了更高的需求。
京东过往十多年业务发展沉淀下来的海量数据，需要通过数据中台的建设形成宝贵的数据资产，以打造强有力的数据智能能力。这也是京东自去年就开始推动数据中台建设的重要原因。
黎科峰认为，数据中台的核心包括数据基础层、数据服务层、数据应用层。除了技术之外，数据中台建设更重要的是一种协作意识和组织能力。因此京东在建设数据中台的过程中提出了共建、共享、标准化三个关键理念。
京东数据中台的共建理念，就是要联合各个业务单元，共同打造沉淀一套大数据中台。共享则是要避免数据孤岛，打破组织界限，实现数据的共通、能力共享。而标准则是指统一的数据标准，从底层的数据治理标准、数据口径标准，到统一的数据标签体系和数据模型服务，确保数据在集团内部流转和应用是基于同样的标准和基础。
2. 京东数据中台：千尺之台，起于垒土
数据中台的建设并非朝夕之功。黎科峰介绍，京东数据中台成立之后，经过半年多的建设，基本完成了打基础的阶段。
首先在数据底层的建设方面，京东建立了统一的采存算大数据平台，有节奏地合并数据集市，形成统一的大集市。数据治理环节，通过EC纠删码技术、数据分级分类、僵尸数据清理和冷数据治理等手段，数据有效性大大提高，数据逐步实现资产化，也大大节约了数据存储和计算资源。
在数据服务层，京东正在搭建一套公共的数据标签体系，汇聚前台业务部门、运营部门以及广告、搜索等各个垂直场景的标签数据，不断迭代，为各个数据应用场景赋能。同时，数据中台向各数据应用层提供数据模型能力，通过商品数据治理形成更准确的商品画像。
最后在数据应用层，京东数据中台推动前台统一了数十个数据产品，建立了统一的数据口径和数据看板。前台部门统一通过黄金眼和商智来提供对采销和商家的数据报表服务，底层通过数据中台使用同一套数据。
黎科峰认为，数据治理是数据中台建设不可或缺的一部分。数据治理要解决数据全不全、准不准、好不好用这三方面的问题，一定要让业务团队清晰地知道，公司的数据能力和数据资产应该达到怎样的标准。
同时黎科峰指出，建设数据中台并不意味着中心化，而应该利用API等形式提供各相关方使用，而区块链等技术手段在实现数据资产化的过程中也将发挥重要作用。
经过多年的积累，京东的亿万消费者和商家在平台上沉淀了海量的数据，数据的深入挖掘对于提升用户体验和商家营销能力都至关重要。京东数据中台着眼于数据驱动业务精细化运营的能力建设，持续夯实数据基础，形成数据与业务正向自循环促进的关系，不仅全面推动京东内部蓬勃的业务创新，也可以更好地对外服务，带动整个产业的数字化转型。
07 网易：胖中台、标准中台、平台组织
1. 网易的数据中台架构
网易汪源的绍，网易的中台建设主要经历了以下几个阶段：
2. 网易的“胖中台组织”“标准中台组织”和“平台组织”
虽然中台概念上只应该包含共享的能力，但对于像网易这样业务间相对独立的公司，很容易遭遇“标准”的中台部门与前台业务结合不够深、合作不够顺畅的问题。
同时，外界也会有这样的质疑，本身网易的业务就很碎片化，那么网易的中台体系又是如何协同、怎样去支撑更加碎片化的业务发展的？基于网易杭研院的实践经验，汪源提出了一套完整的中台组织方法论。
根据参与人员的差异，汪源把不同类型的组织总结为“胖中台组织”“标准中台组织”和“平台组织”。
其中，标准中台组织由各个能力组和工具、规范/流程/方法论组成；当标准中台组织对业务的介入程度不足以支撑中台的实现，就需要更加接近业务的定向组来参与，这就形成了胖中台组织；而能力臻于成熟，工具、流程都实现标准化，标准中台组织也可以退化成平台组织。
换言之，三个角色并非一成不变，而是处在动态变化之中。对于中台的发展，汪源还总结了一个“数字技术核聚变”的模型。
他表示，数据中台汇聚和整合业务数据，产生洞察指导业务创新，在线业务中台支撑业务围绕领域交汇，不断引入新技术，创造新数据，为数据资产增值裂变提供动力支持，数据中台和在线业务中台共生共存，形成数字技术核聚变的巨大能量，推动产业跳跃式进化。
“连接是一个宏观的基础，有了连接，你就有了大量的数据，有了连接你就可以有了大量在线的业务”。
汪源强调，借助中台，基于数据，可以去做分析和洞察，分析和洞察可以催生新的业务，在线业务可以不断迭代和进化，这样就形成一个正向的循环，最终为企业创造巨大的价值。而与理论基础相对应，在组织架构上，网易采取阶段性的把相关前台的部分团队也整合到专业能力部门的做法。
如此一来，在中台部门就有了一个个定向支持对应前台业务的定向组。这就形成了汪源所称的“胖中台组织”。
在汪源看来，这是在阶段性的让中台组织长的过胖一些，让中台和前台的边界在一个组织内磨合，“过两年在看哪些是属于中台的骨骼，哪些是属于前台的肉，搞清楚了再把肉重新分到前台去”。这样，胖中台组织瘦下来，又变成一个标准的中台组织。
实际上，网易的很多业务部门特别是用户中心、数据挖掘、商业智能、移动研发、内容安全等多个部门都具备一些中台的属性。考虑到网易业务多元化的现实，网易杭州研究院则选择和各个业务合作以更好的支持各业务建他们的中台。
比如网易的推荐搜索中台，就是从博客业务的个性化推荐、标签推荐中萌芽，支撑了云音乐的推荐引擎，并帮助网易新闻实现从编辑主导进入算法个性化的时代。
同时，网易的推荐搜索中台也负责考拉、云课堂等所有互联网业务的个性化推荐。
网易在数据中台的应用，第一个是在考拉里面，我们最近刚刚完成的数据中台的建设，达到的效果是实现指标的100%的覆盖，数据质量保障99.8%，100%的数据能够自助取数，同时还降低了20%的数据成本。
据汪源介绍，类似这样的中台，网易还有QA（质量保障）中台、移动研发中台、用户中台、用户体验设计中台等超过10个不同的中台。
08 本文内容小结
京公网安备 11010802035086号