窄带环境下的远程分布式服务调用优化与验证方法

李佳锋，聂坤明，胡春燕，周 武

（北京航天晨信科技有限责任公司，北京 100854）

0 引言

21 世纪以来，世界军事朝着网络中心战方向发展，美军建立了以全球信息栅格为基础、网络使能指挥控制为核心的网络中心化指挥控制系统［1］。通过网络化指挥控制系统的粘合倍增作用，使火力、机动力、信息力、保障力等各种作战要素的局部能量和综合效果成倍提高，进而生成具有倍增效应的整体作战能力［2］。网络化指挥控制不仅依赖于外部网络还依赖于车内局域网、电台等窄带通信环境［3］。窄带环境因具有带宽窄、速率低、收发转换时间长、传输时延大等特点，限制了系统间的互操作能力，阻碍了作战空间中时敏作战行动［4-5］，因此，针对窄带环境存在的问题，对窄带环境下的服务进行优化，能够提高服务对窄带通信的适应性。指挥控制系统中各服务对通信环境的适应程度决定了服务的可用性。

现阶段在窄带通信环境下分布式服务仍有许多问题无法得到有效解决。如：服务地址获取失败问题、调用服务失败问题和难以访问注册中心等问题，这些都制约了分布式服务在窄带环境下的使用。针对上述出现的问题，本文提出了窄带环境下的服务优化方法，并通过实验进行了验证。

1 研究现状

于子恒等［6］在建设新型机动式指挥控制系统装备中提出针对复杂条件下非稳定传输的自适应管控，采用资源虚拟化映射、资源切片、窄带宽可靠传输等技术，对链路资源和传输质量进行管控，实现通信的高效与可靠。

吴珊娜等［7］使用Hessian 协议实现轻量级的面向服务架构的集成方案，具有数据交换效率高、过防火墙能力强、远程网络通信能力强特点。Hessian协议是一个轻量级的、自描述的二进制RPC 协议，保温在HTTP 封包中，通过HTTP 信道传输，可不受防火墙的限制，适用于传输二进制数据，数据量小，无须继承相关协议。

金欣等［8］基于对服务化理念的重新认识，提出了一种“通用框架+专用服务+ 具体模型”的服务化指挥控制系统架构，灵活加载指控服务和模型，实现跨军种统一指挥和灵活适应多样化任务。

周晓明等［9］针对指挥控制系统的通信复杂性，提出了窄带网络的SOA 实现技术，建立了SOA 传输协议、消息格式和Web 显示标准，提出了3 种实现方法，一是通过压缩软件对服务和客户之间交互信息的压缩减少网络传输；二是研究制定适应战术条件下的信息交换模型，采用指挥控制代码减少传输信息的数量，减少信息的重复和冗余；三是在跨网连接中采用代理软件，过滤功能来提高窄带网络的传输效率和可靠性。

刘银良等［10］针对窄带环境下报文所占信息量较大，基于HTTP 协议传输的报文容易被截取而存在的安全性问题，提出了作战数据交换模型以及协议间的转换方法，并设计了用于窄带通信的代理软件，既满足了所需的功能又提高了安全性和实时性。

文波等［11］针对军用信息系统的特点，提出了基于标签替换、文档分解和二进制流处理的适用于军用信息系统的XML 文档压缩方法，有效保障了窄带环境下的传输效率。

张瑜等［12］提出基于Nginx C Web 容器和Java Web 容器相结合的区别于传统XML 报文的窄带传输方案提高宽带利用率。

施冰［13］针对TCP 协议在无线链路中存在的缺陷，提出UDP+应用层无连接可靠传输协议，保证了窄带环境下的可靠传输。

上述各类方法对于窄带环境下的分布式服务方法进行了研究，但是没有针对分布式服务调用进行优化，而且缺少对分布式调用的验证方法。

2 系统设计

2.1 RPC 调用原理

RPC（Remote Procedure Call）提出于1983 年，是一种通信标准。对于开发人员来说，封装好的RPC框架是透明的，仅需按照约定的方式就可实现RPC请求［14］。

RPC 技术经历了多个发展阶段，目前的RPC 分布式框架的基本组件可分为3 个部分：服务注册中心，服务提供方和服务调用方。服务注册中心实现服务的注册、调用和负载均衡等操作；服务提供方根据服务规范接口向注册中心注册自己的服务；服务调用方用于向服务注册中心查询和订阅相关服务，并使用合适的策略向服务提供方调用相应的服务［15］。RPC 调用原理示意图如图1 所示。

图1 RPC 调用框架

2.2 远程分布式调用优化方法

窄带环境的特点决定了必须在通用性与特殊性之间作出选择，要根据实际应用环境开展针对性研究。结合战术级机动指挥控制系统中，包含超短波电台、数据链端机带宽通常在几十K 级别的特点，本文提出远程分布式调用优化的研究内容。

2.2.1 基于层次和内容的协议精简方法研究

窄带通信的延迟是一个关键的参数，为了保证协议状态机动作的时效性，从协议方面进行以下两方面的研究：一是减少协议实现和穿越的层次，例如在基于TCP/IP 的协议栈中，可以牺牲一定的准确性而采用UDP 实现，或者基于数据链路层的实现，以尽量减少协议层来提高通信的效率。二是精简协议内容，在上层应用层协议中，通过减少数据包头的大小、减少无关数据和降低预留数据占用率的方法，降低协议的开销。

根据窄带特点，通过对地址空间、消息头和时间戳等内容的精简完成数据包的精简，采用二进制数据编码方式实现提供更高的带宽利用率和窄带通信效率。示意图如图2 所示。

图2 基于层次和内容的协议精简示意图

2.2.2 数据压缩算法的研究

为了提高带宽的占用率、减少冗余数据，本文采用对数据包进行压缩的方法，在一定程度上减少了数据的大小。数据压缩的实质是在结点处理与网络处理之间的一个折衷，通过降低结点同时处理数据的能力，来提高数据的传输效率。通过配置判断是否需要对数据进行压缩，流程如图3 所示。

图3 可定制压缩算法流程

2.2.3 小数据包聚合大数据包拆分方法的研究

在低带宽高延迟的链路上，数据包的大小会影响数据传输的效率。如果将多个小数据包聚合成一个标准数据包，将大大减小交互次数，提高传输效率。因此，可以通过对指挥控制软件窄带通信应用特点的分析，根据服务质量要求对特定数据包进行聚合或拆分，以提高带宽利用率。

通过提供动态自适应的聚合策略，如图4 所示，根据当前传输链路的带宽和稳定性，综合服务质量要求，采用匹配的数据包聚合策略。策略的主要影响因素有数据实时性要求和当前通道的阻塞程度。若数据有强实时性要求，则直接传输该数据；若否，则根据当前传输通道的阻塞程度选择不同的聚合粒度。

图4 自适应聚合策略

2.2.4 按需服务传输通道动态切换技术研究

在窄带通信环境中，各节点运行在动态、不稳定的网络环境中，通过动态感知链路状态，根据业务质量要求，动态切换底层传输协议保证业务逻辑的正常工作。

通过感知服务在一段时间内的延迟情况，在一定时间内服务不可用的比例和当前服务的压力大小判断是否切换服务。当需要切换服务时，则将后续的服务调用地址动态定位到新的服务提供方地址，实现按需的服务通道动态转换。

2.2.5 窄带可靠传输协议优化技术研究

操作系统的底层传输协议算法和参数，主要为高效的传输环境下，但若在窄带环境中传递这些参数存在带宽利用率低、重传率高和失败率高等问题，本文通过对系统参数的调优，降低重传率和提高宽带利用率。

2.2.6 窄带服务发现技术研究

在窄带、动态的网络环境下，研究为服务注册与服务发现提供一个可靠、冗余和网络负载低的服务注册支持，同时研究服务状态在窄带环境下的快速感知技术，以保证服务的可用性。

通过研究智能化服务缓存技术，根据网络状态和服务命中率动态调整服务连接的缓存策略，实现服务查询和定位时间的减少，以及响应时间和服务效率的提高。

通过研究冗余、负载均衡支持的服务注册支持，实现窄带环境下服务注册与服务定位的高效运行，在服务注册中心间使用负载均衡技术，平衡服务定位在网络中的负载，实现保证服务可用性的同时，提高网络带宽利用率。

2.3 具体实现

2.3.1 远程服务调用模块

1）功能描述

远程调用框架是远程服务的基础，它负责提供远程服务远程调用支持，包括服务的描述、服务的查找定位，服务对象的序列化，服务调用框架等内容。

2）流程逻辑

客户端通过ServiceProxy 对象对服务进程访问，请求被对象代理将服务请求进行序列化后发送到网络上；服务端则在某个特定的端口上监听访问请求，由ServiceSkeleton 对象将请求对象反序列化，然后由ServiceRemoteObject 调用具体的服务实现对象ServiceObject。服务对象ServiceObject 处理完成后，进行返回值的序列化再传送到客户端，并唤醒客户调用线程。远程服务调用流程如图5 所示。

图5 远程服务调用流程图

3）接口描述

参照主流RPC 框架实现，在远程服务调用框架中，共有9 类对象，各类及相应的功能为：

①IService：用户接口服务定义，包含标识为@remote 所有接口，全部为纯虚函数。

②ServiceProxy：客户端IService 实现，用来实现序列化与反序列化与及传递请求和网络并负责接收响应信息。

③ServiceRemoteObject：服务端IService 实现，维护着指向真正服务对象（ServiceObject）的指针，并负责将调用重定向到服务对象。

⑤ServiceSkeleton：接收网络请求，实现参数反序列化，并将请求传递到ServiceRemoteObject，再调用服务对象，同时将输出参数和返回值序列化一起发送到网络。

⑥ServiceProxyFactory：简化ServiceProxy 的创建。

⑦ServiceClientHelper：客户端提供的静态方法，在ORB 对象请求代理中查找proxy 对象，也可以通过直接访问获取。

⑧ServiceServerHelper：服务端提供的静态方法，在ORB 对象请求代理中注册服务对象，也可以通过直接访问获取。

⑨ServiceEventDispatcher：事件发布者。

⑩ServiceEvnetSubscriber：事件订阅者。

远程服务调用框架图如下页图6 所示。

图6 远程服务调用框架图

2.3.2 远程对象序列化

1）功能描述

在远程调用模块中，参数需要在远程和本地进行序列化和反序列化操作，本文实现支持基础数据类型、自定义数据类型、消息体以及结构体的序列化和反序列化操作。

2）流程逻辑

序列化的流程按照消息体、结构体和基础类型的层次进行序列化。首先客户端代理对象发起远程调用并触发序列化，由serializeMessageBegin 函数添加消息头和消息类型字段，；由serializeStructBegin函数添加序列化结构头部消息；而后根据模块参数调用TypeSerializer 的serialize 函数，根据不同的类型进行不同的操作，如果是基础类型或列表类型则进行序列化，如果是嵌套类型则重复上述过程。完成后由serializeStructEnd 函数添加序列化结构尾部，由serializeMessageBegin 函数添加消息尾部，完成序列化。序列化流程图如图7 所示。

图7 序列化流程图

反序列化过程则与序列化过程相反，客户端代理对象在接收到网络传输返回消息后触发序列化。首先解析消息头和消息类型字段，而后则调用代码生成器生成的自定义消息的相关函数，再根据模块参数进行相应的操作，如果是基础类型或列表类型则直接进行反序列化，如果是嵌套类型则重复上述过程。结束后再调用代码生成器生成的自定义消息的相关函数，最后验证消息尾部，完成反序列化。反序列化流程如图8 所示。

图8 反序列化流程图

3）接口描述

①DeserializerBase 类接口

序列化和反序列化的基类接口，定义消息类型和传递给序列化和反序列化的元信息属性操作接口。

②Serializer 类接口

序列化接口，定义基础类型、消息类型以及自定义类型的序列化接口。

③BinarySerializer 类接口

基础二进制序列化接口，该类基于binaryWriter实现，消息序列化基于主机本身的字节序实现。为了使反序列化端了解字节序，在消息的开始设置了字节序标志位。其中，二进制序列化没有携带自描述消息。

④TypeSerializer 类接口

复杂类型的序列化模板类，包括容器类如List、Vector、Set、multise、DateTime、UUID 和智能指针等内容。

⑤TimeTypeSerializer 类接口

自定义复杂类型的序列化模板类，实际上是由框架自动生成的模板类。

⑥Deserializer 类接口

反序列化接口，定义基础类型、消息类型以及自定义类型的反序列化接口。

⑦BinaryDeserializer 类接口

基础二进制反序列化接口，该类基于binaryReader 实现。

⑧TypeDeserializer 类接口

复杂类型的反序列化模板类，包括容器类如List、Vector、Set、multise、DateTime、UUID 和智能指针等内容的反序列化模板类。

⑨TimeTypeDeserializer 类接口

自定义复杂类型的反序列化模板类，实际上是由框架自动生成框架生成的模板类。

2.3.3 服务注册代理插件

1）功能描述

服务注册代理插件作为软件平台内的服务注册代理，在注册中心未连接时，提供注册代理功能，在连接后自动帮助用户注册或注销远程服务。同时进行服务注册中心状态检测、远程服务续租等工作。

2）流程逻辑

当远程服务注册代理插件类RemoteService-WatchDogBundleActivator 被激活时，首先创建远程服务接口对象RemoteServiceInterface，接着创建注册类对象RemoteServiceRegisterDelegateImp，并向本地服务注册中心注册服务。然后注册代理插件类创建定时器对象，调用RedisPublisher 对象，用于定时处理注册代理事件及服务续租事件。安全验证子模块时序图如图9 所示。

图9 安全验证子模块时序图

3 验证及结果分析

3.1 工具介绍

3.1.1 软件工具介绍

本文使用两个不同的网络模拟工具软件来验证低带宽下服务获取和调用的可靠性，确保实验的可靠性。两个工具分别是Network Emulate for Windows Toolkit（简称NEWT）和Shunra VE SMB。

1）NEWT

NEWT 是一个简单实用的网络模拟工具软件。最初是微软内部为搭建网络模拟服务于网络的研究工作而开发，之后将NEWT 的核心代码先后成功地转移到了微软的相关产品中，便广泛运用于用户中［16］。

在使用该软件的过程中发现该软件不支持Windows 10 操作系统，故本文将该软件部署在装有Windows 7 操作系统的电脑上。

2）Shunra VE SMB Edition

Shunra VE SMB Edition［17］是一种专为中小规模企业设计的网络仿真软件产品，模拟了本地实验室中的点对点的连接。它可以用来测试、对比或预测在不同网络条件下，时延、抖动、丢包、带宽、应用程序或设备在WAN 链路上的性能。

在使用过程中发现，该软件仅支持Windows XP操作系统，所以本文将该软件部署在装有Windows XP 操作系统的电脑上。

3.1.2 硬件设备介绍

完成本文实验共使用了3 台电脑和1 台交换机。交换机用于实现不同电脑间的网络连接，使用交换机作为中间设备更符合实际工作中的情况。因为若采用直接通过网线连接两台物理机虽然会大幅降低网络延迟，但是会使得测试的准确性降低。

三台物理机中，其中，两台为Windows 7 系统，一台为Window XP 系统。两台Windows 7 系统的物理机分别作为分布式系统的客户端和服务端。在使用NEWT 作为网络环境模拟工具时，仅需上述两台物理机即可完成本文所做的实验，NEWT 既可布置在客户端也可布置在服务端，通过相关设置即可实现对带宽的模拟。在Shunra VE SMB Edition 网络模拟环境中，Windows XP 系统的物理机是专门用来放置Shunra VE SMB Edition 网络模拟软件，该软件需要一个专门的中间机以实现网络情况的模拟，而且仅支持Windows XP 系统，两台Windows 7 系统任选一台作为客户端，另一台作为服务端。

3.2 验证方法

本文所测试的是1 个分布式平台，分为客户端和服务端两部分，服务端中共有3 个可调用的服务。本文以这3 个服务的调用情况作为实验的测试数据，分别测试在不同带宽下的服务调用时间以及服务调用的频次；测试在何种带宽下会出现客户端获取3 个服务的服务地址失败，导致无法获取服务的情况，并统计在不同带宽下运行10 次客户端中从出现1 个、2 个、3 个服务地址获取失败的次数，以及在10 次获取服务地址成功的情况下，测试出现服务调用失败的情况（原因为调用超时），统计不同带宽下服务调用失败的次数。其中，将客户端获取3 个服务地址全部成功设为获取服务地址成功，将客户端调用3 个服务全部成功设为调用服务成功。

3.3 实验结果分析

3.3.1 NEWT 实验结果

在以NEWT 作为网络模拟工具时，在手动开启客户端应用程序10 次的情况下得到获取服务地址失败的次数，以及在低带宽条件下获取服务地址成功时服务调用失败（调用服务超时）的次数，重复10 次。

1）调用服务失败

调用服务失败出现的错误提示是调用服务超时，且失败后直接导致客户端与服务端断开连接，相关活动被迫直接结束，所以这是一个严重影响分布式系统在窄带环境下顺利运行的关键问题。

如表1 所示，在以NEWT 为网络模拟工具时，出现服务调用超时的情况大概是在30 kb/s。而在实际应用中，所使用的最低带宽为64 kb/s，因此，可以认为该优化方案具有良好的表现，所以不再做低于30 kb/s 下测试。

表1 10 次低带宽下获取地址成功中调用服务失败次数

2）获取服务地址失败

获取服务地址失败出现的错误提示是查找远程服务失败，该错误会导致无法获取该服务信息也无法完成与该服务有关的工作，但并不影响其他服务的运行情况，即不会直接断开客户端与服务端的连接，其他获取服务地址成功的客户端应用仍可访问服务端服务。

如表2 所示，在100 kb/s 左右时会出现获取一个服务地址失败的情况，并在95 kb/s 时便会大概率获取一个服务地址失败。虽然在100 kb/s 时，10 次中失败的次数就达到了6 次，但是根据测试发现在105 kb/s 时也没有获取失败的情况。

表2 获取一个服务地址失败的次数

如表3 所示，在70 kb/s 时，会出现获取两个服务地址失败的情况，在55 kb/s 左右时，获取两个服务失败的情况会大概率出现。此时，尚未出现3 个服务地址全部获取失败的情况，但带宽已经低于64 kb/s，已可以满足需求，故不再做关于3 个服务地址均获取失败的实验。

表3 获取两个服务地址失败的次数

3）服务调用时间

该测试数据主要判断不同的带宽对服务调用时间的影响，在服务地址获取成功以及服务调用成功的情况下测试获得的数据。该结果是将3 个服务各运行5 000 次得到的平均结果。调用时间是指从到客户端请求服务到客户端调用3 个服务全部成功各1 次所需的时间，调用频次是指在1 s内；其中一个服务从客户端请求到调用成功的平均次数。

由表4 可以看出，随着带宽的降低，调用时间不断增加。

表4 不同带宽下3 个服务调用成功所需时间

3.3.2 Shunra VE SMB Edition 实验结果

1）调用服务失败

在Shunra VE SMB Edition 模拟软件中继续重复上述实验获得测试数据如表5 所示。在该网络模拟环境下，在40 kb/s 左右会出现服务调用失败的情况，在35 kb/s 左右服务难以调用成功。

表5 10 次低带宽下获取地址成功中调用服务失败次数

2）获取服务地址失败

如表6 所示，在该网络模拟环境下，在175 kb/s 左右时，便会出现服务地址获取失败的情况，在165 kb/s左右时，便会大概率出现失败的情况。

表6 获取一个服务地址失败的次数

如表7 所示，在115 kb/s 左右便会出现两个服务调用失败的情况，在105 kb/s 左右便会出现大概率失败的情况。

表7 获取两个服务地址失败的次数

如表8 所示，在70 kb/s 左右便会出现两个服务调用失败的情况，在50 kb/s 左右便会出现大概率失败的情况。

表8 获取3 个服务地址失败的次数

3）服务调用时间

表9 不同带宽下3 个服务的调用时间及频次

3.4 实验结果分析

通过两种不同网络环境模拟工具的测试可以发现，窄带环境下的远程分布式服务调用优化方法具有良好的效果，在服务调用方面可以满足实际工作需求，但是在服务地址获取方面，还需要继续改进，以满足在极端环境下的服务可用性。虽然两种网络模拟软件的测试数据有不少差异，但是从定性上看，结果是一致的。该优化方法在窄带环境下的获取服务地址能力仍有一些不足。

4 结论

本文介绍了一种窄带环境下远程分布式服务调用的优化方法，介绍了其实现原理和方法，并通过实验验证了该方法的有效性。在服务调用方面有良好的表现，但在服务获取方面还需要进一步优化。服务获取成功是服务调用的前置条件，所以服务地址的获取不容小视，本文后续还将从数据库存取、查询速度等方面继续做一些服务获取的优化工作。