“徙说数字化”云徙产品系列直播课的第2期于本周二19:00准时直播，云徙科技首席架构师陈新宇博士围绕“中台：可变、可建、可控！云徙xLightning的构建原理”进行了精彩分享，以下为精华实录：

中台的起源与定义

中台源起数字化，从技术的角度解读数字化，其实就是三个词语：连接、数据、智能。

通过连接产生数据，基于数据发现规律产生智能，通过智能来帮助我们决策，实时指导行动产生新的连接，周而复始，生生不息，从而推动企业业务的增长。

大家可以看到，一边是现时可用的一堆技术手段和工具，比如人工智能、大数据、云计算等等，一边是企业想要达到的业务目标，比如改善客户体验、改进产品、提升运营效能等，从而降本增效，促进企业业务增长。技术手段和业务目标中间存在的鸿沟就是企业如何建设数字化系统来支撑数字化转型。

而很多企业建设系统的方式是建设了了非常多的系统，并且在不断地重复建设，比如财务系统、供应链系统、HR系统等，也包括B2C、BBC等交易商城。烟囱式的建设导致企业建设系统的成本高、数据不通、没有沉淀企业的数字资产等。再者这些系统都是单体方式，无法应对互联网大用户的高并发。因此，企业需要改变建设应用系统的方式，通过引入一个抽象层来把公共的能力沉淀起来，而这个抽象层就是中台。

中台是基于云计算、大数据、人工智能等新一代技术架构打造的持续演进的企业级业务能力和数据共享服务平台。

业务中台是以业务划分领域，业务领域划分边界，形成高内聚、低耦合的面向业务领域的能力中心，比如商品中心、交易中心、营销中心等等；数据中台则首先要构建人货场主题模型和下单、支付、评价等事件模型，并通过机器学习建设标签等算法模型。业务中台和数据中台一起合力来支撑上层的商业应用。

中台建设的本质

一句话概括中台建设的本质：分析相似性和差异性，从而管理通用性和可变性。

平时大家来谈建设系统都说我这个系统跟其他系统很不一样，这个企业跟其他企业的需求很不一样，但实际上细拆，打开表层往下深挖后就会发现原来它们是有共通性的。比如，金刚石和石墨看起来就是完全不同的物质，但往下分析都是碳原子组成的，只不过组织方式不太一样。

中台在系统建设上最终落地的方法是什么呢？我们提了四个中台建设的基石：颗粒度、构件标准化、组装方式、可变性。

1、颗粒度

一个系统通过前后端分离会拆成前端和后端。后端拆成微服务，微服务是由很多的API组成的。前端现在也流行微前端。微前端是由页面组成的。微服务、微前端正好是在同一层，即物理部署单元。

我们认为以API或页面作为一个组装的颗粒度，太细了，需要在微服务、微前端和API、页面之间增加一层颗粒度，我们叫功能包。

2、构件标准化

标准化分为两层：

功能包自身的标准：第一，功能包的结构标准，诸如在开发功能包时，代码工程结构的问题；第二，打包标准，即开发出来的功能包如何打包？第三，展示标准：打完包的功能包本身如何展示？

功能包间关系的标准：第一，使用标准；第二，组装标准，如何把它组装出来；第三，管控标准，如何让一个管控平台去管控功能包里面的内容。

3、组装方式

从大的角度有两类，第一类是无关系组装，相当于是砌墙式的，把砖叠上去就行了，砖之间没有关系。

第二个是有关系的组装，这个关系就是依赖关系，依赖关系细分又分成两类，本地引用和远程调用。有一类特殊的本地引用是扩展。

4、分离通用性和可变性

不管是颗粒度、标准化、还是组装方式，都是为了可变性，来使用生产出来的系统能满足企业不同业务的需要。

我们需要考虑是什么东西在变，为什么会变，怎么变的？

什么在变？就是变化点，我们一定要把它抽象地建模分析出来什么在变；

为什么变？一般就是业务需求，也可考虑技术角度的原因；

怎么变？就是变化的候选值。

之后，就需要对变化点的值先用合适的候选值，既候选值赋值或绑定到变化点，最终让变化点固定下来。固定下来的过程就是赋值和绑定的时间，但问题是什么时候去绑定，这个时机很重要。

怎么分析变化点？简单的方法就是场景-需求矩阵，把场景一一列举出来，然后整理需求点，看看同一个需求点是否适用于不同的场景。如果有不适合的场景，那个地方就是可变化的点。

分析通用性和可变性的目的，不是说变化点越多越好，我们应该尽量减少变化点，让我们的系统更通用，简化系统的开发，同时又让它适应各种场景。
前面讲到绑定的时机，绑定的时机分成这三大类：第一类，开发的时候绑定，第二类是部署的时候绑定，第三类是运行的时候绑定。

中台的构建过程

围绕上面绑定的时机一个一个展开，再来讲系统的构建过程。

图片开发时可扩展

（1）规划预埋式扩展接口，整理非预埋式逻辑。

我们现在有很多不同的组件、不同的功能包，它们之间是怎么扩展的？第一，下层的功能包已经预埋了一些可扩展的扩展点，上层的功能包根据需要选用扩展点、变化点。但是系统不是那么简单，不可能所有东西会被预先想到，都被预埋好，所以我们需要第二种，非预埋式。提供一种非预埋式的、可以动态嵌入的，插入一些处理前代码或置换代码。

（2）引擎机制

引擎对于系统的可扩展性是很重要的，在此以促销引擎举例。

什么样的人，什么样的商品，在什么店铺下，什么时间，满足什么条件，才可以做什么动作，是满还是赠，把促销策略整理好后，组装成一个触发器，再配合前端下单的时间点、用户行为，就形成了最终的促销引擎。当有新的促销活动，很容易扩展，而不是做整体系统的开发，所以引擎机制也是我们动态可扩展的很重要的方式。

要把系统组装起来，比如说我们的商品也可以组装起来，为了这个系统可跑，还会需要依赖一些其他的中间件，比如说cache、消息队列或配置中心等等，但是这些所需要提供的提供者本身不是我们在开发时候绑定的，是我们把这个系统组装完以后，部署到具体某一云环境，才会具体绑定的过程。

前端页面在部署时也是可替换的。比如移动端现有三大类：移动APP、H5、小程序。为了开发这些程序，有不同的语言，如React、Taro。需要针对不同的语言实现多个渲染引擎；再上层就是在做页面编排时候的统一语言，也就是数据模型。当需要把这个开发出来的移动端的应用部署成APP的时候，比如是部署成安卓APP的时候，就会根据指定的AppWidgets和渲染引擎，把这个对应的实现打包到对应的代码里面去。 

可配置什么呢？在这个系统里面不同的构建或功能包里面所提供的配置项，需要把它管理起来。首先要把这个分布式的系统里面所蕴含的、可被控制或可被配置的部件、配置项收集起来，上报到统一的配置中心，配置中心根据配置项做一个配置视图的设计，让运营方便配置，所以他会做一些配置视图的管理，配置完的系统本身或配置具体的值再统一下发回各自的中心。

配置项会根据不同的租户、不同的业务来配置，我们叫业务空间，不同业务空间需要做隔离，所以当不同的中心在启动的时候，会根据它当前这个业务所在的租户或业务空间找到合适的配置项，从而达到系统可动态柔性的执行，改变它的运行行为，根据参数和流程编排去改变它的行为。

开发时可扩展、部署时可替换、运行时可配置，但实际上做的过程中我们会发现还缺少一个，如果所有的东西都让别人可配置，特别是放在最后来配置，其实会加大了业务开发工作量和系统的复杂性，可能导致系统也不好运维。

如何简化？预组装。当系统要上架到市场让别人使用之前，可以进行一定的预组装。按照特定的场景或特定的解决方案先把它组装好，组装好的结果也可以上架到市场，来简化部署和运行时候的一些配置工作。

支撑中台构建的工具体系

为了支撑以上复杂的过程，需要一个工具体系。 

功能包的开发需要一个开发平台；开发出来的系统得让它构建，需要一个构建平台；最终把它们组装起来，需要一个组装工厂。

组装构建出来的系统本身需要一个管控平台，来把功能包里面的内容、配置项上报回来，让它管控；同时配置的结果需要回传回去，这些组件得有一个地方可以存储、共享，这就是物料市场。

为了支撑以上概念，我们需要设计一个一体化开发平台。打通规划、建模、开发、集成、部署、运营，通过业务与数据一体化全链路开发平台来加快中台落地速度。

由此，按上述理念构建的参考实现即云徙xLightning的架构如下：

 首先是业务中台和数据中台，其次需要一个一体化、全链路的技术平台来支撑复杂的业务中台和数据中台的建设，以简化开发。