基于Docker的作战应用微服务化架构研究∗

（海军研究院 北京 100063）

1 引言

Docker容器是一种轻量级虚拟化技术［1～2］，自诞生以来获得高速发展，目前已经在云计算领域得到充分实践检验［3～4］。微服务架构系统基于Docker容器进行集成部署和运维，可以实现容器编排、服务自动弹性伸缩、自动修复、监控管理等功能，降低用户的运维成本和难度［5］。微服务架构的应用可以实现软件的松耦合、跨区域开发，传统的软件系统设计、开发、测试、部署与运维等各个环节，因为容器和微服务架构正在被逐步改变。目前已有众多研究人员开展相关研究。

文献［6］基于Docker容器技术开发了数据库微服务系统，系统具有快速，扩展性高等优势，为大数据处理提供了可靠的技术保障。文献［7］设计了基于Docker的计算机应用快速部署系统，该系统通过利用Docker响应速度快，资源消耗少的特点，实现了短时间内的弹性伸缩功能。文献［8］提出了一种基于Docker技术来搭建企业私有PaaS云平台的方案，该平台支持动态伸缩，在高效迁移部署方面有较好效果，能提升运维效率和资源利用率。

2 传统作战应用架构与微服务架构

传统的舰载指控系统作战应用基于“应用框架+应用构件”的设计模式，采用全分布式的体系结构设计［9］。应用构件包括显控构件、计算服务构件、接口适配构件等，各个业务模块由独立的功能构件实现，构件间使用DDS（Data Distribution Service）数据分发服务进行通信。应用构件依赖开放式的应用框架运行，框架屏蔽了底层操作系统差异，并对构件的生命周期进行管理。

这种设计模式对系统软件解耦，集中监控管理起到一定促进作用，但仍存在一些不足：

1）由于对应用的划分粒度较大，单个构件功能复杂，集成效率较低，特别对于新研的系统集成困难，不利于系统敏捷开发和部署；

2）受限于物理机或虚拟机的环境，难以实现资源的灵活弹性伸缩；

3）系统缺乏有效的运维管理工具，对各个构件的运行状态监控不足，构件不具备自修复、自扩容能力。

近年来开展微服务架构研究的人越来越多，微服务架构为敏捷开发和部署提供了巨大的帮助。微服务是一些小而自治、协同工作的服务，具有独立部署、复杂度可控、技术选型灵活和高扩展性的优点［10］。通过对应用进行细粒度的划分，每一个微服务只专注于单一功能，单个业务可拆分为多个独立开发，软件开发效率得以提高，缩短了应用交付周期。同时，微服务之间边界表述清晰，去除中心化，服务变更升级对系统整体影响较小，降低了系统升级风险。由于技术选型灵活，各个服务的开发人员可以自由选择合适的技术栈，避免了技术栈升级对系统整体的影响。图1是微服务架构体系图，包括云平台、容器、服务、接入、应用共五层。

图1 微服务架构体系图

1）云平台层处于架构最底层，用于提供基础硬件资源或虚拟化资源，主要包括计算、存储和网络等资源。

2）容器层位于云平台之上，为微服务提供轻量级虚拟化后的运行环境，容器是系统管理的基本单元，容器层对容器集群提供监控、资源调度、弹性伸缩、容器编排等功能，镜像仓库用于镜像存储。

3）服务层由各类微服务组成，例如服务注册、发现，目标分析服务、情报管理服务等。

4）接入层负责接入外部应用的服务请求，提供系统负载均衡，网关等。

5）应用层位于架构最顶层，是实际的业务应用。

传统作战应用架构与微服务架构在诸多方面存在差异：

在系统开发阶段，构件化与微服务化对系统的划分粒度不一致，微服务对系统的划分更加细粒度。微服务架构使得开发人员只需要专注于自己负责的某个服务，只要服务遵守约定的API即可。开发人员也可以不受限于使用过时的技术开发新的项目。微服务架构促进了软件的敏捷开发。

在系统部署阶段，传统架构依赖人工部署，运维人员需要针对不同应用对生产环境进行配置，部署效率较低。当软件发生升级变更后，需要经过重新部署、修改环境配置、进行生产环境测试等步骤，导致软件升级效率较低。微服务架构采用Docker容器技术，以镜像的方式进行部署，应用软件及其依赖环境被打包为镜像，运维人员不需要再根据应用调整环境配置。各类软件变更在测试完成后即可通过灰度部署等方式部署到生产环境，可支持升级过程中业务不中断。微服务架构让持续部署更易于实现。

在系统运维阶段，传统架构系统中只具备对各个构件的监控能力以及生命周期管理能力，缺乏其他有效的运维手段。在微服务架构中，可基于容器集群管理工具对系统进行运维，支持容器集群调度、编排，服务级的负载均衡，服务资源自动弹性伸缩，服务异常自恢复等功能。此外，微服务架构在运行控制中存在熔断、限流、降级等机制，保证系统中单一服务出现异常时，系统整体资源不被异常占用，保护核心业务的资源使用量。微服务架构使得系统运维能力得到加强，降低了系统运维难度，大大提高了系统的稳定性、可靠性及抗压能力。

3 作战筹划微服务架构

3.1 作战筹划系统分解

作战筹划是对作战活动的预先设计和总体筹划，是指挥员及其指挥机关对作战行动进行的运筹和谋划，是在综合分析判断情况的基础上，对作战目的、作战方针、作战部署、作战时间、战法等重大问题进行创造性思维，进而形成作战基本构想的过程。

作战筹划任务参与方主要由指挥员，作战、情报、通信等各域军官组成。指挥员领受上级命令后，综合分析战场情况，下达作战命令，各级军官根据作战命令拟定作战技术，生成作战方案后上报指挥员审批，继续上报。基于以上流程，可对系统进行划分，设计以下几类微服务：

1）服务注册中心：实现微服务注册中心；

2）监控面板：实现微服务的可视化监控；

3）系统入口：作为系统起始入口；

4）作战计划制定管理服务：负责管理当前任务的敌方目标、我方目标、集结点和展开点等；

5）武器及传感器管理服务：负责管理当前我方参与兵力的设备列表和武器列表；

6）作战力量全集管理服务：管理我方作战力量列表和敌方作战力量列表；

7）作战力量信息管理服务：管理位置信息、部队类型、设备类型、武器类型、任务类型、任务状态等；

8）作战任务管理服务：管理任务列表。

其中1）为微服务注册中心，2）为监控界面，与业务功能不相关，3）至8）为业务相关服务。图2展示了业务相关服务间的关系。

图2 作战筹划微服务关系图

3.2 微服务部署

3.2.1 容器集群框架

Docker可以实现微服务的容器化封装和应用隔离，容器的启动和关闭速度远远快于虚拟机［11］，同时不增加额外的资源消耗［12～13］。目前作战筹划微服务系统由三台服务器组成，均采用中标麒麟服务器版5操作系统，基于此搭建了跨节点的Docker容器集群，容器作为微服务的运行载体。

容器集群搭建采用了多种技术，服务发现存储工具etcd实现服务自注册，网络工具flannel简化容器集群中的网络环境，实现覆盖网络，镜像库registry集中存放镜像，便于镜像管理与容器调度，由可视化工具dashboard提供web界面，便于运维人员监控与管理容器集群。容器集群工具kubernetes对容器集群进行调度，其中集成metrics server实现集群中容器组的自动弹性伸缩，容器集群框架如图3所示。

图3 容器集群架构图

3.2.2 容器化封装

Docker镜像是容器技术的核心组件之一，使用Dockerfile文件可以将微服务及其依赖环境封装为镜像，存入镜像仓库中。下面截取了构建微服务镜像时的Dockerfile文件中的部分内容。

其中描述了需要向镜像中添加的文件，设置了环境变量和容器启动入口等。镜像构建完成后，即可通过Docker push指令推送到镜像仓库registry中。

3.3 系统验证

3.3.1 异常自恢复功能验证

由于kubernetes副本控制器的存在，集群中每个微服务的副本数量会保持为设定的值，当某一个微服务容器组发生异常而停止，副本控制器会自动启动同一个微服务容器组，使副本数量保持与设定值一致，保障了微服务的异常恢复功能，如图4所示。

图4 异常自恢复功能验证

微服务task-service容器组设置副本数为2，两个容器组分别在节点1和节点2上运行。断开节点1网络连接，模拟节点1异常情况，副本控制器无法监测节点1上的容器组，task-service-flj5m容器组被置灰，随即在节点2上启动相同服务容器组，保证副本数量满足要求，实现系统异常自恢复。

3.3.2 伸缩性验证

对于设置了HPA的服务，当微服务容器的资源消耗达到阈值，会触发自动弹性伸缩，增多微服务容器副本数来应对突然增加的负载。

在系统验证过程中，通过yaml文件创建hpa，设置task-service微服务部署的最大最小副本数，以及hpa对应的CPU和内存指标，然后使用busybox进行负载模拟。如图5所示，在负载增加后，task-service容器组开始扩展，表明服务具备弹性伸缩能力。

4 结语

基于Docker容器的微服务架构在敏捷迭代开发、资源消耗、系统可靠性等方面具有优良的性能，针对传统作战应用系统面临的问题，本文对Docker容器技术和微服务架构开展研究，设计了作战筹划系统微服务架构，并采用Docker容器进行系统部署，该架构支持微服务独立开发，提高了开发效率，同时通过容器集群工具降低系统运维难度，提升系统可靠性。