基于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技術的二層中間件服務化體系架構，并對該架構中的接口標準和執行流程提出設計方案，為在船舶信息基礎平臺中實現中間件數據資源共享、系統動態重組重構提供了有效的解決途徑。