CN111464612A - 一种恶劣环境下提供稳定计算服务的方法 - Google Patents

Abstract

本发明涉及一种恶劣环境下提供稳定计算服务的方法，它包括以下步骤：（a）对各服务中心构建计算服务管理框架，所述计算服务管理框架包括计算服务调用单元和计算服务运行支撑单元；（b）在各所述服务中心之间建立计算服务交互协议和计算服务重发补偿及安全认证机制，使各所述服务中心之间为对等关系且具有互为备份的能力；（c）在每个所述服务中心内，依托容器技术并采用所述计算服务管理框架创建服务实例；（d）采用主题订单及发布订阅机制在相互通信的所述节点间进行数据同步；（e）使用客户端连接任一所述服务中心。可以确保计算资源持续可用、计算服务能够持续稳定提供，解决了计算存储服务节点等因为故障或遭受攻击而不能提供服务的问题。

Description

一种恶劣环境下提供稳定计算服务的方法

技术领域

本发明属于信息处理技术领域，涉及一种恶劣环境下提供稳定计算服务的方法，具体涉及一种在网络弱连接及数据传输时断时续等恶劣环境下确保计算资源持续可用、计算服务持续稳定提供的方法。

背景技术

信息技术的重点越来越多地偏向于对数据的存储和处理，因此计算服务和数据的安全性受到越来越多的重视，这样的发展趋势推动了抗毁接替和数据备份技术的研究与发展。从单机备份，到基于SAN的LAN-FREE备份，再到SERVER-FREE备份，直至现在可以提供最高安全性的数据抗毁接替和应用抗毁接替，可见数据的备份和抗毁接替技术经历了一个从本地到异地、从单一到融合的发展过程。

国外对抗毁接替的研究开始于20世纪90年代，主要集中于各大科研机构和IBM、EMC、赛门铁克、惠普等大型IT企业。其中代表性的商业产品包括赛门铁克的VERITASGlobal Cluster Manager、VERIATS Cluster Server等，IBM的HAGEO、XRC等，惠普的MC/Service Guard以及EMC的SRDF等。这些具有代表性的产品和解决方案针对不同行业和单位的需求都有各自的亮点和优势，它们几乎都是基于iSCSI技术、FC技术以及远程复制技术，虽然产品的性能很强大，功能也比较齐全；然而部署这样一套完整的抗毁接替系统需配置专用的光纤链路，而光纤链路价格非常高，所以实施上述远程抗毁接替系统需要有非常大的投入，并且数据生产中心和远程抗毁接替中心之间所间隔的距离相当有限，如果距离太远会导致成本的急剧增加，距离太短又无法达到远程抗毁接替的目的，所以一般将10公里作为系统部署标准。此外，这些抗毁接替产品都被集成在各家公司的硬件设备上，所以在灵活度、软硬件通用性方面都存在一定缺陷。

而且机动环境下，通信网络带宽相对较低，并因为地理气候等环境因素的影响，或因为对抗条件下干扰等因素，会导致网络通信不稳定，出现时断时续的现象，这会导致相关资源服务能力受到影响，甚至出现不能正常提供服务的现象。此外，机动环境下，计算存储服务节点等因为故障或遭受攻击而不能提供服务也是一种大概率事件。计算服务不可用、数据不可访问、信息不能及时处理，这无疑会使信息共享服务保障出现异常。

发明内容

本发明目的是为了克服现有技术的不足而提供一种恶劣环境下提供稳定计算服务的方法。

为达到上述目的，本发明所采用的技术方案为：一种恶劣环境下提供稳定计算服务的方法，它包括以下步骤：

（a）对各服务中心构建计算服务管理框架，所述计算服务管理框架包括计算服务调用单元和计算服务运行支撑单元；

（b）在各所述服务中心之间建立计算服务交互协议和计算服务重发补偿及安全认证机制，使各所述服务中心之间为对等关系且具有互为备份的能力；

（c）在每个所述服务中心内，依托容器技术并采用所述计算服务管理框架创建服务实例；

（d）采用主题订单及发布订阅机制在相互通信的所述节点间进行数据同步；

（e）使用客户端连接任一所述服务中心，当目标服务存在于所述服务中心内时，所述客户端采用直连模式访问所述目标服务；当所述目标服务不存在于所述服务中心内时，所述服务中心通过代理向目标服务所在的所述服务中心发起访问请求以访问所述目标服务。

优化地，步骤（a）中，所述计算服务调用单元包括服务同步调用模块和服务异步调用模块，所述计算服务运行支撑单元包括服务监控模块、服务代理模块、服务管理模块、数据同步模块和服务注册模块。

优化地，步骤（b）中，采用所述计算服务交互协议对服务请求和响应数据进行编解码。

进一步地，步骤（b）中，所述计算服务交互协议采用二进制报文压缩算法。

优化地，步骤（b）中，所述计算服务重发补偿及安全认证机制在服务间使用断线重连、超时重发、异常重发和服务方报文校验手段确保在断线和丢包情况下正确处理服务请求。

进一步地，步骤（c）中，所述服务注册模块接收所述服务中心内各个节点向其注册当前本节点上正在运行的计算服务实例信息。

更进一步地，步骤（c）中，所述服务监控模块监控节点上各个计算服务实例的运行状态。

更进一步地，步骤（c）中，所述服务管理模块负责管理中心内正在运行的计算服务实例，根据计算服务实例的注册和监控信息，动态更新计算服务的部署信息，并通过容器完成计算服务的提交更新。

由于上述技术方案运用，本发明与现有技术相比具有下列优点：本发明恶劣环境下提供稳定计算服务的方法，通过采用计算服务管理框架、建立计算服务交互协议和计算服务重发补偿及安全认证机制、依托容器技术创建服务实例以及以订阅机制进行数据同步，可以确保计算资源持续可用、计算服务能够持续稳定提供，解决了计算存储服务节点等因为故障或遭受攻击而不能提供服务的问题。

附图说明

图1为本发明计算服务管理框架图；

图2为本发明计算服务交互协议多路复用机制图；

图3为本发明计算服务重发补偿及安全认证机制原理图；

图4为本发明计算服务管理框架原理图；

图5为本发明基于发布订阅的数据同步原理示意图；

图6为本发明数据同步模型结构图；

图7为本发明计算服务抗毁接替示意图；

图8为本发明无中心数据同步模型。

具体实施方式

下面将结合附图对本发明优选实施方案进行详细说明。

机动服务中心需要承接机动服务节点卸载下的短时的计算任务，同时对外提供长时的计算服务。

机动、恶劣环境下，由于网络弱连接及数据传输时断时续等原因，导致用户无法按传统模式访问计算服务，从而无法得到充分的服务保障；同时在恶劣的机动、恶劣环境下，节点、服务中心失效或被打击毁灭将成为常态；因此，为了保障服务的长效、可靠和抗打击能力，研究连接弱通信与节点失效等环境下服务抗毁接替技术，实现在不可靠环境中提供可靠的计算服务是用户现阶段面临的核心需求。

机动、恶劣环境下可能面临的毁伤情况包括：

（1）服务中心部分毁伤

服务中心部分损伤是指由于恶劣的环境导致服务中心内部分服务器受损无法正常工作，剩余服务器还具备提供服务的能力。

（2）服务中心完全毁伤

服务中心完全损伤是指服务中心完全瘫痪，处于无法正常工作，并且无法联通的状态。

（3）服务节点毁伤

服务节点毁伤是指服务节点设备由于故障无法正常运行。

对于情况（1）服务中心部分毁伤，通过分布式节点资源弹性扩展技术实现在服务中心损伤节点数小于1/2的情况下，仍能接收并执行服务节点卸载的短时的计算任务，实现短时的计算任务的抗毁接替。长时的计算服务如何在服务中心部分毁伤的情况下仍能提供服务是本申请研究解决的关键问题之一。

对于情况（2）服务中心完全毁伤，短时的计算任务和长时的计算服务可通过高动态环境下跨服务中心的任务管理调度系统恢复运行。其中，短时的计算任务重新开始计算，完成计算任务的抗毁接替；而长时的计算服务则需要考虑恢复原来的状态，并通过服务路由，为用户提供不间断的计算服务，去实现计算服务的抗毁接替，这是本申请研究解决的关键问题之一。

对于情况（3）服务节点毁伤，由于计算服务和计算任务都在机动服务中心运行，计算服务和计算任务的运行不会受到影响。同时计算服务和计算任务都将数据存储到计算服务中心，单一服务节点的损伤可以简单的通过更换设备重新登录到计算服务中心访问自己需要的计算服务和计算任务数据。

针对上述问题，本申请提出了一种恶劣环境下计算服务管理框架，该框架基于服务高效调用技术和中心内抗毁接替策略来提升中心内计算服务的高可用性，并基于发布订阅的数据同步技术和中心间抗毁接替技术实现中心间计算服务的高可用性，为用户提供稳定可靠的计算服务。

上述发明恶劣环境下提供稳定计算服务的方法，它包括以下步骤：

（a）对各服务中心构建计算服务管理框架，计算服务管理框架包括计算服务调用单元和计算服务运行支撑单元。服务中心面向战术级系统应用需求，提供车载集群、机动分队和单兵系统服务运行环境，支持服务即插即用和共享，确保用户快速获取服务，并实现系统快速部署、功能迭代升级和灵活组配使用等功能。根据服务中心应用需求，分析系统间信息交互类型、内容及特点，底层依托网络进行服务运行和通信，结合网络化和服务化等技术，建立适应机动通信网络的环境服务架构，如图1所示，为用户提供一体化的计算服务开发、运行、管理、调度、部署和监控环境，确保服务调用的时效性和适应性，支撑业务系统在恶劣环境中能有效支撑指挥控制，主要分为以下两部分：（1）计算服务运行支撑：为用户提供服务管理、服务注册、服务代理、服务监控、数据同步等功能，根据网络状态实现自动服务路由寻址，保证计算服务单元及中心间的高可靠访问，实现计算服务抗毁接替能力；（2）计算服务调用：针对联合恶劣环境各类业务信息系统，为用户提供计算服务的同步调用和异步调用两种功能。

（b）在各所述服务中心之间建立计算服务交互协议和计算服务重发补偿及安全认证机制，使各所述服务中心之间为对等关系且具有互为备份的能力。

恶劣环境下的计算服务在连接弱通信中应建立服务交互协议和服务重发补偿及安全认证机制以增强服务可达性，并研究服务协议实用消息标准和压缩编码等技术提高服务传输速率，具体如下：

（1）计算服务交互协议

采用计算服务交互协议对服务请求和响应数据进行编解码。对服务请求和响应数据进行编解码是实现服务远程调用的核心，同时为了满足服务高效调用需求，需要实现二进制报文压缩算法。计算服务交互协议提供连接多路复用、双向流、服务器推送、请求优先级、首部压缩等机制，实现节省带宽、降低TCP连接次数、节省CPU，帮助移动设备延长电池寿命等。计算服务交互协议允许同时通过单一的网络连接发起多重的请求-响应消息，这样就可以很容易的实现多流并行而不依赖建立多个TCP连接，同时将通信的基本单元缩小为一个一个帧，这些帧对应逻辑流中的消息，并行地在同一个TCP连接上双向交换消息。计算服务交互协议多路复用机制如图2所示。

计算服务交互协议传输的数据是二进制的，相比HTTP/1.1的纯文本数据，二进制数据拥有更小的传输体积，降低了通信负载，同时二级制的帧更易于解析且不易出错，纯文本帧在解析过程中还要考虑处理空格、大小写、空行和换行等问题。

客户端与计算服务交互都是无状态的，这就意味着每个请求必须携带服务器需要的所有细节，而不是让计算保存之前请求的元数据。每个请求的头部都需要包含用于标识身份的数据，这对于ZS环境中连接弱通信是个极大的挑战。计算服务交互协议对客户端请求头部进行压缩，大大降低了通信负担，提高通信性能。

在序列化方面，计算服务交互协议可考虑基于Protobuf来定义服务。Protobuf是由Google开发的一种类似于XML、JSON的数据序列化协议。Protobuf能够将数据进行序列化，并通过压缩支持数据的高效传输。

计算服务交互协议可极大压缩传输数据量并提高效率，高效实现服务调用数据的编码与解码。协议消息主要信息应包括：

接口方法：包括接口名和方法名；

方法参数：包括参数类型和参数值；

调用属性：包括调用属性信息，如调用超时时间等；

返回结果：包括接口方法中定义的返回值；

返回码：包括执行状态的标识码；

异常信息：包括调用的异常信息；

控制信息：与底层通信协议集成实现数据报文传输层优先级以及未来可能的扩展。

（2）计算服务重发补偿及安全认证机制

计算服务过程调用实质上是一种可靠的请求－应答消息流，服务间应使用断线重连、超时重发、异常重发和服务方报文校验等手段确保在断线和丢包情况下正确处理请求，保障服务请求和响应的高效和有序传输。服务重连重发及报文校验机制原理如图3所示。

计算服务重连重发以及报文校验机制具体包括：连接管理、安全管理两个功能。

连接管理负责解决无论网络连接质量如何，都能较好的满足客户端对计算服务的远程过程调用，同时尽可能降低服务器资源消耗，减少不必要的网络流量。连接管理中体现重发补偿机制，当客户端和计算服务之前连接突然失效，消息发送失败，连接管理自动做请求重发。

安全管理负责连接的安全认证和报文内容校验。连接安全接收用户发送的连接令牌来验证连接用户是否合法，同时对接收的报文进行校验，如果验证通过则接收数据。如果验证不通过，则关闭连接，回收资源

（c）在每个所述服务中心内，依托容器技术并采用所述计算服务管理框架创建服务实例。

恶劣环境中，中心内的服务器的稳定性无法得到全面可靠的保证，网络波动、服务器宕机等问题都将导致服务实例无法正常访问，给用户造成较差的体验；因此需要在中心内采用某些策略来实现用户无感的计算服务抗毁接替，即解决服务质量（QoS）问题。依托容器技术，采用轻量级的计算服务管理框架创建服务的冗余实例来保证中心内服务的高效访问，如图4所示。

中心内服务抗毁接替能力通过计算服务管理框架的服务注册模块、服务监控模块以及服务管理模块来实现。

服务注册模块接收中心内各个节点向其注册当前本节点上正在运行的计算服务实例信息，注册信息主要包括：节点IP、计算服务名称、计算服务运行的内部IP、计算服务当前状态（启动、运行、异常、结束）等。中心内各个节点定期向注册模块报告本节点上的服务实例信息，注册模块在接收到相关信息后对中心内的服务实例情况进行统计等处理，并提供给计算服务管理框架的其他模块。如果中心内的某个节点由于网络或其他原因超过一定的时限没有向服务注册模块更新信息，则服务注册模块会标记该节点为下线，并将该节点上的计算服务实例通过服务中心重新调度到其他节点上运行。

服务监控模块负责监控节点上各个计算服务实例的运行状态，主要是各个计算服务实例对资源的消耗情况（CPU、网络、内存），节点在启动后会向服务监控模块汇报本节点上不同类型的资源总量，并在节点资源总量发生变化时进行更新；同时，节点会定期统计运行在其上的服务实例的相关资源使用情况并汇报给监控模块，监控模块在收集到中心内的资源信息后会进行统计处理，用户可通过服务监控模块发布的服务查看到当前中心的资源使用详情。

服务管理模块主要负责管理中心内正在运行的计算服务实例，它根据计算服务实例的注册和监控信息，动态更新计算服务的部署信息，并通过容器完成计算服务的提交更新；服务管理模块通过这种方式来动态管理计算服务实例的数量；例如服务管理模块通过计算发现当前某计算服务的各个实例的访问请求数量较高，通过计算后，为该计算服务增加一个实例，并将更新信息提交给容器，容器接收到更新请求后在中心内选择一个节点新增计算服务实例，新增服务实例在启动后向服务注册模块注册。

用户在访问计算服务时，会首先向服务注册模块发起请求获取计算服务实例所在的位置，服务注册模块会根据当前各个计算服务实例的访问压力，根据一定的负载均衡算法选择一个服务实例的位置返回给用户，用户再向该实例发起服务请求。

（d）采用主题订单及发布订阅机制在相互通信的所述节点间进行数据同步。

恶劣环境中节点间主要通过无线方式进行通信，在链路环境相对开放、弱连接通信及误码率高的环境中，可采用主题订单及发布订阅机制进行数据同步。同时，对数据进行压缩优化以减轻网络压力，实现断点续传以确保极端情况下数据的可靠性，数据同步原理示意图如图5所示。战术级中心是战术级系统区域性信息数据汇聚之处，对上接入战区级服务中心，同时对所辖区域内的系统提供各类信息数据服务。战术服务中心间多为对等结构关系，并具备互为备份、信息同步和互为替代能力。恶劣环境中，根据网络带宽和性能等因素的动态调整，基于订阅发布的QoS策略（定时、实时和手动推送拉取等）同步模式，可较好适应网络，提高终端对热点信息数据自动获取同步能力，实现数据在各作战单元节点的分布式缓存，提高数据响应时间，减少服务中心访问压力。

所谓QoS即服务质量，指一个网络能够利用各种基础技术，为指定的网络通信提供更好的服务能力, 是网络的一种安全机制，是用来解决网络延迟和阻塞等问题的一种技术。在正常情况下，如果网络只用于特定的无时间限制的应用系统，并不需要QoS，比如Web应用，或E-mail设置等；但是对关键应用就十分必要。当网络过载或拥塞时，QoS 能确保重要业务量不受延迟或丢弃，同时保证网络的高效运行。当网络发生拥塞的时候，或者网络处于连接弱通信的情况下，所有的数据流都有可能被丢弃；为满足用户对不同应用不同服务质量的要求，就需要网络能根据用户的要求分配和调度资源，对不同的数据流提供不同的服务质量：对实时性强且重要的数据报文优先处理；对于实时性不强的普通数据报文，提供较低的处理优先级。

“按需”服务的发布/订阅机制本质上是一种面向大规模分布式计算的通信范型，相应的系统实现简称为Pub/Sub系统。与传统的通信范型（如消息传递、远程过程/方法调用、共享空间等）相比，该范型具有异步、多点通信的特点，可使通信的参与者在时间、空间和控制流上完全解耦，能很好的满足大型分布式系统松散通信的需求。

基于订阅发布的QoS策略同步模型可以从三个层次上来考虑，即应用层、中间件层和网络层。在应用层，终端参与协作和分布式应用，需要访问和使用分布式资源，必须满足相应的QoS需求，使用QoS管理方法协调与确保应用和服务之间及时交互。而网络层QoS提供系统配置以及连接Pub/Sub系统的发布者、订阅者和中间件框架，使用度量函数获取的观察值，包括网络延时、带宽和交付保证。该层是模型的下层。中间件层QoS则控制Pub/Sub系统行为，主要由发布者QoS和订阅者QoS两类组成，服从“发布者提供-订阅者请求”模式。

图6是数据同步模型结构图，数据的发布者在网络上发布数据，同时数据用户描述数据需求，从网络上获取数据。数据发布者和数据订阅者之间是一个数据同步服务。数据同步服务把发布者所发布的数据的描述与订阅者所需求的项匹配，并按要求传送数据。

在此模型中，服务中心和终端可以是订阅者，也可以是发布者。服务中心订阅自身所需同步的数据，同时可以发布自身保有的数据供其他服务中心和终端订阅。终端由于资源和环境所限，极少作为发布者在模型中呈现，大多数情况下作为一个订阅者而存在。因此，多个服务中心可以互为备份，在极端情况发生如服务中心被毁时能够互为替代。此外，终端对热点数据的获取的途径更加可以多样化，同时能够降低服务中心的访问压力，降低终端请求的响应耗时。

本模型基于QoS策略，主要原因在于在数据同步过程中，业务的实际带宽占用量的变化是一组非线性时间序列，其固有的自相似性、突发性等复杂特性给预测带来了很大的困难。各种业务模型复杂多变，甚至无法预知。而发布/订阅机制为有效预测数据同步过程中业务的带宽需求提供了可能。在基于发布/订阅的数据同步中，业务的信息分发数据传输量，可在对其订阅请求所匹配的事件结果进行定量分析的基础上，结合数据传输的实际有效负载进行测量。在提供的众QoS策略中，许多是与订阅需求量化计算相关的，包括：可靠性、数据的持久度、数据的历史记录、周期数据的超时、数据的有效期、数据的所有权、基于时间的过滤。借鉴RTI DDS的相关技术思想，采用全局一致的发布主题表记录所有事件的来源信息（发布者），而各服务中心自身维护的、独立的订阅登记表则记录与该服务中心相关的订阅路由表。由于发布/订阅活动的结果被实时记录在订阅登记表中，那么通过发布主题表就能有效的检索出所有订阅结果的元数据信息。具体而言，发布主题表可以用PT_Table（ID，P_IP，QoS）表示，它记录了所有发布主题的状态信息。其中：ID为发布的主题的域内唯一标识；P_IP为发布者地址；QoS为相关的服务质量保证。订阅登记表可以用SR_Table（ID，S_IP，QoS）表示，它反映了当前订阅该节点的订阅信息。其中：ID为订阅主题的域内唯一标识；S_IP为订阅者地址；QoS为相关的服务质量保证。

需要特别说明的是，在数据同步过程中，用户的动态订阅请求，可划分为“基于时间驱动的”和“基于数据驱动的”两类。前者强调的订阅获取的周期性，这和DDS规范相一致，在获取相关订阅结果的元数据信息后，就能根据事件的数据量元信息和传输间隔等QoS信息，有效地量化出该订阅请求对应的通信带宽资源需求。然而之所以是动态的订阅请求，是因为在某个时间点上，针对相同的订阅请求，系统中符合要求的信息可能不一样，该数据的种类和具体数据项都是在动态变化的。所以“基于数据驱动的”订阅请求实际上在后台计算中是实时计算的，同时会影响“基于时间驱动的”订阅需求的量化结果。因此，基于发布订阅的QoS策略同步模型的订阅需求量化计算，可以认为是基于发布/订阅行为的元数据（QoS信息）和发布/订阅结果的元数据相结合进行量化计算的过程。

（e）使用客户端连接任一所述服务中心，当目标服务存在于所述服务中心内时，所述客户端采用直连模式访问所述目标服务；当所述目标服务不存在于所述服务中心内时，所述服务中心通过代理向目标服务所在的所述服务中心发起访问请求以访问所述目标服务。

战术级计算服务因其运行环境的复杂性和可能面临的威胁，其可用性和鲁棒性设计更重要，故服务中心应多于一个，且中心之间为对等关系，并具有互为备份的能力。计算服务抗毁接替示意图如图7所示。

服务中心间的服务接替支持代理和直连2种模式，当客户端连接某个服务中心且目标服务存在于该中心时，此时客户端采用直连模式访问该服务；当客户端连接某个服务中心，且目标服务不在该中心内时，该中心会通过代理向目标服务所在的中心发起访问请求，此时客户端采用代理模式访问该服务。多个服务中心间通过无中心的数据同步机制进行服务目录同步，即服务中心A、B、C、D会实时同步彼此的服务目录。当服务中心D被摧毁后，它将无法继续与其他服务中心进行数据同步，至此，仅A、B、C三个服务中心进行服务同步；原先D服务中心上的服务会通过跨中心的任务调度系统调度到其他服务中心上（例如B中心），此时如果客户端连接服务中心A访问该服务，A会到服务目录中进行搜寻，一旦发现该服务由服务中心B接替，则ZS服务中心A将服务访问通过本中心内的服务代理转发到服务中心B上，由服务中心B内的服务代理执行服务访问等操作，实现服务在服务中心间的抗毁接替。

上述跨中心服务抗毁接替功能依赖于服务目录信息的同步。服务目录信息的同步依托一个无中心的数据同步模型。具体上，每个服务中心都通过数据库记录同步消息的状态，每一条数据包含源服务中心和目标服务中心的IP地址信息、同步数据的信息（来自于哪一个数据表，标识数据的ID号）、数据的处理标志位（未同步、同步失败以及同步成功）、数据创建的时间和同步的操作类型（添加、删除、更新）等字段。

同步工具将本地服务注册信息推送到其他服务中心，同步操作完成之后返回一组操作是否成功的标志，本地服务中心根据这组标志更新相关服务注册信息的同步状态。在该模式下，各服务中心相互之间完全独立，只处理本地数据。由此，每个服务中心在物理结构层次上的地位是对等的，弱化了服务中心间的概念，实现了物理结构模式下无中心的架构，使得各服务中心的服务注册之间能够直接进行服务注册信息同步共享。

基于无中心的数据同步模型, 各个服务中心的元数据库都需包含全局路由信息以及所收集的服务注册数据，需要同步的服务注册信息都有一个能唯一标识的字段。整个机制从横向上来看，所有服务中心组成一个网状结构，假设有N个服务中心，若某个服务中心上的服务注册有数据更新，那么同步机制主动调用其他N-1个服务中心的元数据服务实现服务注册信息的同步。从纵向上来看，各个服务中心的服务注册数据同步的机制由元数据库、同步工具、元数据服务组成，同步工具获取数据库中的同步数据，调用目标服务中心的元数据服务实现服务注册信息的同步共享，并根据返回的同步结果更新本地消息的状态。如图8所示，用A、B、C、D模拟分布式环境下的4个服务中心 , 每个服务中心上的同步工具间隔性的探测数据库中的数据变化，一旦捕捉到新的消息，就实施数据同步。

上述实施例只为说明本发明的技术构思及特点，其目的在于让熟悉此项技术的人士能够了解本发明的内容并据以实施，并不能以此限制本发明的保护范围。凡根据本发明精神实质所作的等效变化或修饰，都应涵盖在本发明的保护范围之内。

Claims (8)

1.一种恶劣环境下提供稳定计算服务的方法，其特征在于，它包括以下步骤：

（a）对各服务中心构建计算服务管理框架，所述计算服务管理框架包括计算服务调用单元和计算服务运行支撑单元；

（b）在各所述服务中心之间建立计算服务交互协议和计算服务重发补偿及安全认证机制，使各所述服务中心之间为对等关系且具有互为备份的能力；

（c）在每个所述服务中心内，依托容器技术并采用所述计算服务管理框架创建服务实例；

（d）采用主题订单及发布订阅机制在相互通信的所述节点间进行数据同步；

（e）使用客户端连接任一所述服务中心，当目标服务存在于所述服务中心内时，所述客户端采用直连模式访问所述目标服务；当所述目标服务不存在于所述服务中心内时，所述服务中心通过代理向目标服务所在的所述服务中心发起访问请求以访问所述目标服务。

2.根据权利要求1所述恶劣环境下提供稳定计算服务的方法，其特征在于：步骤（a）中，所述计算服务调用单元包括服务同步调用模块和服务异步调用模块，所述计算服务运行支撑单元包括服务监控模块、服务代理模块、服务管理模块、数据同步模块和服务注册模块。

3.根据权利要求1所述恶劣环境下提供稳定计算服务的方法，其特征在于：步骤（b）中，采用所述计算服务交互协议对服务请求和响应数据进行编解码。

4.根据权利要求3所述恶劣环境下提供稳定计算服务的方法，其特征在于：步骤（b）中，所述计算服务交互协议采用二进制报文压缩算法。

5.根据权利要求1所述恶劣环境下提供稳定计算服务的方法，其特征在于：步骤（b）中，所述计算服务重发补偿及安全认证机制在服务间使用断线重连、超时重发、异常重发和服务方报文校验手段确保在断线和丢包情况下正确处理服务请求。

6.根据权利要求2所述恶劣环境下提供稳定计算服务的方法，其特征在于：步骤（c）中，所述服务注册模块接收所述服务中心内各个节点向其注册当前本节点上正在运行的计算服务实例信息。

7.根据权利要求6所述恶劣环境下提供稳定计算服务的方法，其特征在于：步骤（c）中，所述服务监控模块监控节点上各个计算服务实例的运行状态。

8.根据权利要求6所述恶劣环境下提供稳定计算服务的方法，其特征在于：步骤（c）中，所述服务管理模块负责管理中心内正在运行的计算服务实例，根据计算服务实例的注册和监控信息，动态更新计算服务的部署信息，并通过容器完成计算服务的提交更新。

Images