一种基于服务的在线软件架构初步设计
李瑾1,2,3，顾旻皓1,2，李飞1,2，朱科军1,2
(1.核探测与核电子学国家重点实验室，北京 100049；
2.中国科学院高能物理研究所，北京 100049；3.中国科学院大学，北京 100049)
摘要：大型高能物理实验数据获取系统需要一套分布式在线软件负责完成集群环境中进程管理、信息共享、状态跳转控制、运行配置等任务。本文研究内容包括：1.设计初衷以及设计思路提出的背景，并明确设计目标；2.设计基于服务架构的分布式在线软件框架，选用高性能通信库ZeroMQ和信息序列化软件ProtoBuffer作为框架实现的底层工具包；3.核心功能模块的设计和实现。
关键字：在线软件 服务 分布式

数据获取系统（Data Acquisition，DAQ）在现代高能物理实验中是一个非常重要的课题。在高能物理实验迅速发展的几十年间，数据获取系统也经历着架构从简单到复杂，性能快速提升的进化过程。DAQ的任务是读出通过触发判选的事例数据，进行事例包装和过滤，做相应的数据处理后将数据记录到永久介质上，同时给出各种性能和状态的监控图形。
DAQ的在线软件（online software）部分是指全局中保障数据流软件正常运行的软件系统，其作为整个DAQ系统的管理者，向DAQ提供管理、控制、配置、监控以及在DAQ各组件内部交换信息的功能，为整个DAQ的正常运行提供基础架构[1]。
论文将对基于服务架构的数据获取在线软件设计的初衷和背景进行详细说明，明确设计目标，提出并分析设计思路，对核心模块进行初步功能实现。
1	设计初衷和背景
著名的高能物理实验ATLAS开发了功能全面且强大的TDAQ（Trigger DAQ）分布式软件用于实验的数据获取系统；国内的大亚湾中微子实验和BESIII（Beijing Spectrometer III）的数据获取系统数据流部分在借鉴ATLAS TDAQ软件框架的基础上根据实际需求设计完成，在线软件则部分重用了ATLAS TDAQ的相关组件。所以，ATLAS TDAQ框架中的在线软件切实保障了不同实验的数据流系统的正常运行。但是，随着技术的发展和实验需求的变化，ATLAS TDAQ软件框架的劣势也逐渐显现，尤其是在线部分采用CORBA作为底层通信协议。CORBA距今已诞生二十多年，其采用的是RPC（Remote Procedure Call）方式，需要将服务设计和部署为远程对象，并建立代理控制目标节点机上的应用，直接导致整个系统冗余庞大，模块之间耦合度高，很难独立进行代码重构和优化。CORBA的缺点主要体现在一下几点： 
1)	其规范巨大且复杂，实现其所有标准的代码库是庞大的，而实际上ATLAS TDAQ中的通信框架也只是使用CORBA标准中的一小部分，但却要因此去掌握CORBA的全部功能；
2)	CORBA的一些库（比如CORBA的JAVA实现库JacORB）并没有完全实现全部的功能，导致了C++和JAVA功能上的不匹配；
3)	会产生不必要的信息传递，消耗了大量内存和时间；
4)	CORBA是基于IDL语言的，耦合度高，难于控制和开发，不宜于扩展；
5)	不宜学习和快速部署，导致开发周期长、易出错，在业界的使用也越来越少；
包括CERN，现在也在调研比较性能更好、更轻量的消息中间件来代替CORBA。图1是CORBA与其他几种消息中间件的比较[2]。从图中可以看出，CORBA与当前流行的几种中间件在性能、资源消耗、用户体验和技术支持等方面的劣势比较明显。

图1 几种中间件的总体比较
所以，选择一种可以替换CORBA的消息中间件，并设计出轻量级、低耦合、模块化、易动态控制、具有通用性的分布式数据获取在线软件的目标便提出来了。
2	分布式在线软件的设计思想
2.1	基于消息的通信模式
对于有多个模块的分布式在线软件系统来说，其支撑基础无疑就是对消息的处理，尤其是当面临异构系统时，分布式的调用与通信变得尤为重要。消息需要在不同的模块之间进行传递，并可能会被多个完全不同的客户端消费。在众多分布式技术中，消息传递相较文件传递与RPC而言，功能上更胜一筹，因为它具有更好的平台无关性，并能很好的支持并发和异步调用。图2所示为几种消息中间件的性能比较[2]，图中柱状体代表1s内不同消息中间
件发送和接受消息的数目。从图中可以看到，ZeroMQ[3]在单位时间的吞吐量远远超过其他几种消息中间件。

图2 几种消息中间件的性能比较
ZeroMQ是一个面向消息的、开源的、跨语言的、非常高性能、简洁灵活的网路通信库，是网络协议栈中的新的一层，分散在分布式系统间。其特点如下：
1)	简单：ZeroMQ是面向消息的中间件库，它类似于标准的Berkeley套接字，但封装掉很多东西，免去了开发人员的很多麻烦。
2)	灵活：适合多种通信环境（进程内、进程间、跨主机），由于其API设计的很好，以至于只需修改很少的代码就可以适用于不同的通信环境，且支持多种通信模式：request-reply，publish-subscribe等等。
3)	跨语言：支持C、C++、JAVA、C#、PHP、Python等等多种语言，易于扩展。
4)	高性能：首先ZeroMQ是C/C++开发的，且本身的协议格式定义简单，和传统的socket API相比性能上不相上下，但是传统的socket API在连接中断的情况下，会丢失信息，ZeroMQ并不会这样，这主要得益于基于消息的通信机制。所以，如果在线软件部分中一个模块或一台机器出现故障，并不会影响其他模块的工作，满足低耦合、易控制的设计目标。
由于ZeroMQ传递的是二进制串，对于结构化数据的传递，采用google开发的开源序列化工具Protocol Buffers[4]进行数据的序列化和反序列化。Protobuf相较于常见的json或xml来说，时间开销和空间开销小，针对在线软件中需要频繁传递的结构化信息需求来说大大提高了传递效率。对于不同的结构化数据，需要定义不同的proto文件来进行描述。
2.2	基于服务的软件架构
分布式系统通常能够缓解单个服务器的压力，通过将不同模块以不同的服务形式部署在不同的服务器上，就可以有效的分配和利用服务器资源。在这种情况下，部署在不同机器上的服务，即可作为服务器端，用以处理客户端的请求，也可作为客户端，在处理完自己的任务后，将剩余任务请求委派给其他业务。在基于服务的架构语境中，“模块化”指的是将应用的各个部分分别封装为自包含的服务的做法。拆分后的每个服务都可以单独设计、开发、测试和部署，与其他组件或服务之间的依赖性很低甚至没有，其变更管理和维护也更容易，从而使得相应的应用也更稳定，响应也更快。
服务是整个分布式在线软件的基本组成。一个服务包含请求者和服务提供者两个部分。请求者向服务端发送请求消息，服务端收到请求后会有以下两种处理方式：1.根据请求内容执行对应的数据处理并将处理结果发送到请求端；2.如果不能解析请求格式就会忽略该请求，并发送相应的错误报告。图3为基本的服务请求应答模式。

图3 基本的请求/应答模式
3	核心功能模块的设计
如图4所示为软件的整体架构，采用分布式方案，模块之间通信来进行交互。分布式架构有很多优势，包括可伸缩性、解耦能力以及对开发、测试和部署的可控性等。APP_Helper（用户应用程序辅助类库）是用户APP的基本库，每一个APP继承自该库中虚基类；CFG（配置服务）是解析XML格式配置文件，为框架和用户APP提供配置信息查询、修改等服务；PMG（进程管理服务）运行在每个节点上，监控本节点APP的运行；Controller（控制服务）全局只有一个，调用PMG服务启动、终止用户APP，控制框架软件和用户APP状态机跳转；IS（信息共享服务）提供查询和订阅两种模式，可以保存各种状态和监控信息；SR（注册服务）提供以上各框架基础服务或用户自定义服务的注册和查询功能。

图4 数据获取在线软件的整体结构
3.1	注册服务
服务注册SR（Service Register）是整个在线软件中最先启动的服务，其内部维护一个服务列表。该服务提供注册服务、取消注册服务、查询等功能，当服务列表有更新的时候，会发布相应的信息。如图5所示为注册服务的功能实现框图。SRTool是服务的请求者，SRHandler是服务的提供者，checkthread实时检查服务的状态。

图5 注册服务的功能实现框图
3.2	信息服务
信息服务IS（Information Service）是在分布式系统的各个进程之间提供共享信息服务，采用信息提供者-信息仓库-信息发布者-信息订阅者的方式。

图6 信息服务的功能实现框图
3.3	进程管理
进程管理PMG（Process Manager）在每个节点上都会运行一个PMG来对该节点进行基本的作业控制，对目标节点上的程序进行启动、停止和状态查询等，因此PMG服务传送的数据也有命令信息和状态信息两种格式，服务端根据不同的信息执行不同的操作。图7是进程管理的功能实现框图。

图7 进程管理服务的功能实现框图
3.4	配置服务
配置服务（Config Service）实现DAQ中大量运行参数的配置。服务端通过xml文件存储数据，使用xsd[5]进行xml文件解析，解析后的数据经过protobuf序列化为二进制串后进行传输，请求端收到二进制数据串后反序列化，得到原始数据，从而完成一次完整的配置。配置服务提供ID、TYPE、正则匹配等多种方式的查询服务。
3.5	运行控制服务
运行控制（Run Control）调用配置服务、进程管理服务、注册服务来对整个在线软件进行运行控制。

图8 运行控制服务的功能实现框图
4	结论
目前在线软件系统已完成核心模块的初步功能实现，可以配合数据流部分完成基本的运行控制和状态显示。
参考文献：
[1]ATLAS High-Level Trigger，Data Acquisition and Controls Technical Design Report.2003
[2]MIDDLEWARE TRENDS AND MARKET LEADERS 2011, CERN-ATS-2011-196
[3] http://zeromq.org/
[4] https://developers.google.com/protocol-buffers/
[5] http://codesynthesis.com/products/xsd/
A Preliminary Design of a Service - based Online Software Architecture
LI Jin1,2,3，Gu Min-hao1,2，LI Fei 1,2，Zhu Ke-jun1,2
(1.State Key Laboratory of Particle Detection and Electronics，Beijing 100049；
2.Institute of High Energy Physics, CAS, Beijing 100049；3.University of the Chinese Academy of Sciences，Beijing 100049)
Abstract:The data acquisition software of large-scale high-energy physics experiments require a set of distributed middleware (online software) to accomplish process management, information sharing, status controlling, monitor and configuration tasks in the computer cluster environment. The contents of this paper are as follows: 1. The original intention and background of the design as well as explicit design goals; 2. The distributed online software is designed based on service architecture using high-performance communication library ZeroMQ and information serialization tools ProtoBuffer as the bottom layer. 3. Core functional modules preliminary implementation.
Key Words：Online-software  distributed-system  service