首先我再整理下我原来提到过的一些关于企业中台的观点:
对于一个专业细分的业务领域而言,软件企业要做的就是将对业务领域的多年经验和理解沉淀到业务中台,形成可复用的各个业务中台能力中心,然后为上层灵活多变的各类应用提供服务能力。由于沉淀了业务理解形成通用化,可复用的业务模型,那么这个能力就不会轻易被模仿。
而今天当我重新再谈企业中台的时候,可以理解为:
业务平台 + 能力开放平台 构成了企业中台,即业务平台各微服务模块化后的业务中心首先提供可复用的业务能力 API 接口,然后这些接口能力再通过能力开放平台开放出去并统一管理。
今天我再谈这个概念,主要是想从如果一个企业邀请我们去将中台建设,那么从售前方案 PPT 的角度我们应该如何来准备材料来说明企业中台的建设思路和解决方案?
其一,中台思路的产生
首先还是要先讲清楚为什么会产生中台的概念,中台的提出和中台的产生背景。这些还是得介绍清楚。同时在介绍这些的时候还是要谈到 SOA,可以看到前台和后台分离,中台提供能力,前台可以基于中台能力快速的构建应用本质还是 SOA 的核心思想,即原来讲过的可重复服务识别,服务能力的组装和组合。
那么中台思路和原来的 SOA 的思路差别点在哪里?
从我原来对 SOA 架构思想的描述,到中台的核心构建可以看到,SOA 更多的是遗留系统本身的可复用接口服务识别,形成共享服务能力层,对遗留系统本身是一个简单的适配过程;而对于中台思想下可以看到完全是一次重新构建过程,这种重新构建的体现在。
传统模式更多的是垂直化的业务系统构建模式,而中台思路下不再有明确的单垂直化业务系统的概念,而本身就是为了打破原来垂直化竖井的边界,因此采用的是一种分层构建的新 IT 应用构建模式。
其二,从 SOA 到微服务,中台演进的必然之路
前面已经讲到了中台本身就是一个能力提供中心,而这个能力中心本身不再是简单的遗留系统暴露接口的适配和发布,而是微服务能力 + 能力开放 API 接口,这个是和传统 SOA 架构和业务系统集成下一个很大的区别点。正是这个原因我们讲从 SOA 到微服务,是中台演进的必然之路。
那么又得讲清楚什么是微服务?SOA 和微服务架构的区别点在哪里?在采用了微服务架构后真正带来了哪些复杂度,同时在采用微服务架构后又面对哪些挑战。
从 SOA 到微服务,管理的粒度更加细化,管理复杂度实际是增加了,为了更好的进行模块开发和持续集成,配套开始介绍下 DevOps 和容器化技术。
其三,构建核心中台层能力 (中台微服务模块 + API 接口服务)
要将企业中台的构建本身又需要分为好几个方面来讲。其中包括了业务中台的构建和数据中台的构建。而对于业务中台的构建本身又包括了由已有的遗留系统和 IT 资源来构建中台,还是全新构建中台。
构建中台核心要做哪些事情?可以看到重点就是要搞清楚重点就是识别中台应该包括哪些微服务模块,同时每个微服务模块究竟应提供哪些 API 能力接口?其次才是单独的一个中台模块如何进行开发建设,API 接口如何进行开发并能力开放。
中台的构建部分一定包括两个方面的内容,业务咨询和规划,技术实现两个层面。业务咨询规划解决的是中台模块如何划分,接口服务如何识别?而技术实现解决的是采用微服务开发框架如何开发,API 接口如何开发和接入等技术层面的问题。
其四,构建能力开放平台 (API 接入 + 能力运营 + 管控运维)
这块感觉可以单独拿出来讲,即传统业务系统集成我们更多讲的是 ESB 服务总线,共享服务平台。而在企业中台构建思想下,我们讲的是 API 服务网关和能力开放平台,即是一种轻量的 SOA 服务总线。
业务平台 + 能力开放平台 构成了企业中台
中台构建完成后必须要将能力以 API 接口服务的方式暴露出去给前台用,因此有必要单独介绍下能力开放平台,刚开始可以是简单的 API 网关,但是要实现更好的接口服务运营和管理运维,则需要进一步将 API 网关引擎升级为完整的能力开放平台。
中台和微服务的区别和联系
对于这两个概念,我们可以看到在企业 IT 架构转型过程中经常会出现的两个概念。很多时候我们也会把两个概念混用,即中台就是微服务,或者说微服务就是中台。但是实际上两者本身还是有区别。
也可以看到在谈中台的时候更多的是业务层面用词,而谈微服务的时候更多是技术层面用词。在谈中台的时候你首先考虑的是业务模块如何划分,服务如何识别,而实现技术是微服务。而谈微服务的时候本身就是技术实现和架构方法,是否一定用于中台倒不是必须。
因此要回答两者区别这个问题,我们首先还是要看下中台和微服务这两个概念是针对什么来说的。
这个搞清楚后,我们就更加容易理解两个概念的区别,即:
中台更多的是指横向拆分,即共性业务能力的下沉,然后再将服务能力开放给前台应用使用。而微服务更多是技术用词和软件架构开发方法,强调的是大单体要拆分和进一步解耦。
而我们现在构建企业中台,基本是中台和微服务都会使用到,即既需要进行横向拆分,共性能力下沉。同时对于下沉的共性能力又需要按微服务思想进一步拆分多个微服务模块。在中台思想里面更加强调了共性能力下沉和能力开放,能力开放以微服务里面常见的轻量 API 接口方式进行。
了解了这个我们看区别就比较清楚了,具体如下:
中台强调横向拆分和分层,微服务强调纵向拆分和解耦。
中台的构建不一定要采用微服务,也可以采用传统 IT 架构进行构建,只要满足共性业务能力下沉要求即可。类似我们传统架构里面的 MDM 主数据系统,按现在微服务思想应该拆分多个服务,但是即使没拆,我们仍然可以理解为是企业中台建设思路。中台里面还含了数据中台,数据中台构建本身就不能按微服务思路做。
对于中台构建可以用微服务,对于前台应用构建同样可以采用微服务。对于一些大的前台应用如果不能复用,那么也需要拆分为多个微服务进行解耦。
中台强调能力开放,微服务不强调共性能力开放,但是提供 API 网关工具进行能力开放。中台建设的目标更多的是下沉共性能力,识别和暴露可复用的 API 能力接口,供前台应用快速开发和组合,这才是中台构建的目的。而对于微服务来说,更多强调的是单体应用进一步的拆分和解耦,并通过轻量 API 接口高效协同,只要满足这个要求本身就是微服务思想实现。
从传统架构到中台和微服务
下面进一步通过构图来说明从传统架构到中台和微服务。
我们可以简单做下对比映射,即传统架构中的业务系统对应到新架构里面的业务中台,传统架构里面的 BI 系统对应到新架构里面的数据中台。这个对应当然不准确,里面存在差异和区别,也是我们要重点说明的地方。
从传统单体架构到微服务
也可以说是从传统的 IT 业务系统架构到业务中台架构,我在中台和微服务这篇文章里面强调了下,这种转变实际上包括了两个方面的内容,即中台思想和微服务思想。
在当前企业内部 IT 架构转型的过程中,我们实际上需要同时考虑两个方面思想的应用和整合。而这个里面我们也看到实际上微服务技术思想应用相对容易,但是中台思想相对难,中台思想要落地一定就涉及到业务方面的变革或重构。即是先业务转型和敏捷了,才谈得上技术上敏捷支撑。
业务不重构和转型,往往无中台,业务转型和敏捷需求是中台建设核心驱动力。
业务中台和数据中台的区别
对于业务中台相对来说比较好理解,简单一句话就是共性业务能力下沉形成的多个微服务化的业务能力提供中心供上层应用使用。而对于数据中台,我们也可以总结为一句话就是,把数据变成资产并服务于业务的机制。数据来源于业务并反哺业务,不断的迭代循环。
数据中台是实现业务中台核心共享数据的跨域整合,再通过加工后提供整合后的数据服务能力。这里面有两个重点,即第一数据要跨域整合,第二数据要加工处理后再提供增值服务能力,这个加工可能简单的汇总表,也可能是复制的底层数据模型和智能分析算法。
业务中台重点是业务数据化,而数据中台重点是数据业务化,数据来源于业务又反哺业务。就建设和支撑层面来说我原来也总结过,即业务中台是基础业务能力支撑,必须要有,数据中台是增值能力支撑,刚开始没有也不会影响到业务本身的运作。
传统架构里面的 BI 和新架构里面的数据中台的区别
实际上对于数据中台,我们不仅仅要比较和业务中台的区别,还需要比较和传统 BI 的区别。因为从上图我们可以看到数据中台和传统的 BI 系统架构还是很类似。
简单来说传统 BI 和数据仓库的主要场景是支持管理决策和业务分析,而数据中台则是将数据服务化之后提供给业务系统,目标是数据能力渗透到各个业务环节,不限于决策分析类应用场景。数据中台持续不断的将数据进行资产化,价值化并应用到业务,而且关注数据价值的运营。
从我们上面的构图可以看到,核心的区别点即在数据中台反哺业务的一条红线连接。
即数据中台能力要服务于业务系统准实时协同需要。数据中台形成的能力,不论是 ODS 层能力还是 DW 层能力,都可能通过能力开放方式暴露接口给业务应用使用,为业务提供实时或准实时的增值服务能力。
为了做到实时或准实时,一方面你会看到数据中台架构上实际上是包括了大数据平台的核心架构和分布式存储内容,同时还包括了大数据平台中的实时计算和流处理能力。其次,为了将能力提供给业务系统,往往数据中台整体架构上一定会体现一个统一的数据服务能力开放层,这个在传统的数据仓库或大数据平台上是没有的。
数据中台和传统 BI 架构有重合,也有交集。相同的就是整个数据采集集成,数据存储,数据模型构建,数据开发和分析,这些都需要。差异点在于数据中台需要有统一的数据服务能力开放层,提供给业务使用,而弱化了传统 BI 里面的数据分析和报表展现层。
所以我们首先搞清楚数据中台是为增值业务需求服务,BI 平台为管理经营决策服务。这使得两者在数据模型构建,数据开放和提供策略上有差异,但是核心的技术平台能力则是相同的。即你可以基于 Hadoop 整个技术框架体系来构建数据中台,也可以用来构建 BI 数据仓库。