面向服务的测量船测控服务总线系统*

李永刚，李祥明，吴 云，杨海民，毛 文

(中国卫星海上测控部,江苏 江阴 214431)

1 引言

测控计算机系统是航天测量船测控系统的神经中枢，是信息交换、处理和分析的关键单元[1,2]。测控软件系统作为测控计算机系统的核心，需要适应当前我国航天任务多样化、测控体制不断拓展、测控设备持续升级等形势，因此对于其扩展性、复用性、互操作性等要求越来越高[3]。传统测控软件系统是基于构件的软件体系结构，各个构件通常都是紧密耦合在一起的，构件之间通过函数调用的方式实现互操作。构件调用时需要知道被调用构件的位置和技术细节，这使得构件的维护和重复使用变得非常困难，因为一个构件中的修改通常会引发其他构件的修改。面向服务的体系架构SOA(Service Oriented Architecture)是一种粗粒度、松耦合的体系结构，其本质上是服务的集合，服务间彼此通信，服务接口作为与服务实现分离的实体而存在，从而服务实现能够在完全不影响服务使用者的情况下进行修改。采用SOA架构可以实现数据和资源的共享，由原来建立专有的单一应用变为建立更为高级和整合的应用，充分利用已有的、可以共享和重复使用的功能。SOA架构的提出，为建立一个灵活可扩展的软件系统[4,5]，对现有资源合理分配等问题提供了解决思路。

本文在分析测量船测控软件系统基础上，设计了面向服务的测量船测控服务总线系统架构，该架构支持“服务调度规则”与“服务调度系统”2种服务调度模式，并成功实现了该系统的服务端、客户端和服务调度，进行了2种模式下的服务调用性能测试，验证了系统的有效性。

2 测量船测控软件系统

测量船测控软件系统主要承担船内各测控设备的引导及测控信息的汇集、处理、交换和显示等任务。测量船测控软件系统由测控支持、外测处理、遥测处理、显示等子系统组成，其中各子系统分别由卫星处理系统和火箭处理系统2部分组成[3,6]。

测控支持子系统主要完成测控信息的汇集和交换。外测处理子系统的核心任务是根据外测数据获得足够精度的目标空间位置和运动参数(瞬时站址地平系或地心系弹道参数)，并给出精度评估结果。外测数据处理主要是对原始测量元素进行物理量纲复原、合理性检验、数据平滑滤波、误差修正等[6]。这些处理结果是航天器性能评定、设计改进的重要依据。遥测处理子系统是对运载火箭和航天器内部各种参数进行测量。对遥测数据进行实时处理，可以监视航天器飞行过程中内部环境情况、设备工作状态及航天员的生理状况。分析遥测数据可以评估航天器的性能，为故障判断和设计改进提供依据[7]。显示子系统主要收集测控过程中处理的状态信息和测控信息，经过相应处理及时在显示器上显示，为决策人员提供依据和手段。测控软件系统作为测控计算机系统的核心，需要适应当前我国航天型号任务多样化、测控体制不断拓展、测控设备持续升级等形势，因此对于其扩展性、复用性、互操作性等要求越来越高。

3 SOA

3.1 SOA基本概念

从软件开发方法演进的角度来看，软件开发技术总的发展趋势是不断加大软件模块的封装粒度，从而使得软件模块间的耦合度减少，SOA的产生是为了适应分布式环境需求的又一种软件开发方式。

关于SOA，目前尚未有一个统一的、业界广泛接受的定义。一般认为，SOA是一个组件模型，它将应用程序的不同功能单元——服务(Service)，通过服务之间定义良好的接口和契约联系起来。所谓服务，就是精确定义、封装完善、独立于其它服务所处环境和状态的功能单元。如图1所示，服务一般独立于具体实现技术细节，封装了可复用的业务功能，通常是大粒度业务，如业务过程、业务活动等；接口是采用中立方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在这样的系统中的各种服务可以以一种统一和通用的方式进行交互[8 - 10]。

Figure 1 Services and their interfaces图1 服务及其接口

3.2 SOA体系架构

SOA体系架构[11 - 13]中的组件一般包括：

(1) 服务提供者：服务提供者即服务的拥有者，负责将服务信息发布到服务注册中心，同时要控制对服务的访问以及服务的维护和升级。

(2) 服务请求者：实现服务的查找与调用。服务请求者首先到服务注册中心去查找满足特定条件的、可获得的服务。一旦找到，服务请求者将绑定到该服务并对其进行实际调用。

(3) 服务注册中心：集中存储服务信息，以便于服务请求者查找。同时，服务提供者可以把其所能提供的服务在服务注册中心进行注册。

上述3种组件所构成的体系架构如图2所示，SOA体系架构中包含的操作主要包括：

Figure 2 Architecture of SOA图2 SOA体系架构

(1) 发布服务：发布服务的描述信息，以便服务请求者发现和调用。

(2) 查询服务：服务请求者通过服务注册中心查找符合其需求的服务。

(3) 绑定服务：在获得服务描述信息之后，服务请求者据此调用服务。

4 测控服务总线系统设计

测量船测控软件系统的设计需求包括2部分，对系统级的若干全局通用功能进行服务化设计，例如软件调度功能(软件启动、软件退出、主副机状态切换等)、软件状态与参数设置(软件功能选择、运行时参数装订等)；对分系统级的若干局部通用功能进行服务化设计，如外测数据处理分系统的电波折射修正与反修正功能、坐标系转换功能、软件参数设置功能等。为适应系统级、分系统级2类层级不同的服务化部署要求，兼容实时性、扩展性、便捷性等需求，本文在吸收借鉴SOA架构设计理念的基础上，设计了测量船测控服务总线系统架构，如图3所示。

Figure 3 Architecture of TT&C service bus system for survey ship图3 测量船测控服务总线系统架构

测量船测控服务总线系统架构为分布式系统中的各个组件提供了一种透明的通信机制，服务端组件通过服务注册、服务运行接口为客户端组件提供服务，或者通过服务请求接口获取服务端组件提供的服务。测控服务总线系统架构实现了“服务调度规则”与“服务调度系统”2种服务注册与调用的模式：

(1)“服务调度规则”模式，通过建立全局的服务调度规则，实现服务提供方与服务注册方之间对于服务规则约定的一致理解，采用直接交互的方式实现服务请求与调用。优点是服务调用效率高，适用于实时性要求高的应用场景，同时由于没有中间的服务管理环节，一般架设于相互信任的服务端和客户端之间，适用于单一软件分系统内部。

(2)“服务调度系统”模式，该模式下客户端与服务端之间需要通过独立运行的服务调度系统进行集中调度。服务调度系统负责维护全局统一的服务路由信息表，将每一个客户端发送的服务请求与对应的服务端相匹配，并将服务运行完毕后的回答信息返回给客户端。除此之外，服务调度系统还提供了功能扩展的平台，可以按需加载服务安全机制、服务监控机制、日志机制等扩展功能。

5 测控服务总线系统实现

基于SOA的测量船测控服务总线系统的实现包括服务端、客户端和服务调度。

5.1 服务端

测控服务总线系统为服务端提供了服务注册、服务运行的接口，使用的关键技术包括多路复用技术和线程池技术。其中，多路复用指的是在一个统一的事件循环中监听给定的多个文件描述符，当其中某一个或多个文件描述符发生可读、可写、关闭等事件时，系统会唤醒事件循环并给出发生的事件集合。

麒麟操作系统提供的多路复用接口函数为：intepoll_wait(int _epfd,structepoll_event*_events,int_maxevents,int_timeout)，其中_epfd为统一的文件描述符，用来监控预先给定的多个文件描述符所发生的事件，_maxevents为每一次事件循环唤醒时返回事件个数的最大值，_timeout为超时时间，为-1时表示永久等待，直到有事件发生。当函数返回时，所发生的事件集合会写入_events参数。基于麒麟操作系统所提供的多路复用接口，测控服务总线系统会为每一个注册的服务生成一个文件描述符，并将它们加入到epoll_wait的等待队列中，当客户端发来服务请求时，对应的文件描述符会发生可读事件，事件循环线程会被唤醒并执行相应的服务函数。服务注册、运行、请求示意图如图4所示。

Figure 4 Registration,operation and request of service图4 服务注册、运行和请求

实际运行环境中，服务端需要同时对多个相同或者不同的服务请求进行并发响应，此时需要用到线程池技术，通过预先启动多个服务运行线程，动态地对epoll_wait等待的事件集合进行细粒度控制来达到并发响应或者串行响应的效果。此过程中用到的关键系统函数为：intepoll_ctl(int_epfd,int_op,int_fd,structepoll_event*_event)，其中_epfd和_event的含义与epoll_wait中的参数含义一致，_fd为需要进行细粒度控制的文件描述符，_op为要对_fd进行的操作类型，可选取值和适用时机如下：EPOLL_CTL_ADD表示将_fd加入到_epfd的监控列表中，在服务注册时调用；EPOLL_CTL_DEL表示将_fd从_epfd的监控列表中删除，在服务注消时调用；EPOLL_CTL_MOD表示更新_fd的状态，更新后_epfd才能重新对_fd进行监控。

每一次服务运行过程中都需要调用，对于并发服务，在服务响应函数执行之前调用该接口，其他线程可以立即响应_fd上其他请求，服务线程池并发响应示意图如图5所示。对于串行服务，则在服务响应函数执行之后调用该接口，在服务函数的执行期间，_epfd不能对_fd进行监控，所以其他线程不会收到_fd上的其他请求。

Figure 5 Concurrent responses of service thread pool图5 服务线程池并发响应

5.2 客户端

测控服务总线系统为客户端提供了2类服务请求接口，分别为同步请求和异步请求。同步请求会阻塞请求线程直至服务端返回结果，图4和图5所示的客户端部分即为典型的同步请求模式。在异步请求模式下，服务请求将会立即返回并继续执行其他处理过程，由服务回答异步处理线程进行后续处理，异步请求模式示意图如图6所示。在异步请求模式中，对回答结果的处理与服务处理流程一样，也用到了多路复用技术和线程池技术，可以对多个相同或者不同服务的回答结果进行并行处理。

Figure 6 Asynchronous request mode图6 异步请求模式

5.3 服务调度

测控服务总线系统的服务调度包含“服务调度规则”和“服务调度系统”2种模式。在“服务调度规则”模式下，通信的双方通过事先约定的路由规则进行匹配，例如使用公开的IP地址和端口，或者使用哈希算法将服务名字符串计算为一个目的地址等方式，该模式适用于互相信任的系统内部组件之间，通信效率高。

在“服务调度系统”模式下，由服务调度系统负责维护全局统一的服务路由信息表，将每一个客户端发送的服务请求与对应的服务端相匹配，并将服务回答返回给客户端。服务调度系统具备访问权限检查、对请求来源进行安全性过滤、记录日志等辅助功能。客户端、服务端双方通过服务调度系统进行通信的处理流程如图7所示。

6 测试与验证

本节对测控服务总线系统分别在“服务调度规则”和“服务调度系统”模式下进行性能测试。测试环境为联想Thinkpad E550笔记本，硬件配置为Intel Core i5 CPU(4核，2.2 GHz),8 GB RAM。

6.1 服务调度规则模式性能测试

服务调度规则模式性能测试主要测试系统在“服务调度规则”模式下的服务调用性能，以调用服务请求发出至服务结果返回所消耗的时间为衡量标准。具体测试方案为：

(1)编写服务端测试程序ServerApp_Rule以提供DemoService服务。由于测试对象为服务总线系统的性能表现，被测服务所提供的具体服务内容与该项测试无关，如果服务本身所消耗的处理时间过长，反而将影响测试结果所展现的意义，因此对DemoService服务进行简化设计，服务内容为将客户端发来的整型数值加1后返回客户端。

(2)编写客户端测试程序ClientApp_Rule，基于“服务调度规则”模式，通过服务总线库接口请求调用ServerApp_Rule提供的DemoService服务，记录从服务请求发出至服务结果返回所消耗的时间，连续不间断调用10万次并求取时间平均值。

测试过程中，通过动态调整客户端测试程序ClientApp_Rule并发请求服务的线程数量，来模拟并发请求DemoService服务的客户数量，动态调整服务端测试程序ServerApp_Rule的服务线程池规模来模拟服务实例的数量。测试结果如表1所示。从测试结果的纵向变化趋势来看，如果保持服务实例的数量不变，随着客户数量的增加，调用时间呈现线性递增趋势，表明调用性能逐渐降低，符合多客户争抢资源带来性能下降的预期。

Table 1 Performance test results of service scheduling rule pattern表1 服务调度规则模式性能测试结果

从测试结果的横向变化趋势来看，如果保持客户数量不变，随着服务实例数量的增加，调用时间整体呈下降趋势，表明调用性能趋于优化，但是优化的程度随线程增加趋于减弱。定性分析其原因，在于所测试的DemoService服务本身消耗资源极小，当线程数量达到一定规模后(超过测试机器CPU内核数量并继续增加)，其带来的性能优化被CPU频繁的线程切换工作带来的损耗所抵消。

整体上看，单次服务调用所消耗的时间在0.1 ms量级，结合实际应用情况，系统在“服务调度规则”模式下的性能表现显然能够满足应用要求。本文在开源企业服务总线Jboss ESB、Mule ESB、ServiceMix ESB和Synapse ESB上分别做了相应的性能测试，结果统计都相差不多。但是，结合自主可控和安全性，以及对国产麒麟操作系统的适应性，本文设计的系统更可取。

6.2 服务调度系统模式性能测试

服务调度系统模式性能测试主要测试系统在“服务调度系统”模式下的服务调用性能，以调用服务请求发出至服务结果返回所消耗的时间为衡量标准。具体测试方案为：

(1) 编写服务端测试程序ServerApp_System以提供DemoService服务；

(2) 编写调度代理测试程序AgentApp转发DemoService服务调度请求与返回结果，不进行IP地址过滤等安全性检测，AgentApp采用“单线程接收服务请求，单线程返回服务结果”的软件架构；

(3) 编写客户端测试程序ClientApp_System，基于“服务调度系统”模式，通过服务总线库接口请求调用ServerApp_System提供的Demo- Service服务，记录从服务请求发出至服务结果返回所消耗的时间，连续不间断调用10万次并求取时间平均值。

测试过程中，通过动态调整客户端测试程序ClientApp_System并发请求服务的线程数量，来模拟并发请求DemoService服务的客户数量，动态调整服务端测试程序ServerApp_System的服务线程池规模来模拟服务实例的数量。测试结果如表2所示。

Table 2 Performance test results of service scheduling system pattern表2 服务调度系统模式性能测试结果

从测试结果的纵向变化趋势来看，如果保持服务实例的数量不变，随着客户数量的增加，调用时间呈现线性递增趋势，表明调用性能逐渐降低，符合多客户争抢资源带来性能下降的预期。同时，该测试结果明显高于表1中相对应的测试结果，这是因为“服务调度系统”模式下，服务请求的发出和服务结果的返回均需经过AgentApp的转发处理，增加了时间消耗。

从测试结果的横向变化趋势来看，如果保持客户数量不变，随着服务实例数量的增加，调用时间下降不明显，表明调度性能的优化效果较为微弱。经过进一步测试和分析发现，该模式下负责服务调度请求和服务结果转发的AgentApp已经成为消耗时间较多的瓶颈环节，这也与AgentApp“单线程接收，单线程发送”架构存在关系。

整体上看，单次服务调用所消耗的时间在1 ms量级，结合实际应用情况，系统在服务调度系统模式下的性能表现能够满足应用要求。本文在开源企业服务总线Jboss ESB、Mule ESB、ServiceMix ESB和Synapse ESB上分别做了相应的性能测试，结果统计都相差不多。但是，结合自主可控和安全性，以及对国产麒麟操作系统的适应性，本文设计的系统更可取。

7 结束语

本文在分析测量船测控软件系统的基础上，针对现有系统复杂性高、不易扩展和维护的现状，设计了面向服务的测量船测控服务总线系统架构，支持2种服务调度模式，包括“服务调度规则”与“服务调度系统”，实现了系统服务端和客户端。测试结果表明：该系统能够充分保证2种模式下的服务调用性能，对提高测量船测控软件系统的效率具有重要意义。