如何建设中台？中台建设的组织、支撑技术和方法论

编者按：本文转载自网易副总裁，网易杭州研究院执行院长汪源的我的公众号“冷技术热思考”（欢迎搜索关注）。上一篇中台系列的文章重点阐述了中台的概念，本文是系列文章的第二篇，目的是说明什么状况下能够考虑建设中台，若是要建怎么建的问题，能够做为企业思考中台建设的大框架。如下为原文（有少许改动）：

本文将例举典型的须要建设中台的场景，供参考判断要不要建中台。建设中台须要考虑组织、技术支撑和方法论，每每还须要咨询服务的帮助，本文也能够做为思考中台建设的大框架。

要不要建设中台？

要建设中台，首先要考虑要不要建设中台。话说的这么绕是由于如今有不少不明就理就想建中台的。这个问题先作个初略的判断。

01业务中台的典型场景

对业务中台来讲，比较符合的场景主要有：
· 业务系统研发团队至少大几十人（含外包的），需求多变化快，系统又涉及多个领域（好比作ERP、电商的），业务逻辑比较复杂。这时业务中台能够把系统和业务领域划分清楚，提升研发效率。
· 作类似行业的外包项目为主，业务规模也作的比较大的（一年有两位数的项目）。这时业务中台能够提高软件复用，下降定制化成本，提升研发效率。若是你作外包，每一个项目都彻底不同，那中台也救不了你。

此外还有如下场景可能不须要建设完整的中台，但适合落地与中台相关的微服务技术的：
· 大规模互联网式在线系统，对稳定性和弹性要求高当前搞不定的。微服务或业务中台能够比较好的解决这些问题。
· 掉到IT竖井的坑里想爬出来的，经过项目外包作的系统没法管理和维护的。微服务或业务中台能够对系统的API、文档等进行有效管理，也能实现系统间的打通。

02数据中台的典型场景

对数据中台来讲，比较符合的场景主要是数据产品比较多，天天要看数据若是没数据就不知道怎么工做的运营人员比较多的业务。好比电商就是典型。若是这些数据产品和运营人员还在多个团队，那基本上数据中台没跑了。若是常常出现指标不一致、数据出错、想要的数据不知道哪里有等问题，那基本上数据中台也没跑了。

并非数据量大就须要建中台，主要仍是看用数据的姿式是否是比较复杂，当前问题是否是比较多。对于这类符合的业务，数据中台能把层层数据直到最上层的指标梳理清楚，提高数据质量，从而提高运营效率。把数据理清楚了，每每还能下降数据存储和数据开发人员的成本。

除了上述判断，还有一条是同行对比。若是一个行业你们都有点跃跃欲试想弄中台，那领先者必定要想办法抢先（既然是领先者了，每每也符合上述标准），否则就可能被颠覆。跟随者要不要想办法抢先从而超越领先者呢？可能很差说吧，但若是领先者已经建了，跟随者通常得紧跟，不然真可能被甩开了。

若是根据上述逻辑以为大体要考虑去搞一把中台的话，那请继续读本文如下内容，读完本文后续内容而后更具体的看看问题存不存在，条件是否具有。要建设中台，须要考虑组织、支撑技术、方法论这三个方面，每每还须要咨询服务。

中台组织

中台做为一种有业务属性的共性能力，首先就须要一个懂业务、承担业务职责的专职的组织机构来负责。要不要建中台，首先要看领导有没有魄力去整合创建一个中台组织。由于原来的平台部一般不懂业务，懂业务的人各自分散在前台业务部门，因此创建中台组织每每涉及人员、组织架构和部门职责的调整。 正由于如此，中台的建设每每须要做为一把手工程才能成功。

中台组织关键要懂业务和承担业务职责。举个例子，一个大数据平台的建设运维团队不是一个中台组织。一个团队若是作了很是完善的中台产品（如开发了数据中台所须要的指标管理系统、数据仓库开发系统、数据质量管理系统等等），但只是把产品提供给业务方使用，这个团队仍然不能说是中台组织。只有当这个团队承担起指标体系的建设和管理、数据仓库的设计和实施、数据质量的保障等工做时，才能够说是中台组织。而要作到这一点，这个组织确定是比较了解业务的，它的目标和考核也必定与业务有相关性（确定不仅是平台稳定性这样的非业务指标）。

中台组织的层次与中台的层次最好是对应的，BU级的中台组织最好直接向BU老大或分管的CXO汇报，企业的中台组织最好直接向CEO或分管的CXO汇报。

这里特别说明一点的是若是不建设在线业务中台，而只是采用微服务、云原生等技术的话，能够不涉及组织方面的大规模变更，就在原来的研发部实现转型。一般来讲也能够实现必定的系统可用率、弹性和研发效率方面的提高。

中台建设的支撑技术

建设中台通常须要一套支撑技术。

01在线业务中台支撑技术

建设在线业务中台通常须要云原生、DevOps、微服务技术体系的支撑，这是由于：
· 微服务技术：中台是一个独立的组织负责并为多个前台业务服务，所以须要一个标准的服务接口、成熟的服务治理能力和高效的敏捷研发技术。在当前的技术环境下，采用地球人都熟悉的REST风格的同步API、消息队列异步通讯做为标准的服务接口技术，采用服务框架（如Spring Cloud等）、API网关、APM等做为标准的服务治理和敏捷研发技术是最合适的选择。再也不建议采用传统的基于ESB的服务化（SOA）技术，由于ESB产品过多的介入到业务逻辑中，致使前台业务的变动每每须要中台团队的配合才能完成，这样就失去了建设好中台，支撑前台高效创新的意义。此外，中心化的ESB软件和复杂的基于XML的WS-xxx等协议也影响到系统的可用性和性能。能够参见Martin Fowler在P of EAA中的评价，Web Services是应用集成而非应用开发的技术。
· DevOps技术：若是不经过DevOps使得各微服务都能自助式的部署更新，则微服务带来的敏捷性就无从发挥，反而由于服务数量的增长致使研发效率的降低，所以持续集成、持续发布等DevOps技术通常是实现微服务的必备。
· 云原生技术：微服务和DevOps要求底层的基础设施是灵活可编程的，不然根据Amdahl定律，只要有一个必须的环节是低效的，总体的效能也提不上去。
须要强调的是中台要敏捷，这一方面是由于中台具有业务属性，且支撑了很是丰富的前台业务，前台业务的敏捷性要求有一部分就会传导的中台层；另外一方面是中台的重要性使得其须要持续不断的优化，即使对外提供的服务不变，内部实现也会常常变。
· 分布式事务技术：实施微服务拆分后，复杂的业务流程再也不能经过数据库的事务机制来实现ACID特性，为此还须要服务层面的分布式事务处理技术。典型的分布式事务处理模型包括TCC、Saga、FMT等。其中TCC和Saga须要各服务实现定制化回滚逻辑，侵入性比较严重，用起来门槛比较高。FMT模式对于Java能够作到加一行注解（如@GlobalTransaction）便可实现分布式事务，剩下的由框架自动处理，用起来方便的多。Saga模式是Princeton的两位研究者在1987年提出的，灵活性和并发度最好，但须要经过语义锁等精细的设计才能发挥出来。

因而可知，在线业务中台的技术支撑体系是至关复杂的，所幸的是Netflix、Google等世界领先的互联网企业因为自身业务须要打造了不少实用的技术模块，开源社区也贡献了很多力量，CNCF组织又作了很好的聚集和标准化。 经过将相关技术加以整合，已经有了不错的产品可用，如网易轻舟微服务就是一套产品化设计良好、功能丰富的在线业务中台支撑技术产品。

通常而言，前台也会和在线业务中台同样采用云原生等一样的技术体系，这是由于前台更须要敏捷性。在完善的中台支撑之下，前台会比较轻，还能够考虑采用FaaS Serverless技术，不过目前这方面的实践还很少（特别在中国），相关的支撑技术也不是很成熟。

02数据中台支撑技术

建设数据中台通常须要一整套以下典型的支撑技术：
· 指标管理系统：指标是中台与前台之间最关键的接口，也是建设数据中台的牛鼻子，由于它是最核心的业务语言，且指标不一致、数据常出错是建设数据中台最多见的出发点。若是指标体系没有统一的方法论，进行统一建设，那么就很难说是数据中台。指标管理系统通常要实现一套一致的方法论（如原子 / 派生 / 复合指标、维度、修饰词等），作好指标的业务和技术口径管理，还须要支持指标的审批管理。数据中台的指标没法交给各前台业务自助式的建设。
· 数据服务系统：相似于在线业务中台须要经过API网关提供标准化的服务，数据中台也须要一个标准化的服务方式，一般称为数据服务系统，也能够说是数据网关或数据门户。相似于别的网关类产品，数据服务系统须要提供鉴权、日志审计、流控、协议转换（如SQL Dialect之间的转换）等功能，也应该发展多引擎融合查询、逻辑模型等扩展功能以提升服务接口的稳定性和实现的灵活性。
· 元数据管理系统：元数据管理是整个数据中台的基础和中心，全部的其余系统都依赖元数据管理。元数据管理首先要作好的固然是数据模式或目录（catalog）的管理，至少要知道中台里都有什么数据。对复杂的数据中台来讲，数据血缘也很重要。没有血缘信息，不知道数据间的依赖关系，数据质量确定管很差，由于不知道一个数据的质量问题怎么来，又进而会影响什么。一样的若是没有血缘，数据资产也确定管很差，由于不知道什么数据有价值什么没价值，这就像若是你不知道一个函数被谁调用，你就不知道它是否是死代码同样。元数据管理系统每每也须要提供一个基础的访问界面，一般称之为数据地图。
· 数据仓库开发与管理系统：除了指标管理，数据仓库的开发是将一大堆初始数据建设梳理成一个漂亮的数据中台的核心过程。通常来说数据中台更适合用Kimball的维度建模方法而非数据仓库之父Bill Inmon所提倡的方法，这是由于Inmon强调顶层设计，而Kimball强调至下而上。若是要建设数据中台，确定是由于前台业务复杂多变，这时强调顶层设计会致使中台建设缓慢、僵化。由于中台虽然应该是由组织高层决策，但目的倒是为了支持前台业务，而不是为了控制。 支持而不是控制，这一点毫不能本末倒置。
· 数据质量管理系统：全部复杂的系统都须要专业的质量管理，在线业务系统有一系列的弹力设计和APM等监控运维工具，数据中台也须要专业的质量管理。数据质量管理系统一般设计为支持丰富的稽核 / 校验 / 比对规则，监控数据是否准确、实时、一致，还要作到及时的报警，分析影响面，提供快速修复的手段等。但这些手段只能发现和补救问题，不能预防问题，要预防问题，还要经过测试工具减小代码bug、经过资源弹性应对性能波动、经过优先级调度优先知足重要业务需求等。相对来讲，当前数据中台领域的质量管理没有在线业务领域的成熟，如在线业务领域的测试手段远比数据领域的精细，在线业务领域很常见的熔断、限流、服务降级等模式在数据领域都没有成熟的实践方法（优先级调度能够说是实现了部分的服务降级功能），随着数据中台愈来愈普遍和重要，这些技术应该也须要持续发展，但技术上的挑战不小。
· 数据安全管理系统：数据中台由于聚集了组织全部有价值的数据资产，所以良好的安全管理是必须的。细粒度的权限和审计是基础，通常的还须要隐私 / 敏感数据的脱敏处理、数据加密（特别是将数据托管在第三方平台之上时）、数据泄漏防御（比方说一种常见的方法是限制将数据下载到本地的数据量）等技术。发展到高级阶段甚至可能还须要联邦学习、数据沙盒等技术。
· 数据资产管理系统：在数据质量和安全单列的状况下，数据资产管理主要负责的是数据的生命周期管理、成本的统计分析与优化等工做。

同时，数据中台还须要强大的大数据计算引擎、数据集成 / 同步 / 交换引擎，还每每须要一套敏捷BI系统：
· 大数据计算引擎：数据中台要管理的数据规模和复杂度每每都很高（不然搞中台属于为赋新词强说愁），因此传统的数据库和数据仓库基本上支撑不了。当前的技术环境下，基于Hadoop MapReduce或Spark几乎是惟二的选择，固然这也包括了这二者之上的Hive和Spark SQL。能用SQL就用SQL，易于维护，也易于数据血缘的收集。除此以外，流处理可能还须要Flink，交互式查询可能要引入Impala或GreenPlum。
· 数据集成 / 同步 / 交换引擎：一方面数据中台须要强大的数据集成和同步能力才能吸纳各方数据。集成和同步的概念相近，同步更强调实时性。另外一方面，数据中台每每由多种数据计算引擎构成，就须要同步或交换引擎实现不一样引擎见的数据交换。
· 敏捷BI系统：建设数据中台一般最重要的目的是为了支持业务运营和决策，为此须要基于数据中台进一步开发数据产品。敏捷BI系统是开发数据产品快速、轻型的手段，可以尽快尽早的发挥数据中台的价值。

此外，对于互联网业务，统一的埋点引擎每每也是数据中台所须要的。若是埋点的逻辑都不统一的话，建数据中台的时候会发现数据的源头就是乱的，后续也都无法作。其余行业业务，数据采集也属于基础工做，也是要先作好的。

因而可知，建设数据中台须要的技术支撑体系也是至关的庞大，复杂。所幸的是这十年来Google等领先的企业、Hadoop / Spark等开源社区以及大量的厂商大体联合探索出了一条可行的路径，方法论和技术路线都比较统一了。以此为基础，就能够提供较成熟的数据中台技术支撑产品，如网易杭研研发的“网易猛犸V6.0 + 网易有数”就是一套较完整的数据中台产品。

中台建设的方法论

复琐事务都须要方法论的指导（和约束），组织管理有虚虚实实的一大套各类理论，研发有敏捷方法或IPD流程，中台是复琐事务，因此也须要方法论。由于中台建设涉及组织和技术两个维度，因此中台的方法论也应该要覆盖这两个维度。目前而言，技术维度的方法论相对成熟，由于复用了不少原有的方法论。

01在线业务中台方法论

对于业务中台，微服务、网关、REST API及语义化版本控制、六边形架构是侧重于技术架构的方法论，DevOps、敏捷项目管理是侧重于流程层面的方法论，领域驱动设计（DDD）是侧重于业务架构的方法论。要作好业务中台，以上方法论大概都不可或缺。
你们能够看到，除了微服务跟中台大体是同步发展的以外，其余方法论都是早前就存在的东西。正由于有这么多合适的方法论存在，中台才变得可行，不管如何在短时间内要发展出这么多方法论是不现实的，由于方法论的威力不只在于它要好，还在于它要流行。

技术架构和流程方面的方法论已经很流行，无需多说（六边形架构放在和DDD一块儿介绍）。值得关注的是领域驱动设计这么一个10多年前就被提出，这么多年一直不温不火的方法论，忽然在中台领域彷佛找到了它的最佳安身之所。这样的现象是会昙花一现，仍是会长期持续，值得思考。

DDD的核心概念是通用语言和限界上下文。通用语言指的是在一个业务领域内通用（但不是在更大的领域内也彻底通用的）的概念、术语等语言，限界上下文指的是相邻通用语言之间“翻译”的边界，好比前台业务的用户可能要变成后台清算的客户。

我以为DDD的通用语言和一直以来的领域建模是比较类似的，更具创新意义的是限界上下文。在架构设计中，咱们要不要构造那种拥有很是多属性，但每一个使用者只使用少许属性，或者属性的名称和含义对使用者来讲不贴切的对象？若是没有限界上下文的约束，可能会认为这样毕竟实现了更多的复用，是好的，但用限界上下文的理念来看，这样极可能是很差的。每一个领域应该专一于本身领域的语言，领域之间要交互怎么办？加一种翻译机制，也就是限界上下文解决。

领域驱动和限界上下文的理念会天然延伸出六边形架构的设计。所谓六边形架构指的是一个程序的内部只须要处理业务逻辑，他的数据 / 请求从哪里来，数据要存储到哪里去（或者领域事件要发布），都经过各类适配器完成。由于这样的适配器可能较多，就再也不像传统的三层（三明治）架构。不过若是六边形只有一个Input和一个Output适配器的话，和三层架构就仍是差很少的。我想从三层架构进化到六边形架构的主要缘由仍是由于如今的环境已经从传统的C / S或B / S这样只有一个前端，也只有RDBMS这样的一个后端发展到前面有Web / 移动等多个端，向后也有RDBMS / NoSQL等多个端，横向也有服务化 / MQ等多个端的多端环境。我不知道哪天会不会发展出一个十面埋伏架构出来。

02数据中台方法论

数据中台的方法论也是博采众长，最核心的来自于数据仓库领域关于数据仓库规划实施和指标体系建设的方法。在数据仓库领域，有两套大相径庭的方法以前一直是较劲的，一个是数据仓库之父Bill Inmon所倡导的至上而下的方法，另外一个是另外一位大师级人物Kimball所倡导的至下而上的方法。在我理解，所谓Kimball的模式之因此说是至下而上，是由于基本上中台团队只负责从ODS到DWD到DWS就完了，往上就是所谓的ADS，其实已是面向各个业务（或者数据产品）了。你均可以说ADS层不属于数仓。这样的方法在中台做为一种新生事务无法有很强的话语权时显然是更容易作出的选择，可能将来中台概念深刻人心，集团高度重视，说不定Inmon方法又会从新流行？但也能够思考这种细节上都体现了领导的管理意志的中台仍是中台吗。指标设计的方法论基于Kimball方法中的粒度建模的方法，作了比较大的细化和改进。

划分主题域是建数据中台的常见实践，不过主题域划分与行业强相关，好比对零售业常见的有商品、交易、流量、用户、营销等域。

数据中台统一经过数据服务系统实现OneService的设计，不清楚有什么来源，不过相似于在业务架构中很常见的网关模式。数据质量、数据安全、元数据、生命周期管理也都是数据治理领域比较常见的概念，但一方面要实现针对大数据技术环境的落地，另外一方面更面向业务支持而非管控来设计。

实施数据中台一般还须要制定不少规范或标准，这也能够说是方法论的一方面。有不少规范是命名规范，其中数量最大的每每是数据仓库中的表，上万张表甚至更多都是很常见的，因此表的规范命名很是必要。一种好的表的命名规范，要反映其所在数仓分层、主题域、业务过程、时间周期等信息。计算任务也须要必定的命名规范。数据埋点也须要规范性的编码位置信息、内容信息和事件信息。

03组织维度的方法论及其余业

其余类型的中台也都有各自的方法论。如搜索中台，B公司有比较详细的对外分享的资料，其方法论主要体如今规范了搜索系统的关键流程，如内容引入和加工、离线训练、在线召回和排序等，还会涉及到查询改写、展现设计等要点。

以上说的都是中台技术维度的方法论，组织维度的方法论目前尚未看到好的系统性分析成果。在《企业IT架构转型之道》中只有不多的篇幅介绍中台组织维度的方法论，在另外一本讲数据中台的书中，干脆就只字没提组织方面的内容。业界关于中台组织的方法论，主要包括多职能小微团队、业务架构师主导、协做沟通机制、轮岗、共建、考核机制等。业界也有从通常性的组织管理维度（如垂直型组织、矩阵型组织等等）分析，过于宽泛，说了等于没说。

中台组织层面的方法论多是相对不成熟的，好比中台和前台、平台之间的边界和动向问题，彷佛没有明确的方法。我认为可能主流会符合“前台->中台->平台“单向流动的中心法则。可能中台组织的终极目标是发展为平台，由于仍是要追求把能力作成熟和标准，我这也多是很反动的说法。

做为集团的创新业务孵化中心，网易杭研每时每刻都针对不少业务线要并行发展，为此打造了一个又一个共享能力中心，想方设法提高创新效率。12年来感受摸索了一些关于中台的建设经验，固然可能更多的是教训，这段经历的体会后续我将会作个梳理，发出来供你们讨论。

中台建设的咨询服务

说到咨询，我首先想到的是技术进步的驱动力发生了很大的变化，从厂商和咨询公司驱动变成了领先客户驱动。以在线业务为例，传统的SOA和Web Services技术是传统厂商驱动的。这些厂商本身不用产品但要卖产品，因此一不当心就把产品搞的没必要要的复杂。另外这些厂商和咨询公司原本就是共生共荣的关系，因此也得把产品搞的复杂一点吧，否则咨询公司就没生意了。新生代的微服务技术主要是领先的互联网企业驱动的，本身造产品本身用，能简单一点就简单一点，最好是作成各个业务部门本身就能用。

因此新生代的中台技术是尽力将咨询的必要性尽可能下降的，可是由于当前实践中台的都是很大的互联网企业，业务复杂度不可避免的很高，对于大多数想要实践中台的非互联网企业来讲，仍然是须要咨询服务。

现状是，当前中台的咨询很是欠缺。由于这些中台都是互联网企业搞的，当前的厂商和咨询公司都没什么能力作这块的咨询。咱们能够看到一些咨询公司，不懂中台，把什么都往中台的概念上凑。当前也就互联网企业或有很强互联网企业背景的团队才有能力作咨询，但资源颇有限。但愿咨询公司们可以聚焦于真正的中台，透彻理解什么是中台，提高本身的咨询能力。

做者简介

网易副总裁，网易杭州研究院执行院长 汪源
2006年获浙江大学计算机专业博士学位，以后加入网易公司。现做为网易杭州研究院执行院长，全面负责网易集团公共技术支撑工做与云计算、大数据业务，主要包括云计算与服务端架构、前端技术、大数据挖掘分析、信息安全、多媒体、运维、质量保障等方向。

点击连接更多关于网易数据中台