基于RESTful的中间件服务化体系结构及关键技术研究

李富合 高东林 曹宁生

（中国舰船研究院 北京 100101）

1 引言

随着云计算、大数据、人工智能等基础共性技术在船舶平台上的逐步应用，未来的船舶信息平台上将实现各类设备的计算、存储、网络等资源的统一服务化管理，硬件设备资源的服务化管理为云计算环境中软件的服务化提供了基础支撑。目前船舶装备中的软件包含三类：基础软件、中间件［1］和应用软件。基础软件包括固件、操作系统以及硬件模块的驱动程序等，应用软件则囊括了船舶装备上使用的各种定制软件，中间件作为基础软件和应用软件之间的软件，屏蔽了各类不同厂家设备之间的差异，为应用软件提供统一的接口调用。船舶设备中间件实现了包括操控、音视频、显示、人机交互等功能，是船舶装备软件的重要组成部分。

中间件虽然为应用软件提供了统一的接口，但是它们往往独立工作于单一物理设备，容易形成“信息孤岛”［2］。此外，中间件传统的部署模式缺乏灵活性，系统维护难度大。无法满足云计算环境下船舶信息基础平台对软件资源共享、系统动态重构的要求。

本文设计一种基于RESTful的中间件服务化体系架构，通过提供一套开放的RESTfulAPI来实现中间件接口服务化以及中间件部署管理的功能需求。REST（Representational State Transfer）是分布式超媒体系统的架构风格，它采用面向资源的架构，将网络上所有的事物都抽象为资源，通过统一资源标识符（Universal Resource Identifies，URI）来定位和表示资源并进行面向不同资源的操作［3］。资源表述格式的Web服务（RESTful Web Services）是符合REST架构风格的一种轻量级的Web Services。它以更加贴近Web特性的方式实现Web服务。它具有很好的松散耦合性、互操作性和可扩展性。

2 总体设计

2.1 系统架构设计

船舶装备中的中间件软件作为底层软件，它部署在每一台设备上，中间件软件与设备是一一对应的。而应用软件是部署在某一台或几台服务器上，它通过调用中间件来设备信息的获取和设备管理控制。为了实现应用软件对中间件资源的统一调用和管理，系统提出一种使用Web技术来为上层应用软件开放提供一系列RESTful中间件接口调用的服务化体系架构。通过调用中间件接口服务层，应用层软件可以实现分布式调用不同设备上的中间件接口，并能够进行对不同设备上的中间件资源进行统一管理。图1为系统应用场景图。

图1 系统应用场景图

在实际的工程应用中，云主机上的中间件分布具有异构性、分散性、多样性等特点，不同中间件需要部署到不同的云主机上。从平台的开放性和互操作性角度考虑，本系统采用二层架构设计。图2为系统架构图。

图2 系统架构图

与传统中间件体系结构相比，本系统使用B/S（Browser/Server）系统架构，突破了单机限制，满足了在云环境下中间件资源的分布式管理，具有部署简单、管理方便的特性。系统划分成服务器端和客户端两部分。客户端部署在安装有中间件的设备中，它通过加载设备中的中间件来为服务器端提供中间件接口调用服务，它接收来自于服务器端的RESTful接口并返回中间件执行结果。服务器端接收来自于上层应用的RESTful接口，并将接口的执行结果返回给应用程序。它提供的RESTful接口实现了客户端中间件的部署管理、中间件的池化管理、系统管理以及负载管理等功能。

2.2 系统功能设计

2.2.1 客户端功能设计

客户端需要部署到运行中间件的设备中，因此客户端程序基本需要在集群中每一台设备运行，为了降低系统客户端的功能冗余，客户端仅仅保留中间件接口调用功能，它接收服务器端的接口调用请求，调用相关的中间件接口并将中间件执行结果返回给服务器端。

2.2.2 客户端功能设计

服务器端软件可以部署在一台性能较高的服务器中，也可以选择一台客户端设备同时作为服务器。服务器端统一负责各个客户端上中间件的部署管理、服务器端中间件的池化管理、RESTful接口访问负载管理以及系统管理等。

1）中间件部署管理。管理客户端设备上的中间件，包括部署中间件、移除中间件、升级中间件、中间配置参数管理等功能；

2）中间件池化管理。对系统中所有不同类型、不同版本的中间件资源进行统一管理控制，包括上传中间件、下载中间件、更新中间件、中间件版本控制管理、中间件配置管理等功能；

3）系统管理。对服务器端进行管理，包括用户管理、用户权限管理、系统配置参数管理、客户端管理等功能；

4）负载管理。将不同用户、不用应用程序提交的RESTful中间件网络接口分发到不同的设备节点。

3 系统关键技术和实现机制

3.1 RESTful接口设计

3.1.1 资源定义

资源分为以下几类：

1）物理设备资源；

2）中间件资源；

3）中间件接口资源；

4）用户资源。

3.1.2 网络操作定义

系统RESTful接口分为以下四类［4］：

1）GET方法。用户查询已有的资源；

2）POST方法。用户更新已有资源；

3）PUT方法。用户创建新的资源；

4）DELETE方法。用户删除已有的资源。

3.1.3 状态码定义

应用程序调用中间件网络接口时，根据中间件执行结果向用户返回的状态码和提示信息，基本返回状态码定义［5］如下（方括号中是该状态码对应的HTTP请求方式）。

200OK-［GET］：客户端成功返回用户请求的数据，该操作是幂等的（Idempotent）。

201CREATED-［POST/PUT］：用户新建或修改数据成功。

202Accepted-［*］：表示一个请求已经进入后台排队（异步任务）。

204NOCONTENT-［DELETE］：用户删除数据成功。

400INVALIDREQUEST-［POST/PUT］：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的。

401Unauthorized-［*］：表示用户没有权限（令牌、用户名、密码错误）。

403Forbidden-［*］表示用户得到授权（与401错误相对），但是访问是被禁止的。

404NOTFOUND-［*］：用户发出的请求针对的是不存在的记录，服务器没有进行操作，该操作是幂等的。

500INTERNALSERVERERROR-［*］：服务器发生错误，用户将无法判断发出的请求是否成功。

3.2 URL路由设计

系统中的资源分布在不同的物理设备中，为了保证服务器正确将应用程序的RESTful请求准确、快速地发送到相应的设备上。需要制定一套路由规则完成接口的路由，像路由器的路由算法一样，优秀的路由设计可以让URL地址更加简洁和优雅，并且容易被人理解。

常用的路由方法有以下几种：

1）正则路由；

2）规则路由；

3）静态路由（URL映射）。

静态路由直观明了，但不利于URL地址的重用，容易导致配置文件过大，降低地址匹配效率。正则路由使用正则表达式来解析URL地址，并将网络请求重定向到相应的网络程序，虽然正则表达式简洁高效，但正则表达式语法比较复杂，不易入门学习。因此本文使用正则表达式来支持系统可以对URL地址进行路由操作。

在每一个物理节点中设计路由配置文件，配置文件的每一行代表一个路由规则，路由规则定义如下：

‘路由规则’=＞［‘模块名/模块接口’，［‘method’=＞ ‘请求类型’］，［‘匹配参数1’=＞‘变量规则1’，‘匹配参数2 ’=＞‘变量规则2’］……］；

配置文件格式示例如下：

系统会按配置文件中路由规则的顺序依次匹配路由规则，一旦匹配到的话，就会定位到路由定义中的控制器和操作方法去执行中间件接口（可以传入接口相应的参数）。

3.3 客户端设计

3.3.1 接口设计

http：//serverName：port/devices/devID/midwares/midID/interfaces/interfaceName。这是客户端提供给用户的接口格式，参数说明如下。

server Name：服务器端Web域名，也可以是IP地址；

port：服务器端端软件监听端口，默认为Apache默认监听端口80，可通过修改apache配置文件设置；

devices：系统中的物理设备资源；

devID：设备唯一标识。通常由厂商号+设备号+通道号组成，可以唯一标识一台物理设备，dev-ID与设备IP地址的对应关系反映在服务器端的配置文件中；

midwares：系统中的中间件资源；

midID：中间件ID。唯一标识使用的某一个中间件，中间件ID与中间件名称的对应关系反映在服务器端的配置文件中；

interfaces：系统中的中间件接口资源；

interfaceName：中间件接口名称，参见各个中间件技术设计文档。

3.3.2 接口执行流程

考虑到客户端需要部署到每一台设备的实际情况，客户端设计时采用功能最小化原则。因此用户调用客户端提供的RESTful接口并不是直接将HTTP请求发送到客户端，而是发送到服务器端，服务器端先进行权限认证，认证通过后解析接口的URL，并根据其中的devID将请求转发到相应的客户端，客户端调用部署在本地设备的中间件接口并将程序结果返回给服务器，最后服务器将结果封装成统一的JSON数据并返回给用户。

图3 客户端执行流程图

客户端的执行流程图如图3所示。客户端首先判断网络请求是否合法，由于客户端不能进行权限验证，因此它通过判断是否是服务器端发起的网络接口调用来实现，即客户端仅仅接受服务器端的中间件接口调用请求，若请求端不是服务器端，则认为是一个非法的网络请求。若请求合法，则解析HTTP请求body中的参数信息，根据参数加载相应的中间件并调用相应的中间件接口。中间件接口执行完成后客户端将执行结果返回给服务器。

3.4 服务器端设计

3.4.1 接口设计

服务器端管理的资源包括中间件资源、用户资源、中间件资源，三种资源之间是多对多的关系，服务器端使用XML配置文件来描述系统资源之间的关系。以下是对三种资源的RESTful接口设计。

1）中间件部署管理

物理节点上的中间件管理。包括部署中间件、移除中间件、升级中间件、中间配置参数管理等。接口设计如下：

表1 中间件部署管理路由设计

2）中间件池化管理

中间件池化管理。包括上传中间件、下载中间件、更新中间件、中间件版本控制管理、中间件配置管理等。接口设计如表2。

表2 中间件池化管理路由设计

表3 系统管理路由设计

3）系统管理

系统管理。包括用户管理、用户权限管理、系统配置参数管理、物理节点配置管理等。接口设计如表3。

3.4.2 API执行流程

图4为服务器端执行流程。

图4 服务器端API执行流程

1）URL访问检测

上层应用在调用中间件网络接口时，必须提供一种身份认证机制，具体做法是先发送一个用户登录请求到服务器端，服务器端会产生一对临时密钥，公钥存在服务器，私钥发送给应用程序，用于用户权限验证；只有访问检测通过，中间件接口调用请求才会受理。密钥获取方法如下：

返回信息如下：

所有对资源访问的请求，都需要设置Authorization（授权）请求头，并加上自己的access_token，会话结束后密钥也随之失效。

2）路由检测

将网络URL与路由表中的路由进行匹配，如果一旦检测到匹配的路由，根据定义的路由地址会注册到相应的URL调度。

3）分发请求

完成了URL检测和路由检测之后，路由器会分发请求到对应的路由地址，这也是应用请求的生命周期中最重要的一个环节。

根据URL中的DevID参数将请求直接分发请求到设备ID相对应的重定向地址，支持指定重定向代码，默认为301重定向。

4）响应输出

将客户端返回的数据输出到页面或者应用程序。特别的，对于耗时较长的接口调用，客户端程序无法实时返回接口执行结果，为此系统需要对此类请求作相应的处理，对应状态码设计中的202返回值，并返回一个轮询IP地址，其他设备可以调用这个轮询IP查询提交任务的执行状态，若任务执行完成，则返回200状态码。

4 结语

本文根据云计算环境下船舶信息基础平台对中间件所承载的各类资源共享的需求，分析了在云计算集群中实现中间件服务化的可行性，提出了一种基于RESTful技术的二层中间件服务化体系架构，并对该架构中的接口标准和执行流程提出设计方案，为在船舶信息基础平台中实现中间件数据资源共享、系统动态重组重构提供了有效的解决途径。