前言
随着大数据和云计算的飞速发展，单体式应用越来越不适用于复杂的业务需求。微服务架构的出现则将规模庞大的应用分解为小的、互相连接的服务，成功地解决了单体应用所存在的问题。此外，由微服务组成的服务集在传统虚拟机或物理机方式下搭建步骤繁多，搭建逻辑复杂，集的安装和部署都有一定的局限性，如配置文件之多、配置节点数量之大，部署过程涉及计算机网络、Ｌｉｎｕｘ操作系 统、ＳＳＨ 无密码 登 录、ｊｄｋ环 境 配 置、Ｓｈｅｌｌ脚本等一系列纷繁复杂的操作，动辄分布式集的部署以失败告终，且无从下手出故障根源，这就在一定程度上拖慢了开发进度。而随着大数据与云计算的飞速发展，服务集的需求度也明显上升，如何快速搭建服务集也成了业内人士研究的重点。
微服务管控平台
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们一样，构建生态圈，快速创新，持续发展。
微服务的服务编排
在微服务架构下，服务会拆分成很多新的微服务，原有的业务将借助服务编排工具，方便地实现微服务之间的协作，进而快速、灵活组装成各类业务场景。
采用基于微服务架构的服务编排技术，能有效提升软件模块的复用度，降低应用实现复杂度，打造多厂家协同的开放生态，实现从业务场景编码到业务场景编排的提升。
在开发业务场景时，单个服务往往无法完成全部需求，必须依靠一组服务相互之间的协作才能达到目的。通过服务编排可以将多个分布、独立、自治的微服务根据业务语义及逻辑关系进行灵活集成，通过实现各服务之间的协作，进而构成一个完整的业务流程/业务场景。
因此，服务编排是实现复杂系统场景实现的重要技术手段。
服务编排通过可视化的界面直观地编辑和展示流程，不需要修改程序就可以根据需求动态改变流程，提供了服务化下动态改变流程的条件。
正是有了现在微服务的概念以及对功能进行服务化改造，才使得原有的静态功能编排，提升到了动态的服务编排，使得业务人员能够根据业务需要灵活动态地编排服务，满足业务多样性的需要。