用友专家：用微服务架构打造企业基础服务能力

Posted 2021-04-14 DevOps时代

作者简介

刘学斌 用友畅捷通架构专家

大家下午好！很荣幸在 DevOps 国际峰会与各位业界同仁分享微服务架构设计实践。

首先自我介绍一下，我来自用友畅捷通公司，目前专注用友畅捷通云平台应用架构设计和流程建模、领域建模、物理建模。

今天给大家分享以下几方面内容。

第一，问题的背景，给大家介绍一下我们为什么使用微服务；
第二，针对这个问题进行分析并给出方案和思路；
第三，具体介绍我们具体的微服务设计中能力建模方法；
最后，做一个总结。

一. 问题的背景

在介绍具体问题之前，我们先回顾一下过去我们企业信息系统发展的历史。

这就是企业信息化非常典型的发展历程，也即所谓的企业信息化1.0。

其历史可以追溯到上世纪90年代。当时在企业里面，信息化刚刚起步，企业在其业务发展过程中，在不同的时期对不同的业务问题由不同的团队乃至采用不同的技术栈研发或者外购一些独立的系统，这些系统面向各自领域问题，相互之间独立运行。

这些独立的“烟囱”型系统，很多相似的功能在不同系统之间重复建设，浪费严重；

另一方面，企业作为一个有机的整体，客观上要求这些系统能够相互协作和交互，不同系统之间的集成是一个复杂的问题，耗时耗力；

此外，由于重复建设，同一套业务逻辑在多处出现，可维护性差，维护业务逻辑一致性是一个挑战。

所以针对这个问题，我们过去有主数据管理管理，处理各个系统数据集成和统一的问题；

采用ESB平台解决各个独立系统之间交互问题。

但是，无论是主数据管理还是ESB总线，它只是一种技术方案，在具体实践中不仅费时、费力，而且可靠性差，极大限制了信息系统的价值。

针对刚才的问题，从2000年初开始，一些企业软件公司把各种企业应用系统在统一的应用平台或技术平台上进行开发，提供一个集成的系统，这也就是企业信息化2.0阶段。

这种方案应该一部分解决了1.0阶段数据集成问题以及系统交互问题。但是我们知道，对一个大型企业来说，一个系统很难解决企业所有的问题。

我曾经调研过一个银行，一共有100多套系统，有自研的，也有外购的。很难想象一个集成的系统或者一家软件供应商解决企业所有的问题。

从这个意义上讲，系统之间互操作和集成是个必然需求。

刚才我们一起回顾了企业信息化的两个阶段，我们再看一下与企业信息化相关的技术发展历程，总的来说，技术发展的历史就是重用技术的发展史。

上图是一个概要的软件重用技术发展历程。

早期的时候我们把常用的一些功能放在一个文件里面，例如C语言的动态链接库DLL，JAVA语言的JAR包，文件可以自由分发，其他人可以通过引入文件来重用常用的功能，这也就是函数库重用。

随着函数越来越多，查询和使用共享功能变得复杂，我们就把类似的函数、功能有机组合在一起，封装成所谓的组件，也就是Windows平台的ActiveX组件和JAVA平台的JavaBeans组件，这也就是我们通常说的组件重用。该种技术要求调用者和被调用者必须在一个机器和进程上，使用上受到位置的约束。

随着技术的发展，后来出现DCOM，调用方和被调用方可以位于不同的进程中，也可以部署在不同的机器上，但是必须局限在一个内网上，并且一种平台的组件只能由同一平台的技术进行调用。例如windows平台的DCOM组件只能在Windows平台技术调用。到后来的CORBA、COM+标准，调用者和被调用者不仅能在不同的机器上，而且不同的技术平台都可以互相交流。

到现在为止，我们发展了微服务架构以及过去的SOA架构，就是说我们可以在广域网的范围内以及跨平台进行调用。

纵观整个技术发展历史，可以看到，技术发展始终追求的是服务、功能能够随时随地的被调用。

所谓随时，也就是说不管它在什么平台上都能调用；

所谓随地就是不管在内网、本机、外网都能调用。

为什么要追求这个重用，一方面我们可以降低复杂性，另一方面可以促进内部、外部的协作。如果说程序是由数据结构加算法（逻辑）组成，共享lib包本质上是重用算法，而服务重用本质是重用数据结构和算法。

二. 问题分析及方案思路

我们刚才从技术方面、系统建设方面回顾了信息系统的发展历程，再说我们面临的问题是什么？

无论是在信息化1.0阶段还是2.0阶段，系统的重复建设是一个问题，重复建设不仅浪费了有限的IT资源，并且增加了维护成本。其次，组织是一个有机的整体，各个部门之间需要相互协作，服务于企业共同的业务目标。现实有打通系统的客观需求，但是打通系统并不是一件简单的工作。

再一个最要命的问题是：这些独立开发的系统都是基于具体的部门级业务问题进行独立开发，很多是采用项目化开发模式，很难站在企业的高度对服务进行抽象。

即使我们从技术上解决了服务之间互操作问题（例如采用SOA，微服务技术架构等），这些遗留在系统中的服务很难被其它的业务系统所重用，也很难通过演进适应未来业务的变化。

针对这些问题怎么去解决呢？看来不仅仅是一个技术问题，不是简单引入一种微服务架构就可以解决。需要从技术和业务两个方面着手。

建立企业基础业务能力，支持业务快速创新；

• 能力建模

• 领域建模/物理建模

• DDD方法

业务服务随时可用（松耦合、协议透明、位置独立）

• 微服务架构

我今天主要分享的是“建立企业基础业务能力”的方法和实践。

三. 业务能力建模

3.1 能力的分层架构

这个是大家在一些讲座或者是网站看到的微服务架构图，基本上都是类似的，基础服务、平台服务、支撑服务还有领域服务，我今天要讲的这一块就是应用服务和领域服务的建模，这块内容离问题最近，解决问题更有效。

我们在讲能力建模之前我们先说一下什么是能力？

我们说到能力就会说到三个词，一个是知识、一个是能力，还有一个是技能。

什么是知识？知识是对一些理论规则的理解，我们叫知识；

能力一般是指自然的或者内嵌的东西；

技能是学习到的一些行为。我们说游泳是一项技能，游泳对应的知识是浮力作用力、反作用力原理；但是游泳的能力是什么？就是手部的肌肉、腿部肌肉很发达这种能力，技能是蝶泳、仰泳。

我们说能力相比技能来说，能力一般是比较稳定的，但是获得的时间比较长。知识一般是学习书本，能力是通过长期的训练。

对于技能、能力、知识，我们在人力资源招聘人的时候把人当成一个系统，无外乎也从这三个角度即知识、能力和技能三个方面对求职者进行评估，大公司更多关注能力，小公司更多关注技能。技能很快就能上手干活，能力更多体现在将来发展潜力，而且能力培养周期比较长。

我们构建一个系统也一样，将系统的技能和系统的能力进行分离解耦，我们把能力和知识的服务叫做领域服务，技能服务叫做应用服务。

3.2 能力架构设计

我们刚才说的是能力以及技能之间的区别，我们怎么去进行能力架构设计？在讲述具体能力拆分之前，先谈谈业务能力有哪些特征。

业务能力首先是唯一性特征，所谓唯一性就是一种能力在企业不同的业务域中只会出现一次，不可重复出现，通过依赖关系与其它能力相关，并且应该有明确的界限。其次是稳定性，相对技能，能力应该变化较小。

举个例子，航空公司提供值机的能力，过去采用手工值机方式，随着互联网技术的发展，现在广泛使用移动APP值机，或者机场自助机器值机。虽然值机的技术手段变化了，值机的能力并没有变化。最后能力还有可分解的特点，高层的能力可以分解为底层具体能力。只有将抽象泛化的能力分解为具体细化的能力，才能更好实现能力服务。

接下来我会举了一个例子就是业务能力建模，能力拆分。我们说从一个大的方向上，系统的目标是说协作企业进行人、财、货、客的管理，我们怎么能把它进行拆分？

我们首先从人、财、货、客这个角度进行拆分。例如，财务属于核算的范畴，从业务的高度视角拆分为战略财务（决策层）、财务会计（对外）和管理会计（对内）。

对于“货”，从业务运作的角度进行拆分，分解为采购、库存、销售。这两个拆分的视角不一样，我们把一个大的系统拆成了很多小的块，拆成小的块就是我们刚才所说的能力，能力有一个重要的特点一个是唯一的，另一个特点是稳定的。

我们拆分了一些能力块，有些能力可能是在这边存在，在那边也存在，但是我们说能力有唯一性特点，需要将重复的能力识别出来，并独立出来，建立与原始能力域之间的关系，这就是能力规范化。

我们抽取像产品、计量单位、组织等能力域后，再把这些能力进行分层，像应用层，还有领域层。领域层包括核心层、支持层、通用层。核心层包含核心领域服务，一般是业务人员可感知的，一般映射为具体业务部门；支撑层包含支持一般是支持业务的某一方面的能力服务；通用层包括一些公共能力服务，例如产品、计量单位等。

我们刚才分了很多能力模块，然后按照这几层的职责把它落下来，大概就是这个样子。

我们把一个能力，或者说我们把企业的战略从自顶向下拆分成很多能力块，然后再进行规范化，每个块是很简单具体的。

一个领域被切分为很多子域，每个子域的职责如何定义？如果子域很少，这个似乎不难；如果子域很多，这个也不简单。也就是说，通过领域切分，我们有效控制了每个领域内部的复杂性，但是完成一个有价值的业务，需要多个子域协作和配合，协作的复杂性提高了。定义子域的职责，必须采用一定的方法。我们采用用例驱动的方式，并借助系统序列图，划分子域职责。

切分能力域之后，采用以上UML序列图的方式，采用用例驱动方法，给每个能力域定义职责。

3.3 领域建模

我们刚才通过能力建模自顶向下基于企业战略拆分了很多能力域，以及确定了每个能力域的职责，我们现在要深入到能力域内部。

一个系统我们不仅要确定它的外观，同时我们也希望看到内部结构是什么样的，这就是领域建模，特别是做大型的复杂的业务系统领域建模非常重要，我不知道有多少人用过。

如果没有领域建模的话，基本上做的是一个东西的表象，很难洞悉到业务的本质。我们经常说业务经常发生变化，需求经常发生变化。客观来说，很多时候是业务表象发生了变化，其业务需要（或者need）并没有变化。

我们在讲领域模型之前，先说一下什么叫领域。

所谓领域就是问题域，面对的是具体业务世界。什么叫模型？模型对应了两个关键词，一个是简化，一个是抽象。

所谓简化就是抽取与问题相关的东西，将与解决问题无关的东西忽略掉，减轻人脑的负载。所谓抽象是由表及里，洞悉事物本质。模型按照目的不同可分为两种，即分析模型和设计模型。

分析模型目的是认识一个旧世界，设计模型的目的是为了建设一个新世界。所谓领域模型是分析模型，是我认识领域的一种方式，我们把领域里的一种概念，以及概念中的相互关系，一般通过图表的方式把它表达出来。

我们在沟通的时候，包括跟业务人员沟通的时候我们都用领域模型，领域统一语言也是基于领域模型建立起来的。

我们举一个领域模型的例子，我们做个业务系统的人都会用过计量单位。计量单位比较简单的一种设计方式就是设计一个计量单位组，计量单位组里面可以包含多个计量单位，单位与单位之间有一个换算关系。计量单位组中的单位和单位之间换算关系都交给用户自己定义。

我们知道，世界上计量单位类型是有限和确定的。 

我们看一下它的模型是这样的，它一般是计量单位类型，什么叫计量单位类型，我们说长度是计量单位类型，时间也是计量单位类型。

计量单位类型有两种，一种是基本计量单位类型，基本单位类型是物理量里的7种，长度、时间、质量等。

什么叫导出单位类型，就是由基本计量单位组成的，导出单位与基本单位之间存在量纲换算关系。例如面积单位是导出单位，是由长度单位的平方组成的。无论是基本单位类型的单位，还是导出单位类型的单位，其单位和单位之间的换算率是确定的，这些数据系统可以预制。

更重要一点的是，由于导出单位类型与基本单位类型之间存在确定的量纲换算关系，只要设置基本单位的换算关系，就可以推导出导出单位类型的单位换算关系。

这些都是计量单位的领域知识，在刚才的模型中并没有包含这部分知识，下面的模型就内涵量计量单位领域知识，不仅预置了计量单位及其换算关系，而且还预置了导出量纲与基本量纲换算关系，丰富了模型知识。

建立好领域模型可以方便我们理解领域概念和知识，促进内外沟通，指导我们面向对象开发。

但是仅仅停留在这个层面还是不够的，我们需要基于领域模型转化成物理模型。

物理模型是领域模型的关系表达，物理模型与领域模型不是严格的一一对应，基本原则是采用简单映射，与领域模型结构基本一致；但是有时需要考虑性能、复杂性等因素，需要做一些取舍。

建立好物理模型之后，领域模型落实到数据表中。

在开发过程中，基于数据库表生成Repository和Model层代码，领域模型设计成果也反馈到代码中，真正指导开发工作。

四. 总结

刚才分享了微服务架构下业务能力建模的方法和实践，总结下来有以下几点：

1. 简单采用微服务技术架构不能实现支持业务持续发展和业务快速创新，过去SOA项目化所走过的坑已经说明了这一点；

2. 业务世界纷繁复杂，业务能力相对稳定，业务能力建模的过程是洞悉业务本质的过程。企业能力建模的目的是让软件能以较低的成本和风险应对将来的变化（云产品尤其如此），模型的质量决定产品的未来。

3. 能力建模是一个复杂过程，不可一蹴而就，大处着眼，小处着手，迭代开发，循序渐进。此外，对领域理解的深度影响模型质量，充分与领域专家沟通，学习业界先进经验和参考模型，并借助工具和方法让建模能够落地；

4. 当今能用钱解决的问题都不是问题，充分利用业界成熟的技术服务，有限的资源聚焦于企业自身核心竞争力。

本文根据用友刘学斌老师在 DOIS 2018 · 北京站分享整理而成。