微服务管控平台

前言

随着大数据和云计算的飞速发展，单体式应用越来越不适用于复杂的业务需求。微服务架构的出现则将规模庞大的应用分解为小的、互相连接的服务，成功地解决了单体应用所存在的问题。此外，由微服务组成的服务集群在传统虚拟机或物理机方式下搭建步骤繁多，搭建逻辑复杂，集群的安装和部署都有一定的局限性，如配置文件之多、配置节点数量之大，部署过程涉及计算机网络、Ｌｉｎｕｘ操作系 统、ＳＳＨ 无密码 登 录、ｊｄｋ环 境 配 置、Ｓｈｅｌｌ脚本等一系列纷繁复杂的操作，动辄分布式集群的部署以失败告终，且无从下手找出故障根源，这就在一定程度上拖慢了开发进度。而随着大数据与云计算的飞速发展，服务集群的需求度也明显上升，如何快速搭建服务集群也成了业内人士研究的重点。

微服务管控平台

3.1 微服务管控平台

网管微服务管控平台主要实现微服务部署、API 开放的管控，通过集中配置、集中日志、集中监控实现对微服务的运维支撑。提供多租户管理机制，允许租户申请自己空间、进行微服务部署、服务 API 开放以及对空间、API 调用的管控机制。下图介绍了微服务管控平台总体架构。

平台架构包含 3 个部分 ：API 开放管控、微服务调度和公共服务。

（1）API 开放管控 ：通过注册中心和 API 网关实现服务发现和开放管控。

（2）微服务调度 ：通过混合资源调度实现微服务部署、升级和扩容等管理。

（3）公共服务：包括管理门户、运维监控、集中配置以及安全中心。微服务管控平台选用Spring Coudl架构，其中注册中心和配置中心选择Consul，API 网关为 Zuul，客户端框架为

Ribbon，服务容错为 Hystrix。集中日志选择 ELK (Elasticsearch Logstash Kibana)。 各 模 块 间

调用关系如下图所示。

3.2 微服务运行

微 服 务 开 发 完 成 后， 根 据微服务开发语言选择一个合适的Docker 镜像，镜像中包含微服务运行环境。通过 Docker 命令把 微 服 务 打 包 称 为 Docker 镜像， 再 通

过 Kubernetes(K8S)对 Docker 镜像进行部署运行。

3.3 微服务梳理

通过对目标业务系统进行微服务梳理，目前该系统从业务功能上分为管理中心模块、运行管理模块、集成开发模块、数据质量监控模块、系统自监控、元数据管理、执行控制以及执行容器模块等。首先每个模块进行容器化部署，平台自身的管理中心模块具备上传其它功能模块的功能，待上传成功后自动实现解压、安装、部署、启动和管理，同时提供标准化的开放管理接口，以实现对扩展功能模块的管理功能。每一个执行容器按采集网元类型进行划分，其中单个网元类型执行容器微服务接收平台下发的执行命令，获取预先编排好的流程执行，执行完毕后返回通知服务，该服务具备微服务单一职责，独立部署等特点。业务系统的功能框架如下图所示。

微服务梳理是各系统微服务化改造的关键点，通过这个项目我们总结了 Matrix 方法论，对业务流程、功能服务和数据信息 3 个层面并行梳理分析，通过这个方法论可以快速、准确梳理出微服务，通过对网管系统微服务的梳理，抽取出公共微服务，实现服务共享，形成公共服务层。

3.4 微服务编排

3.4.1 流程画布与元件功能

微服务编排包括流程画布和执行元件等功能模块。

3.4.1.1 流程画布

具备增加目录、增加元任务、保存、编辑元任务、删除任务、复制活动、粘贴活动、查看、

元任务复制等功能，如下图所示。

作为一种常见的微服务编排业务流程 ：首先通过 Http Micro Service Http-1、Http Micro

Service Http-2元件获取数据后，发给 Join-1 元件。Join-1 元件根据关键字进行 Join 运算后将数据发送给 Join-2 元件。Http Micro Service Http-3 元件获取数据发给 Json Trans元 件

进 行 格 式 转 化 发 给 Join-2 元 件。Join-2 元 件根 据 关 键 字 进 行 Join 运 算

后 发 送 给 Join-3 元 件。Http Micro Service Http-4 元件获取数据发送给 Join-3元 件。Join-3 元 件 获 取 Http Micro Service Http-4 和Join-2 数据后，根据关键字进行 Join 运算后数据给服务调用方。

3.4.1.2 元件功能

（1）流程首节点 ：此元件标识流程开始，在设计流程图中如果存在多个首节点，以编号最小的默认为首节点，如图所示。

（2）微服务节点 ：通过该元件能够连接微服务，发送指令获取返回报文，以下是指令平台服务调用为例说明元件参数及配置。

（3）自定义解析节点 ：此元件完成对上一个元件（指向本元件的来源节点）所生成报文解析操作。

（4）消息合并元件 ：此元件用于将多个来源元件输出的文件合并为一个返回消息的操作。

3.4.2 流程微服务化

通过画布与元件实现了业务场景流程的组合编排，如何让编排的流程组成微服务呢？这就要借助微服务管控平台。

3.4.2.1 微服务模版

首先设计一个微服务模版，模版包含服务注册、服务配置和服务心跳这些微服务的基本能力。

（1）服务注册 ：通过服务自动注册、发现，实现服务动态自动发现和接入，降低手工维护工作量，避免手工维护和微服务实际情况不一致。

（2）服务配置 ：可以为每个微服务定制集中配置参数 , 方便微服务运行期动态调整。

（3）服务心跳 ：被监控的元件定期发送心跳信息给监控进程（或者由监控进程轮询被监控

元件），如果一定时间间隔内收不到心跳信息就被认为失效了。

3.4.2.2 微服务生成

编排好的流程引擎打包在一起，生成一个流程程序，微服务的注入过程和生成过程如下图所示。

3.4.2.3 微服务化

从 Docker 注册的公共镜像仓库下载一个镜像，不同的操作系统安装 Docker 镜像会有些许不同，新版的 Redhat 和Centos7 自 带 有 Docker 包， 直接安装即可。然后从该镜像中创建一个容器，启动后即可配置运行自己的微服务，同时也可以根据需求对 Docker 镜像进行修改。

比如创建 Docker 用户组，调整内存和交换空间， 启用防火墙的端口转发和为 Docker 配置 DNS 服务。编写安装 JDK 的 Dockerfile，安装语言包，设置微服务环境变量，设置语言环境变量，运行命令 Docker Build-t 定义名称及路径，即可生成一个容器镜像，然后通过命令启动微服务。

3.4.3 执行跟踪

随着微服务设计理念在系统中的应用，业务的调用链越来越复杂，一个请求可能会涉及到几十个服务的协同操作，需要进行跟踪分析。通过调用链，把一次请求调用过程完整的串联起来，实现了对请求调用路径的监控，便于故障快速定位。如各个调用环节的性能分析（如各个 API 使用时间和使用堆栈情况）、还原调用链各个环节依赖关系、SQL 语句打印、IP 显示等。整个跟踪过程需要关注两个 ID，首先微服务收到请求后生成一个全局 Trace ID，通过 Trace ID 可以串联起整个调用链，一个 Trace ID 代表一次请求。除了Trace ID 外，还需要 Span ID 用于记录调用父子关系，每个元件会记录下 Span ID，通过他们可以组织一次完整调用链的父子关系。

通 过 跟 踪 实 时 关 注 各 个 调 用 的 性 能 指 标， 根 据Trace ID 可以查出所有调用记录，通过 Span ID 可以组织起整个调用父子关系，实现问题跟踪，比如响应时间和错误记录等。

3.4.4 微服务的监控

支持按照阈值进行微服务监控配置，比如触发访问次数阈值、清除访问次数阈值、触发访问失败率告警阈值、清除访问失败率告警阈值、触发时延告警阈值、清除时延告警阈值等。设置完成后，系统自动读取服务告警阈值信息，基于判断及时触发告警，微服务相关的告警包括告警正文、告警时间、活动状态等告警信息。

电信运营商组件化和微服务化

与现有多数网元功能复杂不同，功能组件是将电信网络以功能为单位进行分解，每个功能组件往往对应一个相对单一的功能，且相互间的耦合度也比较低。这样每个功能组件的开发比较简单且可以“微服务”的方式独立加载/升级。但由于一个组件/微服务所实现的功能一般比较小且单一，无法独立对外提供较大的电信服务，这就需要将相关组件/微服务按照一定

的关联关系进行组合以对外提供一个完整的电信服务，该过程称之为服务编排。由于不同客户和应用场景所需的组件可能不同，我们可以进行针对性的服务编排，为不同客户和场景构建不同的编排实例，每个编排实例称之为一个网络切片。组件被开发出来后通过组件仓库的方式进行统一管理，当需要使用某些组件构建服务时，由服务生命周期管理系统以服务切片模板方式进行组件的组织并完成实例化。为不同的用户/应用场景构建的网络服务形成系统中一个个服务切片，由系统根据接入用户的特征进行灵活地服务切片选择。因为服务切片中的组件都是一个个独立的“微服务”，因此可以对其进行独立升级和缩扩容而对其他功能组件没有影响。

组件化和微服务的引入彻底打破了电信网络僵化的现状，不但可以提升网络的健壮性，加速新业务开发与部署，同时还提供了更灵活商业模式创新。但组件化和微服务同时也造成了电信功能的“颗粒化“，对管理要求大大提高，这就需要一套更强大的管理和支撑体系作为保障。

支撑体系由服务开发框架、集成框架和运营框架几部分构成，开发框架提供了支持多种不同技术和开发语言的开发和测试环境，集成框架可以提供完善的电信级组件服务仓库和服务集成机制，方便各种不同形式的服务集成能力。而运营框架则实现了网络服务全生命周期的管理，并提供对不同虚拟化资源技术的适配。同时，该支撑体系可以通过强大的portal实现与广大应用开发者和客户的互动，使整个体系成为一个全方位开放的系统。通过该支撑体系，电信服务的开发、部署、管理和开放都变得异常轻松，运营商也可以像OTT们一样，构建生态圈，快速创新，持续发展。

微服务的服务编排

在微服务架构下，服务会拆分成很多新的微服务，原有的业务将借助服务编排工具，方便地实现微服务之间的协作，进而快速、灵活组装成各类业务场景。

采用基于微服务架构的服务编排技术，能有效提升软件模块的复用度，降低应用实现复杂度，打造多厂家协同的开放生态，实现从业务场景编码到业务场景编排的提升。

在开发业务场景时，单个服务往往无法完成全部需求，必须依靠一组服务相互之间的协作才能达到目的。通过服务编排可以将多个分布、独立、自治的微服务根据业务语义及逻辑关系进行灵活集成，通过实现各服务之间的协作，进而构成一个完整的业务流程/业务场景。

因此，服务编排是实现复杂系统场景实现的重要技术手段。

服务编排通过可视化的界面直观地编辑和展示流程，不需要修改程序就可以根据需求动态改变流程，提供了服务化下动态改变流程的条件。

正是有了现在微服务的概念以及对功能进行服务化改造，才使得原有的静态功能编排，提升到了动态的服务编排，使得业务人员能够根据业务需要灵活动态地编排服务，满足业务多样性的需要。

服务编排流程

服务编排通过友好的编排界面，根据业务场景对基本功能服务进行组合，形成一个可执行的业务流程，协同各相关服务功能的交互，最终完成用户定义的业务场景。服务编排包括编排( choreography)和编制( orchestration) 2 个部分。编排是以协议的形式从全局视角定义成员服务之间必须遵守的通信契约和交互行为。编制则是从组合服务的视角描述服务内部的业务流程及其执行细节。编排形成的是服务之间的拓扑关系，不具有可执行性，因此需要转变为易

于执行的编制模型。服务编排的总体架构如下图所示，包括编排过程、编译过程和执行过程。

1) 在编排过程中，服务编排界面从服务注册中心获取服务描述，应用开发人员使用服务编排界面，将已有服务按照业务的功能流程进行组合，形成格式化的编排流程文件。

2) 在映射过程中，映射程序通过映射规则将描述服务拓扑关系的编排流程文件通过流程编译，形成描述组合服务内部服务调用过程的编制执行文件。

3) 在执行过程中，编制执行引擎加载编制执行文件形成组合服务，组合服务消费者调用组合服务，编制执行引擎将根据编制执行文件中定义的流程，进行流程执行和组件调用，最后将执行结果返回给组合服务消费者。

服务编排后，其形态是一个组合服务，集成后形成的组合服务有完整的服务接口和服务描述文件，在服务注册和使用时和基本服务没有区别，区别仅在于这个组合服务是通过服务编排来实现出来的，而不需要通过程序开发代码编码的方式来实现。

服务编排的输入是已注册到服务管理中心中的服务，这些已注册的服务经由应用开发人员进行编排组合后，产生一个新的组合服务，并将该服务注册到服务管理中心。

编排后的服务和普通服务一样，可以编排进其他服务中。

服务编排关键技术

2 服务编排关键技术

2．1 服务描述

调度控制系统不同于互联网系统，开放性及标准化程度相对较低，因此在新一代调控系统设计时就要求“标准统一、继承开放”。

新一代调控系统通过 Protobuf 规范服务接口参数格式，通过服务总线统一通信方式，通过服务管理规范服务注册流程。

服务编排中服务是核心对象，其结构内容在服务编排的每个环节都会使用，关系到服务编排

的编排力度和后续的功能实现。

例如在服务描述中包含服务启动命令，则在服务执行时该服务还未启动，服务编制执行引擎能够通过任务调度功能自动启动服务，完成服务编排的执行流程。

在服务编排中需要规范服务描述，从服务管理中获取服务相关信息。对于服务参数的表示是服务描述的核心内容。在服务编排的过程中，上一个服务的输出往往不能完全匹配下一个服务的输入，可能需要从之前的多个服务输出中拆分出相关内容，再进行重新合并，才能形成新服务的输入数据，而拆分的最小结构就是参数。因此服务描述中需要对服务的参数名称、类型和属性进行具体定义。现有的简单服务接口规范已对基本的服务信息进行了描述，但是缺少服务参数、服务启动命令等服务编排所需要的关键信息。因此服务编排的服务描述将在简单服务接口规范的基础上，采用 XML 格式补充参数、启动命令、场景等信息的描述，并形成编制规范。

服务描述的具体格式为：

〈Service( type1: param1，type2: param2，…) prompt /〉

〈param1 mode type1 /〉〈! --参数 1--〉

〈param2 mode type2 /〉〈! --参数 2--〉

…

〈cmd value/〉〈! --命令--〉

〈scenario value /〉〈! --场景--〉

其中第 1 行为服务定义的描述，与简单服务接口的服务定义格式一致，Service，type 和param 分别表示服务名、参数类型和参数名，用英文标识，prompt 为提示符，是对服务功能的说明，可以使用中文进行描述。从第 2 行开始为参数列表，是对参数的补充说明，mode

可以为 in，out 或 in /out，分别表示输入参数、输出参数或输入输出参数。最后的 cmd 和

scenario 标签定义了服务的启动命令和场景信息。

2．2 流程编译技术

流程编译技术与程序的编译类似，都是将高级语言变成计算机可以识别的二进制语言。流程编译中的高级语言是基于可视化图形产生的描述服务执行流程的编排流程文件，转化成的二进制语言为程序可理解执行的编制执行文件。通过用户操作图形界面形成的编排流程文件描述了业务流程中参数、组件，以及它们之间的对应关系，但是编排流程文件还不能直接执行，需要编译成可高效动态解析的描述内部组件调用关系的编制执行文件，供编制执行引擎使用。流程编译如图 3 所示，包含词法分析、语法分析、检查优化和流程映射 4 个过程。

词法分析从图形产生的编排流程文件中识别出各个基本单元，如参数、组件以及参数和组件之间的对应关系。语法分析在词法分析的基础上进一步进行语义层面的解析，确定各个组件的输入参数和输出参数，获取组件之间的调用关系以及在每一次调用中组件的输入参数所对应的其他组件的输出参数。检查优化过程用于确保流程的正确和高效，需要检查参数类型，确保组件调用时客户端和服务端对应的参数类型匹配; 检查服务流程，确保流程不存在死循环和孤岛，具有最终输出; 优化并发过程，根据各个组件的输入参数值可获取的先后顺序，

将同一时间可获取所有输入参数值( 即可调用) 的组件进行并发执行。词法分析、语法分析和检查优化过程后形成一个保存在内存中的流程编译的中间结构，该结构按照编制执行模板的规范要求记录参数、组件和相互关系。根据编制执行文件高效动态解析的需求，采用支持运行时高效动态解析的 Protobuf编码格式作为编制执行文件的模板格式，这样映射过程就转变为按照编制执行模板进行动态编码的过程，编制执行引擎加载编制执行文件后解析的过程，就转变为按照编制执行模板进行动态解码的过程。

2．3 流程执行技术

流程执行技术提供解决对多种编排流程的表示和处理的方法。其核心是解决串行、并行、分支和循环等多种流程的表示和执行方式，以及嵌套流程的处理过程。一个基本的串行流程由一组组件及其对应参数组成，编制执行引擎顺序执行每个组件，直到最后一个组件处理完毕。并行流程与串行流程类似，只是流程内的各个组件采用多线程方式同时执行。分支和循环流程由前置组件、判断参数和后续流程组成，前置组件是在进行条件或循环判断时需要预先执行的组件，一般用于产生条件判断的参数值; 判断参数用于决定是否进入分支或循环; 后续流程是分支或循环真正的执行内容。串行、并行、分支和循环之间支持相互嵌套使用，流程中的组件可以替换成另一个流程，实现流程嵌套。

2．4 组件调用技术

服务编排主要是处理服务调用，但是为了提高组合服务的执行效率，还需要提供基于函数和动态库方式的调用形式。服务、函数和动态库在服务编排中通称为组件，是服务编排中一个最小的执行单元，根据执行效率从高到低，分为函数组件、动态库组件和服务组件。函数组件是集成在服务编排系统中的简单的函数调用，虽然运行速度最快，但只能实现固定的几种最基本的功能，如取最大值、最小值等; 动态库组件是通过动态库接口调用的方式实现业务逻辑的模块，运行时需要加载额外的动态库性能中等，同时限制了运行的功能只能和组合服务在一台机器上; 服务组件为以服务的方式提供功能的模块，涉及网络通信性能相对前

2 种较低，但限制也最少，功能执行可以和组合服务在不同的机器上。组件的执行分成 2 个部分: 一是对组件的输入输出参数进行编解码，二是根据组件类型调用组件。

服务编排过程中的编解码有 2 个部分: 一是组合服务本身输入、输出参数的编解码，二是组合服務内部各个成员函数输入、输出参数的编解码。基于Protobuf 的 动 态 解 析 特 性，编 制 执 行 引 擎 使 用Protobuf 进行编解码，同时也支持 M 语言编码。在编制执行引擎接收到数据之后，通过获取类型文件，依据 Protobuf 的反射功能，自动创建具体类型的反射对象，完成编解码功能。解码后产生一个或多个参数值，这些参数值被保存在内存中对应参数位置，供后续组件使用。组件执行时会选择需要的参数，获取参数值，函数和动态库组件直接使用，服务组件需要将多个参数重新编码后再使用。编制执行引擎根据组件的类型采用不同的执行方法。对于函数组件，编制执行引擎直接调用对应的函数接口; 对于动态库组件，编制执行引擎将根据动态库名称打开该动态库，并把它装入内存，然后根据函数名称查找函数在内存中的地址，最后调用动态库中的对应函数; 对于服务组件，编制执行引擎首先根据场景、子场景等信息定位服务位置，然后通过服务总线调用对应的服务，最后获取服务返回结果进行解码，完成组件执行过程。

其它服务编排策略和规范

当前服务编排的策略主要分为基于工作流的服务编排策略、基于构件的服务编排策略和基于人工智能（Artificial Intelligence，AI）的服务编排策略三类。其中，基于构件的服务编排策

略是通过对服务构件进行定义来提供服务编排的内部实现脚本。在基于构件的服务编排策略中，服务流模型定义了服务构件行为，因此修改服务流时意味着要对每个构件的设计进行变更 。考虑到综合资源管理的资源范围和能力，可采用基于构件的服务编排策略进行重构，将面向业务的服务接口按照资源管理最小粒度进行重新编排，并根据服务建模的元数据来动态生成轻量化和可复用的服务组件。

微服务规范化

为保证规范性，统一微服务在与外部系统交互的过程中还应当遵循以下接口方式：

（1）代表性状态传输（REST）服务：

①综合资源系统和外部系统提供的数据处理的接口数据集，主要提供一次操作10条以内的数据增删改查的接口服务，接口数据传输采用对象标记（JSON）字符串，采用Unicode的可变长度字符编码（UTF-8）；

②外系统与综合资源系统之间的接口采用代表性状态传输服务形式来进行业务数据的交互；

③为了保证接口升级不影响以前的功能，代表性状态传输服务中都必须要带版本号，如IP:PORT/api/v1/PON/get ONUby Account/{account}；

④在每次调用完成应用程序编程接口后，外部系统都会得到一个状态码、错误码和错误原因描述，便于外部系统告知用户定位问题并做出适当的处理；

⑤为了排除接口服务被攻击、恶意调用以及非法调用等，所有应用程序编程接口在客户端调用服务端的时候必须经过身份验证。

（2）分布式远程过程调用（XRPC）服务：

服务调用如下图所示：

①综合资源系统内部采用分布式远程过程调用服务形式来进行业务数据的交互，或者大批数据处理提供的接口方式，减少了REST服务中的数据限制和效率问题；

②分布式远程过程调用数据都采用综合资源内部程序语言（JAVA）数据对象进行传递；

③分布式远程过程调用服务最终调用的是统一微服务接口

其它服务编制和服务编排

微服务架构继承了面向服务架构的整体思路，强调将单体型应用或服务拆分为由具体、微小、独立的服务应用，服务是最核心的抽象手段，业务被划分 ( 组件化 ) 为一系列粗粒度的业务服务和业务流程。服务通过基于标准、精确定义的接口进行通信，通信可能涉及简单数据传递、两个或更多在一个活动中协作的服务。微服务架构能有效降低系统的耦合性，增强灵活性。采用Web Service 实现微服务架构应用最广泛。

单个服务功能有限，难以满足应用需求，把单个服务按一定的业务流程逻辑组合起来，从而提供更强大、更完整的业务功能。在基于微服务架构的应用系统中，所有功能均是被精确定义的、可调用的、独立的服务，能够被灵活有序组合而构建不同的业务流程 , 最终达到敏捷的、不受限制的服务集成目标，从而使 IT 能够随着业务需求的变化而自由调整，达到所谓的“随需而变”的最高境界。

服务组合方式包括服务编制和服务编排。目前，基于编制的 Web 服务组合描述规范主要是 WS-BPEL，基于编排的 Web 服务组合描述规范主要是 WS-CDL。

(1) 服务编制

服务编制描述一个参与者使用一个中心流程来协调不同的服务操作，其结果可以看作一个新的服务，可以执行，只是执行的过程需要调用别的服务。

(2) 服务编排

服务编排描述多个参与者为实现多组织业务功能而进行的交互，也就是说编排主要描述的是不同流程之间的交互情况，其结果可以看作一个业务流程，也可以执行。

3 微服务组合设计

3.1 服务编制设计

MUSIC 的 接 口 以 Web Service 发 布， 每 个MUSIC 接口就是一个 Web Service 服务，配置接口的关系，关注点为接口功能整合，最后以一个新接口对外发布，用户可以利用

MUSIC 提供的接口使用工具调用该接口。接口的关系包括顺序、分

支和循环 ( 下图）。

3.2 服务编排设计

与服务编制类拟，将 MUSIC 接口视为服务，根据业务流程配置接口，关注点为业务逻辑，最后以处理结果提交给用户。接口的关系包括顺序、分支和循环（下图）。

进而将业务流程组合形成业务场景。在业务

场景中，每个业务流程的地位平等。允许用户订阅业务流程和业务场景执行结果（下图）。

微服务架构和容器作为服务CaaS

微服务架构是面向服务架构（Service-orientedArchitecture，SOA）之上发展而来的新兴的软件体系架构，它将传统的单一、大型的应用程序（Monolithic Application）构建为一系列细粒度、独立部署、松散耦合的服务。每个服务围绕具体业务进行构建，运行在其独立的进程中，提高隔离性和模块化，实现持续交付和部署。服务与服务间采用轻量级的通信机制互相协作（通常是基于 HTTP协议的 RESTful API）。微服务架构带来诸多好处，包括单个服务具有更简单的代码库，同时具有隔离更新和独立扩展的能力，使用不同编程语言编写服务，并利用不同的中间件或者不同服务的数据层。微服务架构开启了应用程序开发的新趋势，通过使用微服务去大幅度降低系统的复杂性并提高弹性和可扩展性，更加容易地进行伸缩、移除和部署系统的组件，而且提高使用不同框架和工具的灵活性。ASP 通过微服务架构将大型工作流应用，划分成大量细粒度、低耦合的微服务任务。这些微服务是轻量级的，并且执行独立于彼此的不同任务，因此根据用户需求的不同而快速、独立地调度和部署，从而提高了工作流应用的灵活性和敏捷性。通常 ASP 将用户提交的大量工作流应用部署和调度到现有云计算服务提供商（Cloud Service Provider，CSP）提供 IaaS 的虚拟机上，例如亚马逊提供的 Amazon Elastic Compute Cloud（Amazon EC2）。但是由于微服务架构将工作流应用划分成大量细粒度、松耦合的协同工作的微服务任务，每个微服务任务对计算资源的需求一般比较（通常是单个 v CPU 和 MB 级别的 RAM），远远小于 IaaS 上的虚拟机规格（多个 v CPU

和 GB 级别 RAM）。而且微服务强调工作流任务之间松耦合，对任务隔离性有一定的要求，而且要求任务之间进行轻量级通信协作。若是采用传统 CSP 提供的 IaaS，租赁大量的虚拟

机来对微服务工作流提供计算资源和资源隔离，会造成大量的计算资源浪费。于是，在现有云计算平台下对微服务工作流的进行部署和调度成为了一个棘手的问题。而随着轻量级虚拟化技术——Linux 容器（Linux container，LXC）和 Docker 容器（Docker container）的出现解决了大规模微服务的部署和调度的问题。云计算的核心是虚拟化（Virtualization）。虚拟化带来了从物理机（Physical Ma-chine，PM）分离计算资源的好处。采用系统级虚拟化技术（Hypervisor）的虚拟机包含完整的客户机操作系统（Guest OS）和特定软件，此外虚拟机的运行环境和配置可以封装成镜像并任意拷贝。这种机制通常用于在云计算中运行的应用程序。虚拟机解决了调度、镜像封装和计算资源存取的问题。但是由于虚拟机包含有完整的

Guest OS，导致了虚拟机实例需要额外的 CPU、RAM 和磁盘存储资源，而且其启动缓慢（通常需要几分钟）。而采用轻量级虚拟技术（Lightweight Virtualization）的容器，使用了系统级别的机制——基于 Linux 内核提供的两个机制：Cgroups（实现计算资源按需分配）和Namespace（实现任务隔离）。多个容器共享一个宿主机操作系统（Host OS）内核，容器中包含需要部署的应用和它依赖的系统环境，容器大小通常只有几十到几百 MB。容器没有了虚拟机的 Guest OS，实现了更轻量级的虚拟化，资源的额外开销更小，启动快速（通常达到秒级启动）。所以容器被作为了更为灵活的封装、交付和编排软件服务与应用程序的工具。随着 Docker及其生态系统的出现，带来了持续部署与测试、跨云平台支持、环境标准化与版本控制、高资源利用率与隔离、容器跨平台性与镜像、易于理解且易用和应用镜像仓库等好处，使得容器技术更加易于使用。由于微服务架构里面强调单个组件是在独立的进程里面运行，各个组件之间在部署时必须有进程级别的隔离。一台服务器需要初始化几十个甚至更多的进程进行应用组件的部署。为了保持进程间的隔离性，可以使用虚拟机，但是几十个进程都完全使用独立的虚拟机是不现实的，而这个问题可使用轻量级的 Docker 容器来解决，Docker 容器能够十分便捷地搭建微服务。Docker 容器技术使用 Cgroups 和 Namespace 的

Linux 内核接口，允许不同容器共享相同的内核，同时容器之间进行完全的隔离。Docker 执行环境使用 libcontainer 的模块并标准化其接口。

Docker 同样为容器镜像提供类 Git Hub 的资源库 Docker Hub，让容器的共享和发布非常简单，也正是这种相同主机上的容器隔离简化了不同编程语言开发的微服务代码部署。使用

Docker，通过创建一个 Dockerfile 来描述所有需要的编程语言、软件框架和应用服务之间的依赖库。每个 Docker 容器是独立的容器，完全做到进程级别的隔离，资源占用率小，这些特点满足微服务架构的开发测试和自动化部署。虚拟机技术与 Docker 容器技术的比较如下图所示。

如今多数主流的云服务提供商，例如 Amazon Web Service、Microsoft Azure、GoogleCloud 和阿里云等，都推出了容器即服务（Container as a Service，CaaS），包括 AmazonElastic Container

Service（Amazon ECS）、Google Kubernetes Engine（GKE）、Microsoft Azure Container Service

（AKS）和 Alibaba Cloud Container Service等。相比较传统的基于虚拟机技术的云计算平台，CaaS 以容器为资源分割和调度的基本单位，封装整个软件运行时环境，为开发者和系统管理员提供用于构建、发布和运行分布式应用的平台。CaaS 位于 IaaS 和 PaaS 之间，虽然

IaaS 提供虚拟化计算资源，PaaS 提供特定于应用程序的运行时服务，但 CaaS 通过为部署的应用程序（或应用程序的不同模块）提供隔离的环境将 IaaS 和 PaaS 粘合在一起。当容器云专注于资源共享与隔离、容器编排与部署时，它更接近传统的 IaaS；当容器云渗透到应用支撑与运行时环境时，它更接近传统的PaaS，如下图所示：

通常，可以在私有物理机上直接使用 Docker 容器来部署、运行微服务任务。但是在公有云平台（如 Amazon Web Service、Google Cloud、Microsoft Azure 和阿里云等）上，考虑到 Docker

容器需要依赖于 Host OS，一般将微服务运行在 Docker 容器中，通常一个微服务部署在一种类型的容器实例之中，再将 Docker 容器部署在虚拟机实例上，虚拟机实例只有操作系统而不包含其他的应用软件。微服务部署与传统应用部署的比较如下图所示：

业务流程建模

业务流程建模

业务流程是对组织内外各种管理逻辑的抽象与视图的刻画。流程管理理论随着信息时代的到来而日渐丰富，信息技术逐渐成为流程管理的重要支持手段。业务流程管理是从工作流管理拓展而成的一个新的研宄领域，其目的是通过使用若干新方法、技术与工作流软件来对涉及人、组织、企业应用、业务对象与其它信息资源的企业实际运作流程的设计、执行、控制、分析等诸多环节进行全面的支持与管理。

业务流程管理的本质是构造卓越的业务流程，因此业务流程是其核心。为了描述、分析与执行业务流程，必须首先对它进行建模。业务流程建模的主要目的是以模型元素及规范的形式，

对复杂的流程结构与关系予以抽象表达，并通过模型使流程参与者对业务流程逻辑达成一致的理解。

服务编排

如今的业务流程协作模型主要分为两大类：中心化与分布化。传统的中心化编排模型称为编配（Orechestration），描述复杂计算机系统、中间件与业务的自动化的安排、协调与管理，是典型的中心化的模型。新兴的分布式的编排模型称为编排（Choreography），对应着分布式的模型。中心化的优点是容易获取全局状态，缺点是控制中心脆弱，容易形成瓶颈，分布化则刚好相反。为了实现分布式系统环境中的协作，业界倾向使用分布化的模式，因此需要协调各个参与者之间的合作，一起完成业务目标。随着服务的运行环境越来越去中心化，微服务编排也由传统的中心化编排模型发展到了分布式的编排模型。传统的中心化编配无法很好地描述如今复杂的业务流程，也无法快速响应业务流程的迅速变化，故需要采用分布式编排方式。ＷＳ－ＣＤＬ（Web Service Choreography Description Language，网络服务编排描述语言）即Choreography模型的一种实例。

通过对主流的服务编排方法进行分析，可以发现它们都存在某些程度上的不足。具体表现在以下几个方面：第一缺少可以运行的系统。第二模型比较复杂或者模糊，未明确区分或定义服务注册、服务编排、服务执行等关键组成部分。第三服务的执行并没有充分利用分布式自治场景。如今电子商务平台皆为大规模的分布式系统，并且逐步采用微服务架构来构建。其中很难实现一个“上帝视角”的控制中心，故实践“声明式”思想时可使用Choreography。提高分布式环境中服务编排的效率，增加系统自动化的性能，对于电子商务企业降低成本有非常重要的意义。本系统主要针对分布式环境中的微服务进行编排，是典型的去中心化协作模式。

在目前的跨界服务中，例如新零售业，这几个差异与问题日益突出，特别是当服务从单中心简单流程转变为多中心复杂流程时，分布式环境中的服务有产生了服务编排的问题。如何尽可能地利用现有的数据实体与服务流程、重用己有资源来完成新的服务建设，已成为服务开发的重要问题。因此，新的业务流程建模方法需要完成如下任务。

＊有效管理数据。与以活动为中心与传统的以实体为中心的流程建模方法不同，该业务流程建模方法应能在有大量实体的服务中有效地管理数据。同时数据之间的相互依赖关系也可以由该模型描述表达。

 需求与开发人员的分离。

当新的服务需求提出时，业务人员能够通过现有资源迅速定位与设计，而无需开发人员的参与。开发人员应专注于开发新的能力，他们不需要了解甚至不了解客户的服务需求。

 代码可被高效管理与重用。

所有的函数与代码模块都应与流程分离，这些代码在本模型中被抽象为能力。本模型应轻松高效地管理与应用这些能力。

 分布式环境中的服务编排。

传统单中心简单流程己经无法满足大型企业的业务需求，随着越来越多企业使用多中心复杂流程，中心化编排模型己经无法满足需求，必须使用分布式服务编排。

服务编排路由算法

在进行服务编排的时候，需要考虑某个服务的具体提供者，此时涉及到服务选择算法。本系统将服务的选择抽象为路由问题，从而可使用路由算法来进行寻路。传统的静态路由算法有其应用场景与问题，无法很好的适用于此处所述的分布式运行环境，对此本系统使用的是动态路由算法结合静态路由算法来进行服务服务选择。

１静态路由算法

静态路由算法也称非自适应算法，该算法不会根据运行时的输出来改变选择策略。相反，其使用选定的策略来进行选择。静态意味着在服务选择之前己经建立了模式，并且己经建立的服务社群关系不应该被改变。当系统已经确定下来一条服务组合路径，服务启动器首先需要选择第一个服务提供商的服务。

泛洪算法

泛洪算法是静态路由的暴力算法，该算法比较简单粗暴。服务社群从邻居社群获取消息，然后将消息发送给除了原始输入社群以外的其他邻居社群。很显然，该方式可以帮助找到最短路径，但其产生大量的重复消息，非常耗时故不适合于实际的工作环境应该改进这种算法来减少交换的消息数量。服务社群记录自己已经泛洪的信息，当再次泛洪该信息时，该社群可以取消发送从而减少重复消息的发送。

泛洪算法是一种构建所有的服务组合的简单算法。该算法可产生最佳路径，但消耗大量时间与空间。其所有可能性是每一个服务社群总数量的乘积，当单个服务的数量增加时，服务组合的总量将急剧增加。所以该方法不适合在大型网络环境中进行服务选择。

Dijkstra算法

另一种静态算法是Dijkstra算法。在该算法过程中，社群中的每个服务节点都有标记信息，标记信息中至少包含两种信息，一种是表示从源头结点到达该节点的权重，另一种信息是该节点自身的状态。节点一般有两种状态，暂定态与稳定态。在算法刚开始的时候，所有的节点权重都是最大值，状态都是暂定态，随着源头结点慢慢从邻居那里搜索整个图查找最短路径，每个节点的权重与状态渐渐稳定下来，直到找到结束节点。

本系统使用Dijkstra算法作为静态路由算法，为服务的最短路径查找提供算法理论与编码实现的支持。

２动态路由算法

在实际的服务环境下，只有静态路由算法是远远不够的，还需要结合动态路

由算法来进行服务选择。组合互联网上的服务需要应对高度动态性的环境，服务

选择算法必须能够进行动态的路由，这样才可以应对新服务的不断涌现与旧服务

的偶然消亡。

Bellman-Ford算法

Bellman-Ford算法又称距离向量算法。在该算法中，每个服务社群都维护一张路由表，其中记录了每个邻居的权重信息。每个服务社群通过接收邻居社群发来的向量信息来更新自己的路由表，从而维护整个系统的信息。距离向量算法很简单但却有一些缺陷。在静态系统中，该算法传播路由表到每一个服务社群，但是在动态的系统中，其稳定性不够好。当服务社群被改变之后，例如建立了新的联系，相关信息的传播会很慢，这意味着一些服务社群会保有错误的选择信息而不自知。

链略状态算法

为了改进距离向量算法，出现了新的动态的算法：链路状态算法。链路状态算法又称为最短路径优先算法，该算法的步骤如下：

１．发现邻居节点，获取其网络地址。

２．计算每个邻居节点之间的成本或延迟。

３．构建一个接受新消息的数据包，链路状态数据包。

４．将此数据包发送给另一个邻居。

５．计算到其他邻居的最短路径。

系统经过该算法可以迅速收敛，从而维护整个系统中服务信息。本系统采用链路状态算法作为动态路由算法的实现方案。

业务流程模型

本系统采用了业务流程模型用于描述、设计、验证与管理系统中的服务。在该模型中构建了处理数据的实体特征模块、处理功能与接口的能力特征模块，和在此两者基础上用分层方式管理服务流程的流程模块。这三个子模块中的每一个模块可以独立完成服务的部分建模工作，它们共同构成了流程模型整体。

为了实现前复杂场景中业务流程模型需要实现的任务，本流程模型所使用的的实体特征模块、能力特征模块、精化流程模块三个子模块主要功能如下：

实体特征模块可用于描述与定义服务中使用的数据实体以及数据之间的相互依赖性，以实现有效管理数据。

能力特征模块用于管理在服务开发期间生成的能力，以实现代码管理与重用。此处的能力主要指的是服务中涉及到的功能与接口。

精化流程模块是一个层次化模块，可以通过状态、活动的约束来描述服务流程与数据，以实现需求与开发人员分离。

简而言之，精化流程模块从能力特征模块调用能力，能力特征模块处理实体特征模块中实体的数据，精化流程模块描述实体特征模块中实体的生命周期。这三个模块一起构建了本次的流程模型。

实体特征模块

实体特征模块用于为具有大量数据的实体进行建模，并可表示实体数据之间的相互依赖性。

本模型通过使用特征建模方法提出一种四层实体构造方法，将实体构造为四层的树，以订单实体为例，第一层是实体层。在新零售中，第一层可以是客户、商品、订单或其他数据实体。第二层是通过实体关联关系分类的特征。例如在订单的实体中，用户可以是第二层的节点，因数据从用户（买家与卖家）获得并保存在订单中。第三层包含同步读取、写入与显示的小数据集，第四层是属性。

能力特征模块

能力特征模块旨在将功能代码与流程解耦，从而以有效的方式管理它们，并避免滥用功能。能力特征模块可以通过特征建模方法来建模，能力之间的约束也可通过此方式来表达。其中，叶子节点是元能力，其他节点代表复合能力，父子节点之间的关系确定调用方式。通过构建能力特征模块，可在系统中管理服务所用到的功能与接口。通过对能力的调用，实体可完成服务流程并实现状态的转移。能力特征模块也采用与实体树类似的树状图来表示能力，但不限制层级数。

精化流程模块

精化流程模块旨在通过三个约束来表达实体的生命周期（服务流程）：状态、活动与数据。该模块可以通过此约束分层地解析与管理复杂的流程，其本质上是—个以数据为中心的模型。确定主要实体后，下一步构建其生命周期。例如当系统需要交易服务时，订单是其主要实体。在状态约束层，系统需验证订单可能出现的状态。然后在活动约束层中，系统在状态之间添加活动与网关，并使用能力来填充活动。最后在数据约束层中，系统通过将参与者绑定到活动，配置能力的输入与输出以及确认条件来确定服务流程。精化流程模块通过这三个约束来逐渐精细化服务流程，该模块是分层逐层精细化的。精化流程模块一共分为五层，每层都有明确的目标，有利于业务需求的分解，也有利于业务流程的复用。

流程模型的应用

新零售作为一种新的零售模式，它利用大数据与人工智能的先进技术来更新商品的生产、流通与分配流程。新零售是商业生态结构的翻新，集成了在线服务，线下体验与现代物流。使用本业务流程模型构建新零售业务流程的步骤如下：

第一需要构建并确认实体。

当需要构建新服务时，应首先确认参与此服务的实体。这些实体由实体特征模块构建。实体特征模块可以帮助检查实体中属性之间的约束。服务涉及的所有实体中，应有一个主要实体。服务流程围绕着主要实体展开，只有主要实体拥有能绑定到该服务的里程碑状态。其余实体使用固定状态，该状态是一个名为“参与者”的保留关键字此外，参与者实体的属性可以被当作服务中的资源来使用。对于新零售，主要实体是订单，参与者包括客户、卖方、银行与电商平台。此时订单是一个主要实体，它包含商品、客户、卖家与其他信息。

第二确定主要实体可能出现的状态。

由于上文已经确认新零售服务的主要实体是订单，下一步是建立状态约束流程。状态约束流程的里程碑与主要实体的状态绑定，在本例中主要实体为订单，故绑定的状态约束流程包括待支付、待发货、待收货、待打款、待评价与已评价。“开始”与“结束”是保留关键字，表示流程的开始与结束。服务流程即状态约束。

第三通过活动与网关来精细化流程。

因为主要实体的状态由活动与网关驱动，从而在流程里程碑之间转化。在构建新零售的状态约束流程之后，需要在里程碑之间插入活动并用能力填充活动，以获得精细化的活动约束流程。所有的能力都在能力特征模块构建的能力树中进行管理，不同能力之间的约束是在能力树中构建的。一旦能力被嵌入到服务流程的活动中，能力特征模块可以检查是否存在误用或滥用行为。开发人员只需开发能力树中缺乏的新能力，而无需重新“造轮子”。此举可帮助企业组织节省大量的人力物力。至此获得了活动约束流程。例如买家有一个下订单活动。因活

动与能力分离，因此活动的结构得到简化。活动“下单”需要填充能力，且需阐明其前置条件与参与者实体。在此情况下，需要一种称为“创建订单”的能力来填写“下单”活动所需内容。此能力需生成订单并将客户的资金转移到第三方平台，订单的ＩＤ与实际价格应在执行能力后生成。若系统中缺少某能力，开发人员仅需根据能力表来对应开发，无需与业务人员进行沟通。对应的，业务人员可直接从能力树中取出并使用某能力，无需麻烦开发人员进行重复开发。

第四配置服务流程。

配置主要指对参与者、能力与条件进行配置。业务流程模型将其中的活动可与参与者绑定在一起，该设计主要用于处理实体之间的交互问题。通过该方式，可在同一活动中处理来自不同实体的数据，并保持以数据为中心的流程的优点。配置完参与者之后需要配置能力。能力被分配给前一步骤中的活动，输入与输出则不固定。在此步骤中，输入与输出被绑定到所涉及实体的属性与资源上。精化流程模型中关系的条件最后来配置。条件是布尔表达式，指示进程是否可以从前一个节点转化到后一个节点。在配置参与者、能力与条件后，服务流程被精化到数据约束级别。通过对参与者、能力与条件进行配置。为其添加配置项，并设定配置项的取值范围。例如用户在新零售平台点击下单后，平台检测用户的支付状态，如果用户在线支付，则提供在线支付方式。如果用户到店支付，则通知商家准备收款。如果用户超时（可

选下单后12小时、商户确认后3小时、最长24小时等配置）未支付，则取消订单。这对应着下单之后的网关节点的走向，以及对支付超时的数据约束。

通过业务流程模型的使用，可以更好地针对复杂的服务场景进行建模，也更符合企业快速迭代、高复用、低耦合的需求。

在以往的模型中，可重用的功能、接口与服务，这些能力是在代码级别进行管理与维护的，只有系统的开发人员与编码人员知道查找与使用该能力的方式。

本业务流程模型中通过能力特征模块来管理这些能力。能力采用标准方式封装、管理与调

用，使得业务人员也可以使用其来构建服务。本模型将活动与能力分离，根据对现代服务业与电子商务等新型服务产业的观察可知，对于某些服务，其流程拓扑结构非常相似，仅活动的能力有细微差别。故可以通过这种分离方式来将开发人员与业务人员解耦，同时增加系统的重用性。

对于服务的内部流程，模型使用分层方式来管理，现在的服务变得越来越复杂，且在某种程度上与其它一些流程类似，分析大型服务的流程变得越来越困难。此外，若需开发与现存服务类似的新服务，常见做法为重新开发，这将浪费大量的人力物力。为了降低分析服务流程的难度，同时提高服务的重用性，本模型中使用了精化流程模块，它可从三个约束层面构建流程。通过这种方式，可以从不同的视角来了解服务的全貌。

Netflix Conductor

本系统使用Spring Cloud框架来进行微服务系统的设计与实现、使用Netflix Conductor来进行微服务编排的设计与实现。本系统在Spring Cloud中利用Java类来表示Choreograpy编排模型中的实体与关系，在Netflix Conductor中利精化流程模块确定了服务具体的流程，对于系统中微服务的管理与运行，需要使用微服务编排模块来处理。微服务编排模块实现了Choreograpy编排模型。

在Netflix Conductor中利也称为决策者服务。当工作流事件发生时（例如任务完成、失败等），决策者将工作流蓝图与工作流的当前状态组合，识别下一状态，并编排适当的任务或更新工作流的状态。决策者使用分布式队列来管理预定任务。存储层一般使用Dynomit存储引擎。

Netflix Conductor框架将微服务称为任务，将编排称为工作流。此框架可通过Spring Cloud提供的微服务来定义任务，使用时需按照规范将微服务转化为任务脚本定义完系统中所有的微服务为任务之后，再按照Choreograpy编排模型的消息图与系统快照编排来定义工作流。

其它

其它

其它

其它