我们是怎么实现一个完整的中台架构的

这次不谈理念，不说方法，就用实际平台讲述我们是怎么实现完整中台架构的

上一篇我谈到中台架构能够成为企业数字化破冰者的关键就是“合”“分”“聚”三言。而构成中台的，又是“有业务”的业务中台，和“有技术”的技术中台两语。掌握了三言两语就可以简单明了的在纷繁复杂的各种中台架构、中台产品和宣传中搞清楚“非中台”、“半中台”以及“伪中台”。

那么完整的具备了“合分聚”三言和“有业务有技术”两语的完整中台长什么样儿呢？接下来我就以我团队所构建的企业数字化开放中台GiSP(Grand Insight Service Platform)为例，说说我们是如何实现完整的企业中台的。鉴于篇幅，在这一篇里我只能走马观花的将三言两语中至关重要的“合分聚”的实现过程说一遍，让大家有一个整体初步的印象。其中涉及的很多建模技术、开发技术、微服务管控技术都得在本系列的后面另外单独分篇阐述，不会让读者你带有遗憾的，只要你持续关注着，我更新不会太慢^_^

GiSP中台架构

1. 在GiSP中，传统软件“整体”生产交付模式被革新为以“零部件”生产的交付模式。即在GiSP中，所有开发都是以微服务为单位的，从需求到部署运营的整个流程，都是以微服务为单位而不是以系统为单位。每个微服务是一个产品/项目里的一个子开发项，但每个微服务都是一个独立的工程，它具有完整而独立的生命周期。——是之为“分”。

下图是GiSP开发平台SA(Service Architecture)的一个截图。SA相当于DevOps当中的Dev。在SA中每个微服务均是独立开发和管理的。本例中，当前中台项目里共有354个微服务。

共享的微服务列表

这些微服务均独立迭代，有新版本发布时，它们会被推送到GiSP的SO(Service Operator)中。SO相当于DevOps中的Ops。下图是SO部署管理功能的一个截图，可以看到每个微服务都是独立部署、运维和管理的。

待部署微服务列表

GiSP从规划、需求、设计、开发、部署、测试、运营、监控实现了彻底的全程微服务化和自动化，从而将“分”字变成了自然而然的开发过程而不是特意的设计。

软件方法和开发过程彻底微服务化

那么，当一个完整系统被拆成这么细粒度的服务之后，业务整体的集成性又是怎么保证的呢？这就需要用“合”字来解决了。

2. 所有的业务能力均以微服务（零部件）的形式存在于业务中台，相互之间对等共享，它们通过模型驱动方法组织为业务整体来保证拆散了的微服务整体的集成性。——是之为“合”。

具体来说，“合”是由数据的集成性—数据模型；业务的集成性—业务模型；系统的集成性—集成模型三个核心模型构成的。

数据模型由数据对象及数据对象之间的关系构成。

数据对象可认为是数据库表的对象化定义。在GiSP中，数据对象的建立将遵循唯一性和共享规则，建模结果将形成全域唯一和共享的数据对象模型库。数据对象之间的关系采用“Association”的语义，通过GiSP中称为Lookup的机制实现。其建模结果是构建了一个如同人际关系网络的数据对象网状关系网络。GiSP将会自动生成维护和访问每一个数据对和它的数据关系网络的SPI和实现代码，并向微服务开放这些SPI。

由平台自动生成的全域的数据关系模型

业务模型由数据对象根据业务实体的需求通过包含（Include）和引用（reference）两种语义聚合而成。

用共享的数据对象组装业务对象

利用数据对象的聚合来组装业务对象，这一步在GiSP中称为建立业务对象模型，即业务模型。它描述的是从领域模型驱动的角度来说，一个业务领域是如何由独立数据对象聚合而成的。下图是由GiSP自动生成的业务对象模型关系图

由平台自动生成的全域业务对象聚合模型

从平台自动生成的业务模型图来看，主对象、关联对象以及这些对象在上一步数据模型中Lookup的其它对象，都会被聚合成一个业务对象整体。这个业务对象整体会被GiSP自动创建成一个Spring Cloud 微服务，并在微服务中自动生成针对这个业务对象处理的一系列API和实现代码。利用这些自动生成的API，处理这个领域对象开发者不需要写一行代码。

在后续的业务处理中，服务消费者不再需要关心数据来自哪个数据对象，也不需要关心一个业务对象是由多少数据对象，是采用什么关系组织起来的。只需要针对这个业务对象整体或部分进行操作即可。利用自动生成的微服务API，当服务消费者向服务提交全部或部分数据时，GiSP会根据业务对象模型识别数据操作，并自动调用上一步数据对象的SPI接口进行处理。

集成模型由微服务之间的相互依赖所构成的关系网络构成。

每个微服务就如同组成一部电脑的电子元器件，而依赖关系就是描述一个电子元器件与其它电子元器件的消息交流通道。在GiSP中，微服务间的集成非常简单，它被称为服务依赖。根据实际业务需求，每个服务都可以依赖全域共享服务库中的任何一个服务。在GiSP的中台架构中，所有微服务都是可共享的，即使这个服务不是由自己团队生产的，只要别的团队共享给出来，它就可以被依赖。仿佛集成电路板将各种电子元器件连接在一起，集成模型将多个微服务集成在一起，共同构建起实际业务实现的流程和脉络，组成一个复杂的业务构件。

设置当前微服务直接依赖的其它微服务

每个服务都有自己的依赖服务，所有的依赖关系形成一个服务之间消息的传递网络。GiSP将实时进行全域运算分析，从而建立起全域的服务集成网络。如同集成电路板一样，把作为电子元器件的微服务集成联动起来。下图展示了从订单合同微服务出发，在全域范围内形成的服务集成网络。在运行期，消息将循着这些网络在服务间传递，将原本独立运行的微服务集成联动起来，最终实现了全景业务集成联动的集成一体化。

由平台自动生成的全域的服务集成模型

同样，GiSP也会为这个集成关系网络生成相应的调用API。开发者并不需要了解这个复杂的集成结构，它是由平台自动维护和展示的；开发者只知道在本微服务中有一系列外部接口的本地代理方法，他只需要像调用本地方法一样调用这些本地代理方法即可。

可见，GiSP通过模型驱动的微服务架构技术，利用数据模型将数据对象“合”成全域数据模型，利用业务模型将数据对象“合”成一个独立业务领域并自动生成一个微服务，再利用集成模型将微服务“合”成一个业务整体。从而实现了三言两语当中的“合”。

现在，业务通过模型合在了一起，并以独立微服务的方式像零部件一样向外提供服务。业务场景又是怎么通过这些零部件组装出来的呢？这就要用到“聚”字诀了。

3. 在GiSP中，原来所谓的ERP/CRM/TMS/PMS等系统，是由共享的微服务像零部件一样，用的不同组装方式构成的——是之为“聚”。

在GiSP中，应用场景被称为“模块”。每个模块都是一个可独立运行的小场景。在下图中可见，在GiSP中，连场景也是“分”成可独立运行的模块的。这些模块构成了共享的业务场景库。

在中台中构建出来共享业务场景库

一个模块由多个页面，以及每个页面上与用户交互的多个按钮和事件构成。在实际开发过程中，通常由UE工程师设计交互原型，模块设计者再依据交互原型将页面和行为建模为模块。

为模块配置页面和路由

接下来为每个页面添加交互行为和事件。每个行为和事件均可从共享服务库中选择要绑定的微服务，指定微服务的版本，并将该行为或事件绑定到微服务的某个开放API上。

将页面行为或事件绑定共享服务的开放API

将页面行为或事件绑定共享服务的开放API

完成上述配置后，一个独立模块就建立完成了。GiSP将会自动生成业务场景模型。我们看到一个结构清晰的，从场景到页面，到行为，再到微服务的开放API的应用结构就生成了。

自动生成的业务场景应用结构图

GiSP会根据上述的配置结果自动生成前端代码、打包、并生成可执行的部署包。下图是GiSP自动生成的模块的运行效果。

业务场景的运行效果

一个业务场景经过几步简单的配置就可以运行，这并不神奇：因为它所调用的微服务是可运行的，微服务的业务构成逻辑是由之前建立好的业务模型和集成模型解释和处理的，而数据的处理，则是由数据模型解释和处理的。因此，我们就用模块这个组装器，用页面及页面上的事件和行为将共享的微服务组装成了一个个的配完即可运行的业务场景；不同的组装代表不同的场景。这就是“聚”的作用。

不管怎么组装，模块都共享业务中台中的同一组微服务，并由同一组模型来解释，所以，不论业务场景怎么独立，怎么变，最终业务是统一的，数据是一致的。业务场景可以快速组装千变万化，但回到业务中台，又变回了企业的集成一体化本质。这一步就是打通企业内部管理和互联网创新之间屏障的关键！

这些组装出来的所有模块则又变成了全局共享的状态，每个模块就成了一个可执行的业务组件，用于组装最后的应用系统。GiSP甚至还实现了将多个模块组装成更大模块的能力。这个以后再说。

最后一步，所谓的业务系统，不过是这些共享模块的组合罢了。我们只需要配置一个菜单，按需求将共享的业务组件组织起来即可，GiSP将会把这些模块全部自动打包，生成业务系统的部署包。

用共享模块组装业务系统

通过这样的机制，为每个客户创建个性化的业务系统简直太方便了。下图就是我们SaaS团队为客户组装的一些业务系统。看似各不相干的那么多系统，其实无非是模块的不同组装罢了。而如果没有适用的模块，我们会在项目上配置一个新的出来。这个新的立刻又会成为可复用的模块了。

下图是我们地产行业ERP系统组装运行结果。它当然不需要写一行代码就能跑，因为每个模块都是独立可运行的。我们也根本不用担心它的集成性：模块可以随便选，服务可以任意组装，可以每个客户都不一样；但别忘了后台它们通过“合”字诀已经是一个集成的整体了。

至此，中台架构中至关重要的“合分聚”三字真言都实现了。中台之所以是解决企业数字化转型中必需的平台，它的作用也就体现出来了：

“合”，让企业实现了标准一致的管理，集成一体的业务，这是数字化的基础；

“分”让企业业务实现了独立部署、弹性化、复用化、共享化，变成支撑企业数字生态无数业务场景的零部件。

“聚”让企业得以快速的、任意的组合它们已经有的业务能力，去构建数字生态中的千人千面的个性化场景，但却不会破坏企业管理的标准和一致。

这篇已经很长了……可以讲的东西太多。我和我的团队花费了整整四年时间来琢磨这些东西，不可能在短短几篇文章里讲完。读者肯定还有很多疑问。慢慢来吧，反正这个系列我说过会很长……只要你有耐心，关注我，跟着我走完，不会让你失望的。如果需要对这篇里所讲的GiSP平台有更多了解，可以关注我们的官方公众号。

下一篇，来讲一个IT从业者一直梦寐以求的境界：GiSP是如何像搭积木一样构建一个软件的。

这将会是很长的一个系列。我会持续的把我这十多年在企业数字化过程中思考、架构、方法和技术，以及我团队所研发的企业数字化中台构建平台发布出来。相信对业界是有着重要的借鉴意义的。

如果您对企业中台架构、企业数字化转型和产业互联网感兴趣，请关注我并期待后续更新。