基于微服务架构的数据链领域综合应用平台的探讨与分析

中国电子科技集团公司第二十研究所 鱼昆 李桂斌

针对数据链领域综合应用平台中包含诸多不同依赖环境、不同架构、不同软硬件要求的软件，本文首先分析了传统的架构和SOA 架构的不足，提出以云平台为底座基于微服务的层次化、服务化平台架构，阐述了平台架构的特征和集成方法；然后将综合应用平台的构建过程进行描述，并以不同类别软件的接入改造为例说明架构良好的适配性；最后对平台的应用部署、容器管理和服务中心功能进行验证，取得了良好的应用效果。

对军用软件系统，如指控系统、应用平台等需要将各种子系统集成并综合处理展示，传统的单体架构已经无法满足这种大型软件快速迭代、按需扩展的要求。引用[1]以分布式构件、DDS 数据分发技术对指控系统进行了设计，达到了一定程度的开放、通用[1]；引用[2]以面向服务的架构（SOA）为基础，解决了嵌入式软件技术体制各异接入困难等问题[2]。当前在民用领域方兴未艾的微服务理论已经取得了较好发展应用[3，4]，并在向下一代发展。而在军用软件领域，由于网络隔离和云设施投入大，研究和应用较为缓慢，使其微服务以易扩展和高可用的优点被广为接受。引用[5]基于舰载指控系统作战应用软件，提出了作战筹划系统微服务架构的实现技术途径[5]；引用[6]针对传统指挥控制系统存在的系统封闭等问题，采用了基于微服务为基础的云原生方法构建了开放式指控平台[6]。本文研究的数据链领域综合应用平台作为数据链方面的一个集管理、仿真、验证的大型系统，其架构关系到系统本身的生命力，本文对平台特点进行了阐述，并结合服务化主流技术分析研究，以构建开放可靠的综合应用平台。

1 数据链领域综合应用平台

数据链领域综合应用平台是将数据链领域中的顶层管理、体系规划、仿真模拟、技术验证、教学培训等类型应用软件进行集成，形成一个大而全的综合系统。设计这样的大型平台系统主要是为将数据和业务流程统一到一个系统上面来，各个用户登录同一个系统进行相关的数据获取或业务处理，从而免去了系统间需要通过非数字化的手段（报告、报表）来传递信息，使数据的生产和消费更加流畅，使需要各单位协作的业务流程更加便捷。但是由于平台系统下软件众多，类型多样，且是由多家厂商单位开发维护的，导致软件集成难度大，交互设计沟通多，具体表现在:（1）软件体制不一。有的软件是B/S 软件，有的是C/S 软件，有的是单体软件，有的是需要依赖特殊软硬件才能正常运行的应用；（2）部署平台各异。有的软件需要部署在Linux 系统，有的需要部署在Windows 系统，有的嵌入式软件需要运行在Vxworks 上等；（3）迭代需求不同。部分软件由于功能不明确，在开发部署过程中需要持续迭代，持续改进，有些软件基于稳定的业务和过程，基本不需要改动。

传统的开发集成方法是通过设计单体软件，将需要集成的各软件、数据、处理等都接入到这个大而全的中心软件中。这就需要对各软件进行深度的改造、适配，将技术体制、部署平台等都统一到中心软件上来，保证用户通过这个中心软件能够操作处理其他面向具体业务的软件。这种方法的缺点显而易见，需要对系统中各软件进行适配开发或者改造，不仅开发、沟通工作量大，而且软件间互相交连，单个软件的需求模糊进度落后可能导致多个软件的进度拖延。这些不足概括起来有以下几点:（1）新增业务困难。由于系统内模块众多，互相依赖复杂，当加入新业务时，极易对已有业务产生或多或少的影响；（2）系统可靠性下降。系统规模越庞大复杂，出故障的概率就越高；（3）协作效率降低。各软件间由于涉及复杂的接口和互相交叉的依赖关系，需要大量沟通协调的工作做支撑；（4）软件迭代受限。由于系统规定了各软件的架构或技术路线，当需要对软件进行技术升级时就会产生阻碍。

2 服务化架构

针对传统开发集成模式的问题，一个解决方案就是遵循SOA 规则，将应用进行纵向和横向的拆分，对应用系统进行服务化转型。其将应用程序的不同功能单元通过服务接口联系起来，接口采用中立方式定义，独立于实现服务的硬件、操作系统和语言，运行在不同系统中的服务可通过统一和通用的方式进行交互。

SOA 的关键技术有企业服务总线ESB、远程过程调用RPC、Web Service[7]。但是随着发展，逐渐发现SOA的缺点开始显现，主要有:ESB 承载了所有的服务消息通信，对于高并发、大系统，ESB 模块太“重”、维护成本大、服务间的组合方式不够灵活、扩展性不强等。虽然SOA 架构缺点明显，但是服务化的方向没有错，庞大系统如果不采用服务化架构，那将很快被淘汰。主要体现在:服务化提高了软件间的交互能力，减少了业务烟囱、数据孤岛，减小了算力浪费，更大程度地实现了信息的融合与共享；更加容易地对跨地域服务进行调用和集成；服务解耦，迭代快速；更易于知识产权的保护。因此，近年来，随着云计算、容器化的快速发展，新的服务化架构——微服务架构获得了更好的应用和反馈，其主要特点为:对系统的划分更加细粒度，共用的组件能够更好地得到重用和维护；减少了服务间的耦合，只需遵守约定的API；服务集成不受限于过时的或特有的架构；促进了软件的敏捷开发。因此本文采用微服务架构和相关技术对平台进行构建。

3 微服务化集成实践

3.1 整体架构设计

要构建基于微服务的灵活可靠、统一开放的数据链领域综合应用平台，首先要从底层构建硬件集群，在综合资源的基础上，向上构建虚拟容器集群及容器编排管理工具，最后构建业务应用服务和微服务治理相关工具，保证整个平台能够提供稳定可靠的服务。基础设施层将物理设备进行整合统一，形成整个平台的硬件资源池，对各个物理机上的计算能力、存储能力、网络能力和输入输出设备统一进行管理，并可以根据需要进行划分，从而支撑上部的各类业务应用。虚拟化层按照业务应用的需求将下部资源进行划分配置，构建虚拟化容器，将应用打包部署后形成服务容器，同时支持对容器的管理、编排等功能。业务服务层提供顶层管理、体系规划、仿真模拟、技术验证、教学培训等各类应用的服务入口，向上面向用户，向下链接到具体的微服务容器，容器间相互交连，完成业务功能。支持对各类容器服务进行整合管理，包括服务注册、发现等。各类用户通过服务入口进入平台，获取各项业务能力和数据资源，完成具体的任务目标。

3.2 云平台构建

云平台承担着合并底层资源、规范基础架构、连接业务要素、支撑上层应用等任务，是解决软件系统集成的关键，是实施一体化数据底盘、形成网络信息体系能力的重要支撑，在平台中发挥着“基座”的作用。本文采用基于国产化的软硬件环境构建云平台，其软硬件环境如表1 所示。

表1 软硬件环境Tab.1 Software and hardware environment

云平台按照虚拟化的粒度分为多种云，本文采用基于Docker+Kubernetes 的容器云。通过分布式集群资源管理的方式，将集群内各类资源进行统一管理、全局调度，支撑上层服务在容器云环境下的调度运行。部署完容器云后，即拥有了对基础资源进行容器虚拟化并进行管理的能力，包括监视物理服务器状态，集群CPU、内存、存储、网络占用，每个虚拟容器的状态等信息，基于镜像进行容器构建等。然后对微服务管理相关工具进行部署，主要包括配置目录、服务支撑后端、服务支撑前端、Center-check、K8swatch、Podinteractive 以及Rkts、Redis 等基础服务，以支撑复杂的服务调用关系，保证服务高可用，主要能力包括:（1）服务治理。包括服务注册、服务发现、服务注销。（2）服务调用。支撑服务间的远程调用，基于Http 的RESTful 接口和基于TCP 的RPC 协议。（3）服务网关。包括统一接入、安全防护、协议适配、流量管控、请求容错等能力。（4）服务熔断。保证单个微服务的拥塞或错误不会使整个服务链条产生崩溃。（5）链路追踪。支持对服务链路监控追踪，以进行排错调优。

微服务体系构建完成后，就可以对业务应用的服务容器进行打包、部署、编排、维护等。业务应用容器按照应用包+Docker 基础镜像进行打包，然后配置容器依赖的数据库与外部服务，配置容器参数，包括计算核心数量、内存大小、DFS 挂接点、服务副本数、存活探针地址、配置文件注入等，然后对容器进行启动测试，容器打包启动的Docker File 格式如下:

平台共性软件和业务应用软件按照上述步骤部署到云平台，完成各软件向平台的集成与构建，形成自下而上的基础设施、工具支撑到业务应用的整体架构，并具备开放、扩展、可靠的能力。

3.3 应用的微服务化接入和改造

数据链领域综合应用平台中包含新研软件和沿用软件，这些软件架构多样，并不都是云原生应用，而且部分软件包含定制化的硬件，因此应该分别考虑应用的微服务化接入和改造。（1）原生的B/S 应用。可直接将应用的各模块进行拆分，分别打包部署，编排服务，形成整体的业务能力。（2）C/S 应用。需要对客户端软件结合平台的服务中心API 进行改造，从而可以在客户端运行时能够动态获取服务端地址并进行交互，客户端通过服务中心进行更新。（3）单体应用。需要大量运行资源的应用进行C/S 或B/S 改造，将其拆分为客户端与服务端，客户端通过服务端获取资源或结果，从而减轻客户端的压力；不需要大量运行资源的，可直接改造后运行在终端机上，通过服务中心获取待交互服务的地址。（4）不适合容器化与需要硬件支撑的应用。直接作为非虚拟化的外部服务与平台进行集成，这些服务统一注册到服务中心，从而和其他服务相互感知，通过平台整体管理调用。（5）部分沿用的软件已对业务功能有较完整的包装和精炼，虽然按照微服务的思想需要进行模块拆分，但是由于其更新迭代的频率不高，模块复用几率小，因此可直接作为单个服务快速接入、快速集成。例如，部分软件需要采用DDS 进行消息通信，可直接将DDS 作为一个服务进行接入，从而减少消息总线改造的工作量和难度。

通过上述方式，将各种软件服务以较小改造成本、较大集成效率和较强交互能力接入到数据链领域综合应用平台中，形成了一个开放、可靠的以云平台为基础的复合系统，同时也形成了各单位在数据链领域进一步激发创新活力的众创平台。

4 结语

军用软件系统由于其自身特点，采用服务化架构的方式并未完全铺开，本文研究了将微服务架构引入数据链领域综合应用平台的集成方法，取得了良好的应用效果。通过研究与应用，证明微服务架构是实现兼容不同技术体制、软件架构和软硬件环境的重要手段之一，是对已有软件模块化、服务化的体系架构理论的进一步发展，能够最大限度地解放集成工作，让各服务专注于自身业务能力。其松散耦合的关系能让各服务更快速迭代需求变化，从而提升企业数字化能力，促进以用户为中心的转型。本文所提出的集成构建方法对于相关复杂系统有一定的参考意义。但是，军用系统对微服务的架构使用还很有限，其面向具体业务场景的适配问题还未完全挖掘；服务化架构仍在发展当中，基于边车模式的多语言易用和基础设施单独演进的服务网格架构[8]研究也在不断深入等。在后续的研究实践中，将对这些问题持续关注。