CN112000448B - 基于微服务架构的应用管理方法 - Google Patents

Abstract

本发明公开了基于微服务架构的应用管理方法，包括面向战术应用的微服务技术架构设计、轻量化的微服务运行支撑环境构建、面向战术环境的微服务可靠管理技术和信息服务全过程动态运维。本发明引入前沿的微服务架构用于应用管理，将战术级业务系统拆分成松耦合、更细粒度的服务单元，基于微服务框架的应用系统部署模式，具有易于开发和维护、启动较快、局部修改容易部署、按需伸缩部署等优点，实现基于微服务的应用系统支撑环境构建，满足战术环境的轻量化、快速部署的军事应用要求，同时，项目针对战场环境对微服务的可靠管理进行研究，通过高可用管理、负载均衡、服务容错、调用追踪等优化技术，实现可靠性更高的应用运维管理。

Description

基于微服务架构的应用管理方法

技术领域

本发明涉及云计算领域，具体来说，涉及基于微服务架构的应用管理方法。

背景技术

陆军现役信息系统应用管理模式下，应用软件大多是各种独立应用的堆砌，扩展性差、可靠性不高，维护成本高。随着系统功能复杂度的提高和规模的扩大，单体架构暴露出越来越多的问题，部署速度变慢、无法按需伸缩等。在陆军机动战术云环境下，对应用系统的高可用性和可维护性要求更高，应用的单体部署越来越难以满足战场环境对应用的轻量级、高动态、高可靠要求。

针对相关技术中的问题，目前尚未提出有效的解决方案。

发明内容

本发明的目的在于提供基于微服务架构的应用管理方法，以解决上述背景技术中提出的问题。

为实现上述目的，本发明提供如下技术方案：基于微服务架构的应用管理方法，包括面向战术应用的微服务技术架构设计：包括面向战术应用的微服务技术架构设计、轻量化的微服务运行支撑环境构建、面向战术环境的微服务可靠管理技术和信息服务全过程动态运维，具体如下：

面向战术应用的微服务技术架构设计：包括超融合资源层、微服务环境支撑层、微服务管理调度层、战术级业务服务层和接入层，超融合资源层指底层构建微服务的车载硬件平台和虚拟化资源池，是提供微服务环境的物理支撑，虚拟化资源池包括计算资源池、存储资源池、网络资源池，微服务支撑环境层构建了微服务框架的运行时系统，是支撑微服务运行的框架，包括消息总线、微服务网关、微服务注册发现、认证授权支撑组件，并由配置中心进行集中管理，微服务管理调度层用于构建支持恶劣战场环境下的高可靠微服务集群，具体包括微服务高可用、微服务熔断、微服务负载均衡、微服务调用追踪、微服务部署管理、微服务监控告警、微服务后台服务管理，业务服务层提供了基于微服务框架的丰富战术级应用，应用以微服务解耦模式部署，通过数据库服务、认证服务多单元基础服务的聚合，形成对外提供完整服务的战术级应用业务系统，接入层是用户访问微服务应用的接口层，接入层部署了负载均衡和接入网关组件；

轻量化的微服务运行支撑环境构建：在微服务技术架构基础上，基于SpringCloud构建轻量级微服务运行时支撑环境，包括微服务消息总线、微服务网关代理、微服务注册与发现和微服务认证授权，由微服务配置中心进行统一管控，服务消息总线通过建立多个应用之间的通信频道，管理和传播应用间的消息，实现多个微服务之间的同步配置和更新，微服务网关代理实现代理和过滤功能，消息总线和网关实现应用之间的关系解耦，微服务注册与发现实现微服务的动态构建，微服务认证授权提供用户访问微服务的统一认证接口，构建适应于机动战术云的微服务系统，各运行时组件配置和流程说明如下：

1接入访问请求统一通过API网关代理来访问内部服务；

2网关接收到请求后，从注册中心获取可用服务；

3获取可用服务，分发到后端具体实例；

4微服务之间通过消息总线进行通信处理业务；

5统一认证和访问控制作为微服务重要模块，也以微服务的形式部署；

面向战术环境的微服务可靠管理技术：面向陆军战术环境服务可靠管理的需求，在微服务运行支撑环境之上，研究战场环境下的微服务可靠管理技术，具体包括微服务高可用、微服务熔断、微服务负载均衡、微服务调用追踪，从而在机动性强、实时性高的陆军机动作战环境下，提升应用服务的快速响应、稳定可靠运行的能力，微服务高可用管理，通过配置多服务注册中心副本、服务自愈、服务缓存实现战术应用的高可用，面向微服务容错保护的服务熔断，设计面向微服务的容错保护服务，用户隔离访问远程服务，防止级联失败，实现断路器、线程隔离、信号隔离容错功能，能够在一个、或多个依赖同时出现问题时保证系统依然可用，防止雪崩效应，面向微服务的客户端负载均衡，感知弹性伸缩发生后后端实例的状态变化，并将最新的后端信息更新至负载均衡器，进而实现应用服务的弹性负载均衡，微服务调用链追踪技术，构建针对微服务全生命周期的监控，增强微服务的运维管理和性能优化能力，具体如下：

1网关从注册中心获取服务后，通过客户端负载均衡，分发到后端具体实例，从而保障战场资源的运行效率；

2访问的微服务网关、微服务实例多副本部署，具有高可用；同时还具有访问缓存、自愈功能保障故障时的临时访问；

3战场环境下出现微服务故障时，由网关代理执行容错保护，以服务降级响应形式返回客户端；

4用户的微服务访问路径、微服务之间的消息总线通信，设置监控和追踪组件，实现微服务调用链的追踪；

信息服务全过程动态运维：包括应用业务逻辑感知的快速系统开设机制、基于微服务视图的轻量化数据加载技术、基于多服务实例同步的信息共享机制和战场环境感知的微服务链动态重组技术，具体如下：

应用业务逻辑感知的快速系统开设机制：对应用进行解构，明晰其业务组件：微服务，通过对业务逻辑、组件架构及功能差异的分析，明确其微服务构成，对于微服务的执行，以一个或多个虚拟机或容器的形式来完成其功能，并满足一定的业务需求即应用的负载，此外，也据此分析出应用的总体资源需求和数据依赖，基于应用的微服务化过程，明确系统开设所需要的基本微服务，结合各微服务实例的分布情况，自动实现微服务链的推荐、选取，从而完成系统开设，微服务链的选择过程包括：微服务实例的描述、应用微服务链生成、微服务链的评估与确定，微服务实例描述：定义s＝(pos,ra,o,e)为单个微服务实例，采用4个属性进行描述；其中，pos表示该服务实例所在的位置，包括云、端设备；ra表示该服务实例的输出输入数据比，即ra＝amountoutput/amountinput，表明该微服务产生的数据传输时延开销；o表示该服务实例处理单位数据所花费的时间；e表示该服务的有效性(0/1)，即是否可用，此外，用mEN(s)表示微服务实例s所在的节点所能具有的微服务实例数量上限，pEN(s)表示微服务实例s所在的节点当前具有的服务数量，应用微服务链生成；令SG＝<S,E,s0>表示生成的微服务链，s0表示微服务链的源节点，即发起应用请求的位置，当s0调用该应用服务时，将根据此组合服务的某条组件功能链，记为P，生成相应的SG，S表示P中涉及的功能组件的所有服务实例构成的集合；E表示S中微服务实例之间有向边的集合；

基于微服务视图的轻量化数据加载技术：微服务架构下，每个微服务根据自己的业务特征，自由选择适用的数据库，而无需采用完全一致的数据库；时序数据库对于实时数据的预处理更加有效，因此，每个微服务根据业务的功能和非功能性需求，生成独立的微服务视图，并据此从综合数据存储中加载所需的数据，从而完成数据加载过程，微服务根据自己的需要生成数据加载规则，微服务加载过程包含的主要流程有系统启动流程、全量数据加载流程和增量数据加载流程，系统启动流程就是各微服务的启动，启动顺序应该是首先启动数据库读取组件，然后启动域内控制器，最后在需要加载数据时启动数据加载服务器，系统启动时微服务数据库读取组件通过配置文件，首先建立与数据库之间的连接，域内控制器启动后连接微服务数据库读取组件，获取微服务数据库基本信息：数据表名、数据列名、数据规模，域内控制器将数据库基本信息提供给客户端；根据微服务数据库基本信息，生成加载规则：需要加载数据表名、数据列名，将加载规则发送给域内控制器，域内控制器将加载规则分发给各微服务；每个微服务的数据库读取任务，分别批量加载数据并上传读取结果；

基于多服务实例同步的信息共享机制：信息共享是战场环境下的重要应用服务，微服务架构下，信息的逻辑载体为微服务实例，而其物理载体为虚拟机或容器，由于各微服务实例基于自身业务特征选用了不用的数据库；因此，跨库的数据共享会带来较大的数据模式转换开销，据此，拟采用基于信息目录的机制完成数据共享过程，为实现对多个微服务实例间的高效共享，满足对战场实时变化的需求，建立微服务信息目录收集、存储、链接关联多个微服务，实现各类微服务能够按需提供和访问各类数据，在信息目录中快速搜索和管理微服务资源，并通过订阅微服务主题，实现微服务资源的按需主动推送，达到对微服务资源的高效共享，其次，是需要实现微服务的状态监控，在多个微服务工作的各个阶段，采用具体的监控进程：Linux系统脚本和开发的监听工具，进行作业，使各阶段的服务依序启动、依序监听、依序关闭，严格处理好各应用服务之间的依赖关系，当服务开启时自动按顺序启动底层服务和应用进程，为了做到多服务的自维护与管理，添加了服务监听进程，定期检测各个服务的运行状态以及系统维护信号，当检测到某个服务意外关闭时便发通知给管理员并尝试重新启动该服务，当检测到服务需要关闭或重启时，在关机/重启前，安全关闭相关进程与服务，确保系统数据的完整性，为了实现自动待机，管理多服务互关联的管理问题，需要解决如何自启动数据库并成功挂载；如何安全关闭数据库；如何自启动及安全关闭统一认证服务；如何实现服务启动与关闭的依序进行；如何实现服务监听进程并定期自检，在传统微服务链的组合模式，通常多个微服务，各自独立执行服务任务，多微服务之间不存在服务链的动态共享机制，而系统监控只对各自独立的微服务进行配置管理；为了适应微服务资源动态重组需求，建立虚拟微服务监控管理池，集中监控管理所有微服务活动状态把以单个微服务为对象的资源调配模式扩大为以全局服务链为对象的服务链动态重组模式，自动对虚拟微服务资源池内的多个微服务进行调控，完成服务链重组、参数配置和自动化运行工作；

战场环境感知的微服务链动态重组技术：随着战场环境和网络拓扑条件的快速变化，原有微服务链的执行会由于通信失效、端节点失效原因无法高效完成应用；因此，有必要针对战场动态环境信息，进行微服务链服务质量监控并进行主动的微服务链动态重组，保障应用的服务质量，基于微服务的应用有多种微服务链实现方式，但是多数微服务所需的网络功能之间都存在依赖关系，防火墙要部署在微服务链的入口和出口处，从而保证微服务的安全要求，因此我们假设在微服务到达后，经过业务编排器分析得到的微服务链是固定的，接下来只需要通过对设计好的微服务链进行资源动态重组，假设底层网络中有N个虚拟机，对微服务器上部署的实例的类型进行存储、计算物理资源的调整，大大提高这些物理资源的利用效率，减少资源浪费；资源动态重组问题本质上是一个优化问题，为微服务链进行实例资源调度的目的是提高资源利用率，同时不对微服务完成时间产生较大的影响，因此将微服务完成时间和稳定性共同作为优化目标，而其中微服务完成时间是最重要的优化目标。

进一步的，所述微服务消息总线是一个消息中心，众多微服务实例连接到微服务消息总线上，实例通过监听的方式往消息中心发送或接收信息，微服务网关代理为在客户端和服务端之间增加一个API网关，所有的外部请求先通过这个微服务网关，它只需跟网关进行交互，而由网关进行各个微服务的调用；

微服务注册与发现包括服务治理中心Eureka、服务注册、服务发现，Eureka包含两个组件：EurekaServer和EurekaClient，EurekaServer提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息在界面中直观的看到，EurekaClient是一个Java客户端，用于简化与EurekaServer的交互，客户端同时也具备一个内置的、使用轮询负载算法的负载均衡器，服务注册指的是在服务治理框架中，通常都会构建一个注册中心，每个服务单元向注册中心登记自己提供的服务，将主机与端口号、版本号、通信协议一些附加信息告知注册中心，注册中心按照服务名分类组织服务清单，服务注册中心还需要以心跳的方式去监控清单中的服务是否可用，若不可用需要从服务清单中剔除，服务发现包括提供者服务发现和消费者服务发现；

微服务认证授权：在使用SpringCloud体系来构建微服务的过程中，用户请求是通过网关：ZUUL或SpringAPI网关，以HTTP协议来传输信息，API网关将自己注册为Eureka服务治理下的应用，同时也从Eureka服务中获取所有其他微服务的实例信息，搭建微服务认证授权服务，并不是给每个微服务调用，而是通过API网关进行统一调用来对网关后的微服务做前置过滤，所有的请求都必须先通过API网关，API网关在进行路由转发之前对该请求进行前置校验，实现对微服务系统中的其他的服务接口的安全与权限校验。

进一步的，所述提供者服务发现指的是在服务提供者和服务消费者之间有一个独立的负载均衡器，负载均衡器上有所有服务的地址映射表，当服务消费者调用某个目标服务时,向负载均衡器发送请求,负载均衡器根据策略做负载均衡后将请求转发到目标服务，消费者服务发现指的是服务消费者要访问某个服务时，通过内置的负载均衡组件向服务注册表查询目标服务地址列表，然后以某种负载均衡策略选择一个目标服务地址，最后向目标服务发起请求，这一方案需要一个服务注册表配合服务注册和发现，采用高可用、分布式一致的组件Zookeeper、Consul、Etcd来实现。

进一步的，所述微服务高可用包括多副本部署、变更管理、微服务自愈和失效缓存，具体如下：

多副本部署：服务注册中心EurekaServer是微服务系统的核心组件，单点部署显然这并不适合应用于线上生产环境，通过运行多个实例，并进行互相注册的方式来实现高可用的部署，所以我们只需要将Eureke Server配置其他可用的serviceUrl就能实现高可用部署，但是实际上因负载原因，往往需要在生产环境构建多于两个的EurekaServer节点，EurekaServer的同步遵循着一个非常简单的原则：只要有一条边将节点连接，就进行信息传播与同步，因此，只要部署3个注册中心，两两注册的方式实现集群中节点完全对等的效果，实现最高可用性集群，任何一台注册中心故障都不会影响服务的注册与发现；

变更管理：在微服务架构里，服务之间是相互依赖的，所以要最小化出现故障的几率，限制故障所造成的负面影响，在部署新应用时，或者在对配置做出变更时，要先在一小部分服务实例上进行，然后监控它们，一旦发现关键性度量指标出现异常，马上自动回滚；

微服务自愈：自愈能力能够让应用在发生故障时进行自我恢复，通过部署应用容器实例运行监控组件，实施心跳检测来确定服务的可用性，并在服务故障时，进行微服务实例多副本同步，并在其它服务器上重建改服务，实现微服务自愈。

进一步的，所述微服务负载均衡指的是通过硬件或软件实现负载均衡均会维护一个服务端清单，利用心跳检测手段进行清单维护，保证清单中都是正常访问的服务节点；当用户发送请求时，会先到达负载均衡器，负载均衡器根据负载均衡算法：轮训、随机、加权轮训，从可用的服务端列表中取出一台服务端的地址，接着进行转发，降低系统的压力，基于开源SpringCloudRibbon构建面向微服务的客户端负载均衡工具，它将面向服务的REST模板请求自动转换成客户端负载均衡的服务调用。

进一步的，所述微服务熔断指的是为了防止“雪崩效应”，必须提供一个容错机制，当调用延迟超过一定时间时，采取一定措施处理，而不是让其一直处于等待状态，简单来说，该机制实现关键点如下：

1为网络请求设置超时时间：主要是防止因服务故障或网络延迟导致请求堆积，占用服务器资源；

2使用断路器模式：当调用出错或者超时，服务将此请求标记为失败，给调用方返回信息提示，即调用失败处理方法，基于SpringCloudHystrix设计面向微服务的容错保护服务，用户隔离访问远程服务，防止级联失败，它实现了断路器、线程隔离、信号隔离容错功能，能够在一个、或多个依赖同时出现问题时保证系统可用。

进一步的，所述微服务调用追踪指的是一个完整的微服务系统包含多个微服务单元，各个微服务子系统存在互相调用的情况，形成一个调用链，战场环境下的移动终端应用访问请求、跨云数据协同请求，从发出到被指挥车单元响应经历了哪些组件、哪些微服务、请求总时长、每个组件所花时长信息有必要了解和收集，一方面能帮助定位性能瓶颈、进行性能调优，另一方面针对战场环境下的应用进行追踪和高可用优化，因此监控整个微服务架构的调用链十分有必要，基于Zipkin开发分布式的追踪系统，帮助收集微服务架构中用于解决延时问题的时序数据，它通过创造一些追踪标识符tracingId，spanId，parentId，最终将一个request的流程树构建出来，各业务系统在彼此调用时，将特定的跟踪消息传递至Zipkin，Zipkin在收集到跟踪信息后将其聚合处理、存储、展示。

与现有技术相比，本发明具有以下有益效果：本发明引入前沿的微服务架构用于应用管理，将战术级业务系统拆分成松耦合、更细粒度的服务单元。基于微服务框架的应用系统部署模式，具有易于开发和维护、启动较快、局部修改容易部署、按需伸缩部署等优点，实现基于微服务的应用系统支撑环境构建，满足战术环境的轻量化、快速部署的军事应用要求。同时，项目针对战场环境对微服务的可靠管理进行研究，通过高可用管理、负载均衡、服务容错、调用追踪等优化技术，实现可靠性更高的应用运维管理。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是根据本发明实施例的基于微服务架构的应用管理方法的微服务运行时框架结构示意图。

图2是根据本发明实施例的基于微服务架构的应用管理方法的微服务技术框架图。

图3是根据本发明实施例的基于微服务架构的应用管理方法的网关代理示意图。

图4是根据本发明实施例的基于微服务架构的应用管理方法的Eureka服务治理示意图。

图5是根据本发明实施例的基于微服务架构的应用管理方法的消费者服务发现示意图。

图6是根据本发明实施例的微服务可靠管理技术关系图。

图7是根据本发明实施例的失效缓存示意图。

图8是根据本发明实施例的Ribbon负载均衡示意图。

图9是根据本发明实施例的Zipkin的设计架构示意图。

图10是根据本发明实施例的信息服务全过程动态运维技术途径示意图。

图11是根据本发明实施例的应用的微服务化示意图。

图12是根据本发明实施例的数据库读取组件数据示意图。

具体实施方式

下面，结合附图以及具体实施方式，对发明做出进一步的描述：

请参阅图1-12，根据本发明实施例的基于微服务架构的应用管理方法,包括面向战术应用的微服务技术架构设计、轻量化的微服务运行支撑环境构建、面向战术环境的微服务可靠管理技术和信息服务全过程动态运维，具体如下：

面向战术应用的微服务技术架构设计：包括超融合资源层、微服务环境支撑层、微服务管理调度层、战术级业务服务层和接入层，超融合资源层指底层构建微服务的车载硬件平台和虚拟化资源池，是提供微服务环境的物理支撑，虚拟化资源池包括计算资源池、存储资源池、网络资源池，微服务支撑环境层构建了微服务框架的运行时系统，是支撑微服务运行的框架，包括消息总线、微服务网关、微服务注册发现、认证授权支撑组件，并由配置中心进行集中管理，微服务管理调度层用于构建支持恶劣战场环境下的高可靠微服务集群，具体包括微服务高可用、微服务熔断、微服务负载均衡、微服务调用追踪、微服务部署管理、微服务监控告警、微服务后台服务管理，业务服务层提供了基于微服务框架的丰富战术级应用，应用以微服务解耦模式部署，通过数据库服务、认证服务多单元基础服务的聚合，形成对外提供完整服务的战术级应用业务系统，接入层是用户访问微服务应用的接口层，接入层部署了负载均衡和接入网关组件；

轻量化的微服务运行支撑环境构建：在微服务技术架构基础上，基于SpringCloud构建轻量级微服务运行时支撑环境，包括微服务消息总线、微服务网关代理、微服务注册与发现和微服务认证授权，由微服务配置中心进行统一管控，服务消息总线通过建立多个应用之间的通信频道，管理和传播应用间的消息，实现多个微服务之间的同步配置和更新，微服务网关代理实现代理和过滤功能，消息总线和网关实现应用之间的关系解耦，微服务注册与发现实现微服务的动态构建，微服务认证授权提供用户访问微服务的统一认证接口，构建适应于机动战术云的微服务系统，各运行时组件配置和流程说明如下：

1接入访问请求统一通过API网关代理来访问内部服务；

2网关接收到请求后，从注册中心获取可用服务；

3获取可用服务，分发到后端具体实例；

4微服务之间通过消息总线进行通信处理业务；

5统一认证和访问控制作为微服务重要模块，也以微服务的形式部署；

面向战术环境的微服务可靠管理技术：面向陆军战术环境服务可靠管理的需求，在微服务运行支撑环境之上，研究战场环境下的微服务可靠管理技术，具体包括微服务高可用、微服务熔断、微服务负载均衡、微服务调用追踪，从而在机动性强、实时性高的陆军机动作战环境下，提升应用服务的快速响应、稳定可靠运行的能力，微服务高可用管理，通过配置多服务注册中心副本、服务自愈、服务缓存实现战术应用的高可用，面向微服务容错保护的服务熔断，设计面向微服务的容错保护服务，用户隔离访问远程服务，防止级联失败，实现断路器、线程隔离、信号隔离容错功能，能够在一个、或多个依赖同时出现问题时保证系统依然可用，防止雪崩效应，面向微服务的客户端负载均衡，感知弹性伸缩发生后后端实例的状态变化，并将最新的后端信息更新至负载均衡器，进而实现应用服务的弹性负载均衡，微服务调用链追踪技术，构建针对微服务全生命周期的监控，增强微服务的运维管理和性能优化能力，具体如下：

1网关从注册中心获取服务后，通过客户端负载均衡，分发到后端具体实例，从而保障战场资源的运行效率；

2访问的微服务网关、微服务实例多副本部署，具有高可用；同时还具有访问缓存、自愈功能保障故障时的临时访问；

3战场环境下出现微服务故障时，由网关代理执行容错保护，以服务降级响应形式返回客户端；

4用户的微服务访问路径、微服务之间的消息总线通信，设置监控和追踪组件，实现微服务调用链的追踪；

信息服务全过程动态运维：包括应用业务逻辑感知的快速系统开设机制、基于微服务视图的轻量化数据加载技术、基于多服务实例同步的信息共享机制和战场环境感知的微服务链动态重组技术，具体如下：

应用业务逻辑感知的快速系统开设机制：对应用进行解构，明晰其业务组件：微服务，通过对业务逻辑、组件架构及功能差异的分析，明确其微服务构成，对于微服务的执行，以一个或多个虚拟机或容器的形式来完成其功能，并满足一定的业务需求即应用的负载，此外，也据此分析出应用的总体资源需求和数据依赖，基于应用的微服务化过程，明确系统开设所需要的基本微服务，结合各微服务实例的分布情况，自动实现微服务链的推荐、选取，从而完成系统开设，微服务链的选择过程包括：微服务实例的描述、应用微服务链生成、微服务链的评估与确定，微服务实例描述：定义s＝(pos,ra,o,e)为单个微服务实例，采用4个属性进行描述；其中，pos表示该服务实例所在的位置，包括云、端设备；ra表示该服务实例的输出输入数据比，即ra＝amountoutput/amountinput，表明该微服务产生的数据传输时延开销；o表示该服务实例处理单位数据所花费的时间；“e表示该服务的有效性(0/1)，即是否可用”，此外，用mEN(s)表示微服务实例s所在的节点所能具有的微服务实例数量上限，pEN(s)表示微服务实例s所在的节点当前具有的服务数量，应用微服务链生成；令SG＝<S,E,s0>表示生成的微服务链，s0表示微服务链的源节点，即发起应用请求的位置，当s0调用该应用服务时，将根据此组合服务的某条组件功能链，记为P，生成相应的SG，S表示P中涉及的功能组件的所有服务实例构成的集合；E表示S中微服务实例之间有向边的集合；

基于微服务视图的轻量化数据加载技术：微服务架构下，每个微服务根据自己的业务特征，自由选择适用的数据库，而无需采用完全一致的数据库；时序数据库对于实时数据的预处理更加有效，因此，每个微服务根据业务的功能和非功能性需求，生成独立的微服务视图，并据此从综合数据存储中加载所需的数据，从而完成数据加载过程，微服务根据自己的需要生成数据加载规则，微服务加载过程包含的主要流程有系统启动流程、全量数据加载流程和增量数据加载流程，系统启动流程就是各微服务的启动，启动顺序应该是首先启动数据库读取组件，然后启动域内控制器，最后在需要加载数据时启动数据加载服务器，系统启动时微服务数据库读取组件通过配置文件，首先建立与数据库之间的连接，域内控制器启动后连接微服务数据库读取组件，获取微服务数据库基本信息：数据表名、数据列名、数据规模，域内控制器将数据库基本信息提供给客户端；根据微服务数据库基本信息，生成加载规则：需要加载数据表名、数据列名，将加载规则发送给域内控制器，域内控制器将加载规则分发给各微服务；每个微服务的数据库读取任务，分别批量加载数据并上传读取结果；

基于多服务实例同步的信息共享机制：信息共享是战场环境下的重要应用服务，微服务架构下，信息的逻辑载体为微服务实例，而其物理载体为虚拟机或容器，由于各微服务实例基于自身业务特征选用了不用的数据库；因此，跨库的数据共享会带来较大的数据模式转换开销，据此，拟采用基于信息目录的机制完成数据共享过程，为实现对多个微服务实例间的高效共享，满足对战场实时变化的需求，建立微服务信息目录收集、存储、链接关联多个微服务，实现各类微服务能够按需提供和访问各类数据，在信息目录中快速搜索和管理微服务资源，并通过订阅微服务主题，实现微服务资源的按需主动推送，达到对微服务资源的高效共享，其次，是需要实现微服务的状态监控，在多个微服务工作的各个阶段，采用具体的监控进程：Linux系统脚本和开发的监听工具，进行作业，使各阶段的服务依序启动、依序监听、依序关闭，严格处理好各应用服务之间的依赖关系，当服务开启时自动按顺序启动底层服务和应用进程，为了做到多服务的自维护与管理，添加了服务监听进程，定期检测各个服务的运行状态以及系统维护信号，当检测到某个服务意外关闭时便发通知给管理员并尝试重新启动该服务，当检测到服务需要关闭或重启时，在关机/重启前，安全关闭相关进程与服务，确保系统数据的完整性，为了实现自动待机，管理多服务互关联的管理问题，需要解决如何自启动数据库并成功挂载；如何安全关闭数据库；如何自启动及安全关闭统一认证服务；如何实现服务启动与关闭的依序进行；如何实现服务监听进程并定期自检，在传统微服务链的组合模式，通常多个微服务，各自独立执行服务任务，多微服务之间不存在服务链的动态共享机制，而系统监控只对各自独立的微服务进行配置管理；为了适应微服务资源动态重组需求，建立虚拟微服务监控管理池，集中监控管理所有微服务活动状态把以单个微服务为对象的资源调配模式扩大为以全局服务链为对象的服务链动态重组模式，自动对虚拟微服务资源池内的多个微服务进行调控，完成服务链重组、参数配置和自动化运行工作；

战场环境感知的微服务链动态重组技术：随着战场环境和网络拓扑条件的快速变化，原有微服务链的执行会由于通信失效、端节点失效原因无法高效完成应用；因此，有必要针对战场动态环境信息，进行微服务链服务质量监控并进行主动的微服务链动态重组，保障应用的服务质量，基于微服务的应用有多种微服务链实现方式，但是多数微服务所需的网络功能之间都存在依赖关系，防火墙要部署在微服务链的入口和出口处，从而保证微服务的安全要求，因此我们假设在微服务到达后，经过业务编排器分析得到的微服务链是固定的，接下来只需要通过对设计好的微服务链进行资源动态重组，假设底层网络中有N个虚拟机，对微服务器上部署的实例的类型进行存储、计算物理资源的调整，大大提高这些物理资源的利用效率，减少资源浪费；资源动态重组问题本质上是一个优化问题，为微服务链进行实例资源调度的目的是提高资源利用率，同时不对微服务完成时间产生较大的影响，因此将微服务完成时间和稳定性共同作为优化目标，而其中微服务完成时间是最重要的优化目标。

通过本发明的上述方案，微服务消息总线是一个消息中心，众多微服务实例连接到微服务消息总线上，实例通过监听的方式往消息中心发送或接收信息，微服务网关代理为在客户端和服务端之间增加一个API网关，所有的外部请求先通过这个微服务网关，它只需跟网关进行交互，而由网关进行各个微服务的调用；

微服务注册与发现包括服务治理中心Eureka、服务注册、服务发现，Eureka包含两个组件：EurekaServer和EurekaClient，EurekaServer提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息在界面中直观的看到，EurekaClient是一个Java客户端，用于简化与EurekaServer的交互，客户端同时也具备一个内置的、使用轮询负载算法的负载均衡器，服务注册指的是在服务治理框架中，通常都会构建一个注册中心，每个服务单元向注册中心登记自己提供的服务，将主机与端口号、版本号、通信协议一些附加信息告知注册中心，注册中心按照服务名分类组织服务清单，服务注册中心还需要以心跳的方式去监控清单中的服务是否可用，若不可用需要从服务清单中剔除，服务发现包括提供者服务发现和消费者服务发现；

微服务认证授权：在使用SpringCloud体系来构建微服务的过程中，用户请求是通过网关：ZUUL或SpringAPI网关，以HTTP协议来传输信息，API网关将自己注册为Eureka服务治理下的应用，同时也从Eureka服务中获取所有其他微服务的实例信息，搭建微服务认证授权服务，并不是给每个微服务调用，而是通过API网关进行统一调用来对网关后的微服务做前置过滤，所有的请求都必须先通过API网关，API网关在进行路由转发之前对该请求进行前置校验，实现对微服务系统中的其他的服务接口的安全与权限校验。

通过本发明的上述方案，提供者服务发现指的是在服务提供者和服务消费者之间有一个独立的负载均衡器，负载均衡器上有所有服务的地址映射表，当服务消费者调用某个目标服务时,向负载均衡器发送请求,负载均衡器根据策略做负载均衡后将请求转发到目标服务，消费者服务发现指的是服务消费者要访问某个服务时，通过内置的负载均衡组件向服务注册表查询目标服务地址列表，然后以某种负载均衡策略选择一个目标服务地址，最后向目标服务发起请求，这一方案需要一个服务注册表配合服务注册和发现，采用高可用、分布式一致的组件Zookeeper、Consul、Etcd来实现。

通过本发明的上述方案，微服务高可用包括多副本部署、变更管理、微服务自愈和失效缓存，具体如下：

多副本部署：服务注册中心EurekaServer是微服务系统的核心组件，单点部署显然这并不适合应用于线上生产环境，通过运行多个实例，并进行互相注册的方式来实现高可用的部署，所以我们只需要将EurekeServer配置其他可用的serviceUrl就能实现高可用部署，但是实际上因负载原因，往往需要在生产环境构建多于两个的EurekaServer节点，EurekaServer的同步遵循着一个非常简单的原则：只要有一条边将节点连接，就进行信息传播与同步，因此，只要部署3个注册中心，两两注册的方式实现集群中节点完全对等的效果，实现最高可用性集群，任何一台注册中心故障都不会影响服务的注册与发现；

变更管理：在微服务架构里，服务之间是相互依赖的，所以要最小化出现故障的几率，限制故障所造成的负面影响，在部署新应用时，或者在对配置做出变更时，要先在一小部分服务实例上进行，然后监控它们，一旦发现关键性度量指标出现异常，马上自动回滚；

微服务自愈：自愈能力能够让应用在发生故障时进行自我恢复，通过部署应用容器实例运行监控组件，实施心跳检测来确定服务的可用性，并在服务故障时，进行微服务实例多副本同步，并在其它服务器上重建改服务，实现微服务自愈。

通过本发明的上述方案，微服务负载均衡指的是通过硬件或软件实现负载均衡均会维护一个服务端清单，利用心跳检测手段进行清单维护，保证清单中都是正常访问的服务节点；当用户发送请求时，会先到达负载均衡器，负载均衡器根据负载均衡算法：轮训、随机、加权轮训，从可用的服务端列表中取出一台服务端的地址，接着进行转发，降低系统的压力，基于开源SpringCloudRibbon构建面向微服务的客户端负载均衡工具，它将面向服务的REST模板请求自动转换成客户端负载均衡的服务调用。

通过本发明的上述方案，微服务熔断指的是为了防止“雪崩效应”，必须提供一个容错机制，当调用延迟超过一定时间时，采取一定措施处理，而不是让其一直处于等待状态，简单来说，该机制实现关键点如下：

1为网络请求设置超时时间：主要是防止因服务故障或网络延迟导致请求堆积，占用服务器资源；

2使用断路器模式：当调用出错或者超时，服务将此请求标记为失败，给调用方返回信息提示，即调用失败处理方法，基于SpringCloudHystrix设计面向微服务的容错保护服务，用户隔离访问远程服务，防止级联失败，它实现了断路器、线程隔离、信号隔离容错功能，能够在一个、或多个依赖同时出现问题时保证系统可用。

通过本发明的上述方案，微服务调用追踪指的是一个完整的微服务系统包含多个微服务单元，各个微服务子系统存在互相调用的情况，形成一个调用链，战场环境下的移动终端应用访问请求、跨云数据协同请求，从发出到被指挥车单元响应经历了哪些组件、哪些微服务、请求总时长、每个组件所花时长信息有必要了解和收集，一方面能帮助定位性能瓶颈、进行性能调优，另一方面针对战场环境下的应用进行追踪和高可用优化，因此监控整个微服务架构的调用链十分有必要，基于Zipkin开发分布式的追踪系统，帮助收集微服务架构中用于解决延时问题的时序数据，它通过创造一些追踪标识符tracingId，spanId，parentId，最终将一个request的流程树构建出来，各业务系统在彼此调用时，将特定的跟踪消息传递至Zipkin，Zipkin在收集到跟踪信息后将其聚合处理、存储、展示。

通过综合分析，结合微服务链资源调度问题的特点，采用改进的遗传算法求解。而在简单的遗传算法基础上，NSGA和NSGA-II是两种目前用于解决多目标优化问题的常见方法，他们建立在遗传算法思想基础上，进行了适当变种。NSGA在选择算子执行交叉和遗传之前，会根据个体之间的支配关系进行分级，逐个找出满足非支配关系的个体。而NSGA-II在NSGA基础上，提出快速非支配排序算法，不仅降低计算复杂度，而且父代种群和子代种群的合并保证了最优个体的保留；此外NSGA-II还引进精英策略，保证优良的个体在进化过程中始终被保留；采用拥挤度和拥挤度比较算子，保证种群多样性利用基于遗传算法的NSGA-II求解，首先确定种群为一定数量的可行调度方案，接着对问题的可行解进行染色体编码，确定染色体上每条基因的含义，再选定遗传交叉和突变的具体方案，最后进行求解。

最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限定本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (7)

1.基于微服务架构的应用管理方法，其特征在于，包括面向战术应用的微服务技术架构设计、轻量化的微服务运行支撑环境构建、面向战术环境的微服务可靠管理技术和信息服务全过程动态运维，具体如下：

面向战术应用的微服务技术架构设计：包括超融合资源层、微服务环境支撑层、微服务管理调度层、战术级业务服务层和接入层，超融合资源层指底层构建微服务的车载硬件平台和虚拟化资源池，是提供微服务环境的物理支撑，虚拟化资源池包括计算资源池、存储资源池、网络资源池，微服务支撑环境层构建了微服务框架的运行时系统，是支撑微服务运行的框架，包括消息总线、微服务网关、微服务注册发现、认证授权支撑组件，并由配置中心进行集中管理，微服务管理调度层用于构建支持恶劣战场环境下的高可靠微服务集群，具体包括微服务高可用、微服务熔断、微服务负载均衡、微服务调用追踪、微服务部署管理、微服务监控告警、微服务后台服务管理，业务服务层提供了基于微服务框架的丰富战术级应用，应用以微服务解耦模式部署，通过数据库服务、认证服务多单元基础服务的聚合，形成对外提供完整服务的战术级应用业务系统，接入层是用户访问微服务应用的接口层，接入层部署了负载均衡和接入网关组件；

轻量化的微服务运行支撑环境构建：在微服务技术架构基础上，基于SpringCloud构建轻量级微服务运行时支撑环境，包括微服务消息总线、微服务网关代理、微服务注册与发现和微服务认证授权，由微服务配置中心进行统一管控，服务消息总线通过建立多个应用之间的通信频道，管理和传播应用间的消息，实现多个微服务之间的同步配置和更新，微服务网关代理实现代理和过滤功能，消息总线和网关实现应用之间的关系解耦，微服务注册与发现实现微服务的动态构建，微服务认证授权提供用户访问微服务的统一认证接口，构建适应于机动战术云的微服务系统，各运行时组件配置和流程说明如下：

1接入访问请求统一通过API网关代理来访问内部服务；

2网关接收到请求后，从注册中心获取可用服务；

3获取可用服务，分发到后端具体实例；

4微服务之间通过消息总线进行通信处理业务；

5统一认证和访问控制作为微服务重要模块，也以微服务的形式部署；

面向战术环境的微服务可靠管理技术：面向陆军战术环境服务可靠管理的需求，在微服务运行支撑环境之上，研究战场环境下的微服务可靠管理技术，具体包括微服务高可用、微服务熔断、微服务负载均衡、微服务调用追踪，从而在机动性强、实时性高的陆军机动作战环境下，提升应用服务的快速响应、稳定可靠运行的能力，微服务高可用管理，通过配置多服务注册中心副本、服务自愈、服务缓存实现战术应用的高可用，面向微服务容错保护的服务熔断，设计面向微服务的容错保护服务，用户隔离访问远程服务，防止级联失败，实现断路器、线程隔离、信号隔离容错功能，能够在一个、或多个依赖同时出现问题时保证系统依然可用，防止雪崩效应，面向微服务的客户端负载均衡，感知弹性伸缩发生后后端实例的状态变化，并将最新的后端信息更新至负载均衡器，进而实现应用服务的弹性负载均衡，微服务调用链追踪技术，构建针对微服务全生命周期的监控，增强微服务的运维管理和性能优化能力，具体如下：

1网关从注册中心获取服务后，通过客户端负载均衡，分发到后端具体实例，从而保障战场资源的运行效率；

2访问的微服务网关、微服务实例多副本部署，具有高可用；同时还具有访问缓存、自愈功能保障故障时的临时访问；

3战场环境下出现微服务故障时，由网关代理执行容错保护，以服务降级响应形式返回客户端；

4用户的微服务访问路径、微服务之间的消息总线通信，设置监控和追踪组件，实现微服务调用链的追踪；

信息服务全过程动态运维：包括应用业务逻辑感知的快速系统开设机制、基于微服务视图的轻量化数据加载技术、基于多服务实例同步的信息共享机制和战场环境感知的微服务链动态重组技术，具体如下：

应用业务逻辑感知的快速系统开设机制：对应用进行解构，明晰其业务组件：微服务，通过对业务逻辑、组件架构及功能差异的分析，明确其微服务构成，对于微服务的执行，以一个或多个虚拟机或容器的形式来完成其功能，并满足一定的业务需求即应用的负载，此外，也据此分析出应用的总体资源需求和数据依赖，基于应用的微服务化过程，明确系统开设所需要的基本微服务，结合各微服务实例的分布情况，自动实现微服务链的推荐、选取，从而完成系统开设，微服务链的选择过程包括：微服务实例的描述、应用微服务链生成、微服务链的评估与确定，微服务实例描述：定义s＝(pos,ra,o,e)为单个微服务实例，采用4个属性进行描述；其中，pos表示该服务实例所在的位置，包括云、端设备；ra表示该服务实例的输出输入数据比，即ra＝amountoutput/amountinput，表明该微服务产生的数据传输时延开销；o表示该服务实例处理单位数据所花费的时间；e表示该服务的有效性(0/1)，即是否可用，此外，用mEN(s)表示微服务实例s所在的节点所能具有的微服务实例数量上限，pEN(s)表示微服务实例s所在的节点当前具有的服务数量，应用微服务链生成；令SG＝<S,E,s0>表示生成的微服务链，s0表示微服务链的源节点，即发起应用请求的位置，当s0调用该应用服务时，将根据此组合服务的某条组件功能链，记为P，生成相应的SG，S表示P中涉及的功能组件的所有服务实例构成的集合；E表示S中微服务实例之间有向边的集合；

基于微服务视图的轻量化数据加载技术：微服务架构下，每个微服务根据自己的业务特征，自由选择适用的数据库，而无需采用完全一致的数据库；时序数据库对于实时数据的预处理更加有效，因此，每个微服务根据业务的功能和非功能性需求，生成独立的微服务视图，并据此从综合数据存储中加载所需的数据，从而完成数据加载过程，微服务根据自己的需要生成数据加载规则，微服务加载过程包含的主要流程有系统启动流程、全量数据加载流程和增量数据加载流程，系统启动流程就是各微服务的启动，启动顺序应该是首先启动数据库读取组件，然后启动域内控制器，最后在需要加载数据时启动数据加载服务器，系统启动时微服务数据库读取组件通过配置文件，首先建立与数据库之间的连接，域内控制器启动后连接微服务数据库读取组件，获取微服务数据库基本信息：数据表名、数据列名、数据规模，域内控制器将数据库基本信息提供给客户端；根据微服务数据库基本信息，生成加载规则：需要加载数据表名、数据列名，将加载规则发送给域内控制器，域内控制器将加载规则分发给各微服务；每个微服务的数据库读取任务，分别批量加载数据并上传读取结果；

基于多服务实例同步的信息共享机制：信息共享是战场环境下的重要应用服务，微服务架构下，信息的逻辑载体为微服务实例，而其物理载体为虚拟机或容器，由于各微服务实例基于自身业务特征选用了不用的数据库；因此，跨库的数据共享会带来较大的数据模式转换开销，据此，拟采用基于信息目录的机制完成数据共享过程，为实现对多个微服务实例间的高效共享，满足对战场实时变化的需求，建立微服务信息目录收集、存储、链接关联多个微服务，实现各类微服务能够按需提供和访问各类数据，在信息目录中快速搜索和管理微服务资源，并通过订阅微服务主题，实现微服务资源的按需主动推送，达到对微服务资源的高效共享，其次，是需要实现微服务的状态监控，在多个微服务工作的各个阶段，采用具体的监控进程：Linux系统脚本和开发的监听工具，进行作业，使各阶段的服务依序启动、依序监听、依序关闭，严格处理好各应用服务之间的依赖关系，当服务开启时自动按顺序启动底层服务和应用进程，为了做到多服务的自维护与管理，添加了服务监听进程，定期检测各个服务的运行状态以及系统维护信号，当检测到某个服务意外关闭时便发通知给管理员并尝试重新启动该服务，当检测到服务需要关闭或重启时，在关机/重启前，安全关闭相关进程与服务，确保系统数据的完整性，为了实现自动待机，管理多服务互关联的管理问题，需要解决如何自启动数据库并成功挂载；如何安全关闭数据库；如何自启动及安全关闭统一认证服务；如何实现服务启动与关闭的依序进行；如何实现服务监听进程并定期自检，在传统微服务链的组合模式，通常多个微服务，各自独立执行服务任务，多微服务之间不存在服务链的动态共享机制，而系统监控只对各自独立的微服务进行配置管理；为了适应微服务资源动态重组需求，建立虚拟微服务监控管理池，集中监控管理所有微服务活动状态把以单个微服务为对象的资源调配模式扩大为以全局服务链为对象的服务链动态重组模式，自动对虚拟微服务资源池内的多个微服务进行调控，完成服务链重组、参数配置和自动化运行工作；

战场环境感知的微服务链动态重组技术：随着战场环境和网络拓扑条件的快速变化，原有微服务链的执行会由于通信失效、端节点失效原因无法高效完成应用；因此，有必要针对战场动态环境信息，进行微服务链服务质量监控并进行主动的微服务链动态重组，保障应用的服务质量，基于微服务的应用有多种微服务链实现方式，但是多数微服务所需的网络功能之间都存在依赖关系，防火墙要部署在微服务链的入口和出口处，从而保证微服务的安全要求，因此我们假设在微服务到达后，经过业务编排器分析得到的微服务链是固定的，接下来只需要通过对设计好的微服务链进行资源动态重组，假设底层网络中有N个虚拟机，对微服务器上部署的实例的类型进行存储、计算物理资源的调整，大大提高这些物理资源的利用效率，减少资源浪费；资源动态重组问题本质上是一个优化问题，为微服务链进行实例资源调度的目的是提高资源利用率，同时不对微服务完成时间产生较大的影响，因此将微服务完成时间和稳定性共同作为优化目标，而其中微服务完成时间是最重要的优化目标。

2.根据权利要求1所述的基于微服务架构的应用管理方法，其特征在于，所述微服务消息总线是一个消息中心，众多微服务实例连接到微服务消息总线上，实例通过监听的方式往消息中心发送或接收信息，微服务网关代理为在客户端和服务端之间增加一个API网关，所有的外部请求先通过这个微服务网关，它只需跟网关进行交互，而由网关进行各个微服务的调用；

微服务注册与发现包括服务治理中心Eureka、服务注册、服务发现，Eureka包含两个组件：EurekaServer和EurekaClient，EurekaServer提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息在界面中直观的看到，EurekaClient是一个Java客户端，用于简化与EurekaServer的交互，客户端同时也具备一个内置的、使用轮询负载算法的负载均衡器，服务注册指的是在服务治理框架中，通常都会构建一个注册中心，每个服务单元向注册中心登记自己提供的服务，将主机与端口号、版本号、通信协议一些附加信息告知注册中心，注册中心按照服务名分类组织服务清单，服务注册中心还需要以心跳的方式去监控清单中的服务是否可用，若不可用需要从服务清单中剔除，服务发现包括提供者服务发现和消费者服务发现；

微服务认证授权：在使用SpringCloud体系来构建微服务的过程中，用户请求是通过网关：ZUUL或SpringAPI网关，以HTTP协议来传输信息，API网关将自己注册为Eureka服务治理下的应用，同时也从Eureka服务中获取所有其他微服务的实例信息，搭建微服务认证授权服务，并不是给每个微服务调用，而是通过API网关进行统一调用来对网关后的微服务做前置过滤，所有的请求都必须先通过API网关，API网关在进行路由转发之前对该请求进行前置校验，实现对微服务系统中的其他的服务接口的安全与权限校验。

3.根据权利要求2所述的基于微服务架构的应用管理方法，其特征在于，所述提供者服务发现指的是在服务提供者和服务消费者之间有一个独立的负载均衡器，负载均衡器上有所有服务的地址映射表，当服务消费者调用某个目标服务时,向负载均衡器发送请求,负载均衡器根据策略做负载均衡后将请求转发到目标服务，消费者服务发现指的是服务消费者要访问某个服务时，通过内置的负载均衡组件向服务注册表查询目标服务地址列表，然后以某种负载均衡策略选择一个目标服务地址，最后向目标服务发起请求，这一方案需要一个服务注册表配合服务注册和发现，采用高可用、分布式一致的组件Zookeeper、Consul、Etcd来实现。

4.根据权利要求1所述的基于微服务架构的应用管理方法，其特征在于，所述微服务高可用包括多副本部署、变更管理、微服务自愈和失效缓存，具体如下：

多副本部署：服务注册中心EurekaServer是微服务系统的核心组件，单点部署显然这并不适合应用于线上生产环境，通过运行多个实例，并进行互相注册的方式来实现高可用的部署，所以我们只需要将Eureke Server配置其他可用的serviceUrl就能实现高可用部署，但是实际上因负载原因，往往需要在生产环境构建多于两个的EurekaServer节点，EurekaServer的同步遵循着一个非常简单的原则：只要有一条边将节点连接，就进行信息传播与同步，因此，只要部署3个注册中心，两两注册的方式实现集群中节点完全对等的效果，实现最高可用性集群，任何一台注册中心故障都不会影响服务的注册与发现；

变更管理：在微服务架构里，服务之间是相互依赖的，所以要最小化出现故障的几率，限制故障所造成的负面影响，在部署新应用时，或者在对配置做出变更时，要先在一小部分服务实例上进行，然后监控它们，一旦发现关键性度量指标出现异常，马上自动回滚；

微服务自愈：自愈能力能够让应用在发生故障时进行自我恢复，通过部署应用容器实例运行监控组件，实施心跳检测来确定服务的可用性，并在服务故障时，进行微服务实例多副本同步，并在其它服务器上重建改服务，实现微服务自愈。

5.根据权利要求1所述的基于微服务架构的应用管理方法，其特征在于，所述微服务负载均衡指的是通过硬件或软件实现负载均衡均会维护一个服务端清单，利用心跳检测手段进行清单维护，保证清单中都是正常访问的服务节点；当用户发送请求时，会先到达负载均衡器，“负载均衡器根据负载均衡算法：轮训、随机、加权轮训，从可用的服务端列表中取出一台服务端的地址”，接着进行转发，降低系统的压力，基于开源SpringCloudRibbon构建面向微服务的客户端负载均衡工具，它将面向服务的REST模板请求自动转换成客户端负载均衡的服务调用。

6.根据权利要求1所述的基于微服务架构的应用管理方法，其特征在于，所述微服务熔断指的是为了防止“雪崩效应”，必须提供一个容错机制，当调用延迟超过一定时间时，采取一定措施处理，而不是让其一直处于等待状态，简单来说，该机制实现关键点如下：

1为网络请求设置超时时间：主要是防止因服务故障或网络延迟导致请求堆积，占用服务器资源；

2使用断路器模式：当调用出错或者超时，服务将此请求标记为失败，给调用方返回信息提示，即调用失败处理方法，基于SpringCloudHystrix设计面向微服务的容错保护服务，用户隔离访问远程服务，防止级联失败，它实现了断路器、线程隔离、信号隔离容错功能，能够在一个、或多个依赖同时出现问题时保证系统可用。

7.根据权利要求1所述的基于微服务架构的应用管理方法，其特征在于，所述微服务调用追踪指的是一个完整的微服务系统包含多个微服务单元，各个微服务子系统存在互相调用的情况，形成一个调用链，战场环境下的移动终端应用访问请求、跨云数据协同请求，从发出到被指挥车单元响应经历了哪些组件、哪些微服务、请求总时长、每个组件所花时长信息有必要了解和收集，一方面能帮助定位性能瓶颈、进行性能调优，另一方面针对战场环境下的应用进行追踪和高可用优化，因此监控整个微服务架构的调用链十分有必要，基于Zipkin开发分布式的追踪系统，帮助收集微服务架构中用于解决延时问题的时序数据，它通过创造一些追踪标识符tracingId，spanId，parentId，最终将一个request的流程树构建出来，各业务系统在彼此调用时，将特定的跟踪消息传递至Zipkin，Zipkin在收集到跟踪信息后将其聚合处理、存储、展示。