微服务编排在网管支撑系统中的研究与应用
杨朝晖，李飞，付永振
（中国移动通信集团河北有限公司，石家庄 050021）
摘　要　近年来，面向下一代通信网络，未来网管技术架构一直是OSS领域被关注的焦点课题之一。本文按照云原
生、集中化、平台化和开源化的设计原则，提出了一套未来网管基础技术框架，设计并开发了微服务管控平台，统一作为上层网管应用的PaaS平台支撑层。同时通过微服务化改造和容器编排，在已建设的网管支撑系统中加以验证，实现了业务需求的敏捷快速支撑，取得了良好的应用效果。
关键词　微服务管控平台；容器；微服务；编排
中图分类号  TN915.07      文献标识码  A      文章编号  1008-5599（2019）06-0031-06
收稿日期：2019-05-27
近年来，随着通信业务的快速发展，尤其是面向5G，如何快速支撑客户需求，如何实现业务快速上线，
通信网络如何与云计算深度融合，网管支撑手段如何快速支撑业务发展，一直是讨论的热门话题。同时随着中国移动2016年启动NFV 试点，网络功能虚拟化逐渐被业界所认知，NFV/SDN 等CT 与IT 融合的新技术对OSS 提出了新的智能化要求。
王烁怎么说球球参照国际通信企业和互联网公司成功运维经验，未来网管技术架构将立足自主研发，充分应用开源技术实现网管核心能力的自主掌控，并遵循云原生（Cloud Native）、集中化、平台化和开源化的设计原则，提出未来网管的基础技术框架，作为上层网管应用的统一技术栈。
1  微服务概述
上海部分平台黄桃罐头卖断货微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立
部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。尽管微服务这种架构风格没有精确的定义，但其具有一些共同的特性，如围绕业务能力组织服务、自动化部署、对语言及数据的去集中化控制等。
随着应用过程中管理微服务的增多，如何快速的将已经提供的微服务能力进行组合发布，实现业务的快速创新，如何提供界面化的业务编排功能，如何通过API 网关实现对外开放，成了一个个需要迫切解决的问题。
本文提到的微服务管控平台，基于容器技术进行开发，实现了Mesos、K8S、Yarn 等资源框架调度，目标是对通信网管4+1架构进行重构，最终实现IT 层面
的能力开放，支撑下一代网管建设，支撑网络业务的快速变化发展。下面将围绕网管支撑系统提取微服务，在微服务管控平台上进行微服务编排和相关技术研究，并结合实施效果做阐述和说明。
2  项目研究
各种门事件图片2.1 容器编排
随着容器技术的日益成熟以及生态圈的不断扩大，容器作为微服务承载工具，既可以为微服务提供轻量级虚拟化操作系统资源，又可以对微服务应用进行可视化管理。目前业界许多企业都创建了各自的容器服务，但真正的价值是企业能够在不改变这些服务正常运行的情况下，将容器集成起来创造出新的业务模型，以满足用户需求和不断变化的市场，为组织带来更大的价值，构建敏捷型企业。
如何让微服务架构与容器结合创造更多的价值？相对于传统架构，微服务架构下更需要通过各微服务之间的协作来实现一个完整的业务流程，可以说服务编排是微服务架构下的必备技能。
常见的容器编排方式如下。
(1) 编制：面向可执行的流程，通过一个可执行的流程来协同内部及外部的服务交互。通过中心流程来控制总体的目标，涉及的操作及服务调用过程如图1所示。首先要有一个流程控制服务，该服务接收请求，依照业务逻辑规则，依次调用各个微服务，并最终完成处理逻辑。这种方法的好处是流程控制服务，时刻知道每一笔业务所处的状态，监控业务成了相对简单的事情。这种方法的坏处是流程控制服务涉及太多的业务逻辑，耦合度过高，变得臃肿。
(2) 编排：面向合作，通过消息的交互序列来控制各个部分资源的交互。参与交互的资源都是对等的，没有集中的控制。这种方式可以看作一种消息驱动模式，
或者说是订阅发布模式，实现方案多是异步的。每笔业务到来后，各个监听该事件的服务会主动获取消息处理，并可以按需发布自己的消息。这种方法的好处是耦合度低，每个服务都可以各司其职。这种方法的坏处是业务流程是通过订阅的方式来体现的，很难直接监控每笔业务的处理，因此需要增加相应的监控系统，来保证业务顺畅进行。
(3) API 网关：可以看作一种简单的接口聚合/拆分的方式。每笔业务到来后，先到达网关，网关调用各微服务，并最终聚合/拆分需反馈的结果。这种方法的好处是对外接口相对稳定。这种方法的坏处是只适合业务逻辑较为简单的场景，业务逻辑过于复杂时，网关接口耦合度及复杂度会急剧升高，变得臃肿。
服务的粒度越小，服务需要组合的可能性就越大，本文结合本地业务独立且复杂的特点，最终采用API 网关加编制的方式来实现容器的编排。2.2 解决思路
基于已有系统，根据流程引擎逻辑将已有功能进行微服务化。使用界面托拉拽的方式借助执行引擎进行服务编排组合，保持业务服务间的调用关系和上下文，实现数据模型的自动转换，完成同步、异步、异步模拟同步、超时重试、事务补偿等功能，从而降低编码要求，实现业务的快速创新。
3  实现方案
3.1 微服务管控平台
网管微服务管控平台主要实现微服务部署、API
开
图1  常见容器编排方式
放的管控，通过集中配置、集中日志、集中监控实现对微服务的运维支撑。提供多租户管理机制，允许租户申请自己空间、进行微服务部署、服务API 开放以及对空间、API 调用的管控机制。图2介绍了微服务管控平台总体架构。
平台架构包含3个部分：API 开放管控、微服务调度和公共服务。
（1）API 开放管控：通过注册中心和API 网关实现服务发现和开放管控。
（2）微服务调度：通过混合资源调度实现微服务部署、升级和扩容等管理。
（3）公共服务：包括管理门户、运维监控、集中配置以及安全中心。
微服务管控平台选用SpringCloud 架构，其中注册中心和配置中心选择Consul，API 网关为Zuul，客户端框架为Ribbon，服务容错为Hystrix。集中日志选择ELK (Elasticsearch Logstash Kibana)。各模块间调用关系如图3所示。3.2 微服务运行
微服务开发完成后，根据微服务开发语言选择一个合适的
Docker 镜像，镜像中包含微服务运行环境。通过Docker 命令把微服务打包称为Docker 镜像，再通过Kubernetes(K8S)对Docker 镜像进行部署运行。3.3 微服务梳理
本文单独对网管统一采集平台进行微服务梳理，目前该
林一霆系统从业务功能上分为管理中心模块、运行管理模块、集成
开发模块、数据质量监控模块、
系统自监控、元数据管理、执
行控制以及执行容器模块等。首先每个模块进行容器化部署，平台自身的管理中心模块具备上传其它功能模块的功能，待上传成功后自动实现解压、安装、部署、启动和管理，同时提供标准化的开放管理接口，以实现对扩展功能模块的管理功能。每一个执行容器按采集网元类型进行划分，其中单个网元类型执行容器微服务接收平台下发的执行命令，获取预先编排好的流程执行，执行完毕后返回通知服务，该服务具备微服务单一职责，独立部署等特点。网管统一采集平台功能框架如图4所示。
图3  微服务管控平台模块间调用关系
图2  微服务管控平台总体架构
微服务梳理是各系统微服务化改造的关键点，通过这个项目我们总结了Matrix 方法论，对业务流程、功能服务和数据信息3个层面并行梳理分析，通过这个方法论可以快速、准确梳理出微服务，通过对网管系统微服务的梳理，抽取出公共微服务，实现服务共享，形成公共服务层。3.4 微服务编排
3.4.1 流程画布与元件功能
微服务编排包括流程画布和执行元件等功能模块。3.4.1.1 流程画布
具备增加目录、增加元任务、保存、编辑元任务、删除任务、复制活动、粘贴活动、查看、元任务复制等功能，如图5 所示。
图5单独介绍了一种常见的微服务编排业务流程：首
先通过HttpMicroServiceHttp-1、HttpMicroServiceHttp-2元件获取数据后，发给Join-1元件。Join-1元件根据关键字进行Join 运算后将数据发送给Join-2元件。HttpMicroServiceHttp-3元件获取数据发给JsonTrans 元件进行格式转化发给Join-2元件。Join-2元件根据关键字进行Join 运算后发送给Join-3元件。HttpMicroServiceHttp-4元件获取数据发送给Join-3元件。Join-3元件获取HttpMicroServiceHttp-4和Join-2数据后，根据关键字进行Join 运算后数据给服务调用方。3.4.1.2 元件功能
（1）流程首节点：此元件标识流程开始，在设计流程图中如果存在多个首节点，以编号最小的默认为首节点，如图5所示。
代评中级职称
（2）微服务节点：通过该元件能够连接微服务，发送指令获取返回报文，图6以指令平台服务调用为例说明元件参数及配置。（3）自定义解析节点：此元件完成对上一个元件（指向本元件的来源节点）所生成报文解析操作。
（4）消息合并元件：此元件用于将多个来源元件输出的文件合并为一个返回消息的
操作。
图5  编排操作界面
图4  网管统一采集平台功能框架
3.4.2 流程微服务化
通过画布与元件实现了业务场景流程的组合编排，如何让编排的流程组成微服务呢？这就要借助微服务管控平台。
3.4.2.1 微服务模版
首先设计一个微服务模版，模版包含服务注册、服务配置和服务心跳这些微服务的基本能力。
（1）服务注册：通过服务自动注册、发现，实现服务动态自动发现和接入，降低手工维护工作量，避免手工维护和微服务实际情况不一致。
（2）服务配置：可以为每个微服务定制集中配置参数，方便微服务运行期动态调整。
（3）服务心跳：被监控的元件定期发送心跳信息给监控进程（或者由监控进程轮询被监控元件），如果一定时间间隔内收不到心跳信息就被认为失效了。3.4.2.2 微服务生成可爱的狗名字
编排好的流程引擎打包在一起，生成一个流程程序，微服务的注入过程和生成过程如图7所示。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 微服务的监控
支持按照阈值进行微服务监控配置，比如触发访问次数阈值、清除访问次数阈值、触发访问失败率告警阈值、清除访问失败率告警阈值、触发时延告警阈值、清
图6  元件参数配置示例
图7  微服务注入生成过程