软件开发架构师

如何建设中台?-InfoQ

大数据 189 2019-09-02 16:16

上一篇中台系列的文章重点阐述了中台的概念,本文是系列文章的第二篇,目的是说明什么情况下可以考虑建设中台,如果要建怎么建的问题,可以作为企业思考中台建设的大框架。以下为原文(有少量改动):

本文将例举典型的需要建设中台的场景,供参考判断要不要建中台。建设中台需要考虑组织、技术支撑和方法论,往往还需要咨询服务的帮助,本文也可以作为思考中台建设的大框架。

要不要建设中台?

要建设中台,首先要考虑要不要建设中台。话说的这么绕是因为现在有很多不明就理就想建中台的。这个问题先做个初略的判断。

业务中台的典型场景

对业务中台来说,比较符合的场景主要有:

  • 业务系统研发团队至少大几十人(含外包的),需求多变化快,系统又涉及多个领域(比如做 ERP、电商的),业务逻辑比较复杂。这时业务中台可以把系统和业务领域划分清楚,提高研发效率。
  • 做相似行业的外包项目为主,业务规模也做的比较大的(一年有两位数的项目)。这时业务中台可以提升软件复用,降低定制化成本,提高研发效率。如果你做外包,每个项目都完全不一样,那中台也救不了你。

此外还有以下场景可能不需要建设完整的中台,但适合落地与中台相关的微服务技术的:

  • 大规模互联网式在线系统,对稳定性和弹性要求高当前搞不定的。微服务或业务中台可以比较好的解决这些问题。
  • 掉到 IT 竖井的坑里想爬出来的,通过项目外包做的系统无法管理和维护的。微服务或业务中台可以对系统的 API、文档等进行有效管理,也能实现系统间的打通。

数据中台的典型场景

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

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

除了上述判断,还有一条是同行对比。如果一个行业大家都有点跃跃欲试想弄中台,那领先者一定要想办法抢先(既然是领先者了,往往也符合上述标准),不然就可能被颠覆。跟随者要不要想办法抢先从而超越领先者呢?可能不好说吧,但如果领先者已经建了,跟随者一般得紧跟,否则真可能被甩开了。

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

中台组织

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

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

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

这里特别说明一点的是如果不建设在线业务中台,而只是采用微服务、云原生等技术的话,可以不涉及组织方面的大规模变动,就在原来的研发部实现转型。通常来说也可以实现一定的系统可用率、弹性和研发效率方面的提升。

中台建设的支撑技术

建设中台一般需要一套支撑技术。

在线业务中台支撑技术

建设在线业务中台一般需要云原生、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 技术,不过目前这方面的实践还不多(特别在中国),相关的支撑技术也不是很成熟。

数据中台支撑技术

建设数据中台一般需要一整套如下典型的支撑技术:

  • 指标管理系统:指标是中台与前台之间最关键的接口,也是建设数据中台的牛鼻子,因为它是最核心的业务语言,且指标不一致、数据常出错是建设数据中台最常见的出发点。如果指标体系没有统一的方法论,进行统一建设,那么就很难说是数据中台。指标管理系统一般要实现一套一致的方法论(如原子 / 派生 / 复合指标、维度、修饰词等),做好指标的业务和技术口径管理,还需要支持指标的审批管理。数据中台的指标无法交给各前台业务自助式的建设。
  • 数据服务系统:类似于在线业务中台需要通过 API 网关提供标准化的服务,数据中台也需要一个标准化的服务方式,通常称为数据服务系统,也可以说是数据网关或数据门户。类似于别的网关类产品,数据服务系统需要提供鉴权、日志审计、流控、协议转换(如 SQL Dialect 之间的转换)等功能,也应该发展多引擎融合查询、逻辑模型等扩展功能以提高服务接口的稳定性和实现的灵活性。
  • 元数据管理系统:元数据管理是整个数据中台的基础和中心,所有的其他系统都依赖元数据管理。元数据管理首先要做好的当然是数据模式或目录(catalog)的管理,至少要知道中台里都有什么数据。对复杂的数据中台来说,数据血缘也很重要。没有血缘信息,不知道数据间的依赖关系,数据质量肯定管不好