基于ESB的服務排隊路由

劉 巖，劉建明，李宏周，彭智勇

（1.桂林電子科技大學 計算機科學與工程學院，廣西 桂林541004；2.桂林電子科技大學 電子工程與自動化學院，廣西 桂林541004；3.桂林電子科技大學 生命與環境科學學院，廣西 桂林541004）

0 引 言

由于網絡環境處于動態變化中，所以有很多不確定性因素影響靜態路由的效能，很多研究已經展開用于設計企業服務總線動態路由。文獻 ［1，2］提出了基于ESB的動態適應方案用以適應動態網路環境變化，例如服務接口改變、反應時間過大和服務飽和等，各個適應方案都提到了對等效服務的利用，也就是對功能相同服務的利用；文獻［3］提出了在運行時測試評估的動態路由方法，文中的抽象服務名映射實際的功能等同的服務提供者列表；文獻［4］引入了DWT 組件和偵聽器組件來實現動態可靠的服務路由，文中的服務發現引擎用于查找等效的服務提供者列表；文獻 ［5］提出了一個策略配置動態路由模型，文中消息分析器組件用于查詢得到服務提供者列表。

動態服務路由的研究都收集了服務提供者列表以應對網絡中的動態變化需求，也都是采用增強ESB 功能的方式在運行時實現動態服務路由。本文提出將服務提供者預先進行科學分析，根據平均狀態下的性能進行排隊，得到一個固定的具備優先權的隊列。在ESB 中利用得到的隊列是一種靜態布置，但由于有一個有效的優先權隊列，隊列中包含了一些運行良好的服務提供者，這種方式提高了ESB服務路由的效能。同時設計中的程序控制充分利用隊列，使其能夠很好地應對網絡中的動態變化，也實現了類似動態服務路由的效果。本文利用排隊的方法，在保證服務路由高可靠性的情況下，兼顧高效性、穩定性，提高了ESB服務路由的整體效能。

1 服務的排隊

1.1 服務的排隊條件

Web服務技術以其跨平臺可互操作的特性在互聯網上得到了快速地發展和應用。互聯網上存在大量的Web 服務，很多可以利用UBRs（UDDI business registries）和服務搜索引擎進行查找［6］，其中有一部分免費的Web服務可以提供給研究者調用。在這些Web服務中很多都顯示了功能相同或者相似的特點，對這些功能相同或相似的服務加以利用，可以提高應用服務的效能，例如在可靠性、高效性和穩定性等方面。

ESB充分利用了消息機制和XML、Web服務的跨平臺特點，實現了面向服務架構 （service－oriented architecture，SOA）的模型，利用它可以實現更廣領域的集成。其最核心的功能是消息轉換和消息路由。消息轉換能夠消除消息在傳輸過程中協議和格式的差異性，也能夠消除最終的反應消息的差異性，將功能相似的服務變成功能相同的服務。消息路由是消息經過所選擇的通道正確傳達給服務提供者，由服務提供者將最終的反應消息返回給服務請求者。

現實網絡的實際情況是并不是所查找到的服務提供者效能都非常好，而把效能很差的服務提供者隨意加入服務提供者列表中，會降低整個的服務路由的效率和可靠性，而且在網絡中的動態變化不是時時都發生，而是在某一時間段或者在某一時間點發生，所以不需要ESB 在每一次運行中都進行復雜的應對環境變化的工作。

1.2 服務的排隊依據

許多相關文獻都談到了QoS （quality of service）屬性問題［7］，QoS屬性是為了區分服務特別是功能相同的服務而定義的一系列非功能屬性，其中包括反應時間、可用性、吞吐量、成功率及可靠性等等。這些屬性值的獲取一般是通過專業的測試工具，而且這些屬性值在一定時間間隔內度量得到的平均水平，也是通過統計分析得到的平均水平。由于屬性值的變化不是時時刻刻都在進行的，其更新可以由一個統一的服務代理周期性完成。這些屬性值可以被用戶用來選擇滿足特定需求的服務，也可以用來選擇總體評估好的服務。

服務的屬性值是一個服務執行的平均狀態，可以收集很多的屬性值用以更好地選擇特定服務［8］。要將功能相同的服務組成一個整體隊列供服務請求者調用，而由于單個服務的可用性、吞吐量、成功率等屬性值綜合到一個隊列里面整體體現出的相應值會很大，可以忽略這些因素而僅僅利用反應時間提高隊列整體的高效性和可靠性等性能。可以自己統計得出平均反應時間，僅僅利用平均反應時間來完成服務排隊路由。

在網絡環境中可能會發生很多情況致使服務失效，例如暫時的服務器故障、某個特定服務器負載量太大或者傳輸時延在某一段網絡中過大等等。這些失效大都屬于臨時失效，會維持一段時間的失效狀態，一段時間過后會重新恢復原來的平均狀態。在ESB 中功能相似的服務轉換為功能相同的服務，在互聯網上可以搜集這些功能相似或者相同的服務，得到一個服務提供者列表。失效本身是一種隨機的不確定的現象，當服務提供者列表中有不少于3個的服務提供者，全部失效的概率是很小的。綜合考慮網絡變化中的所有情況，全部失效也是可能的，但一定以一個小概率出現，而這樣可以保證高可靠性。

因服務提供者反應的結果相同，所以平均反應時間越短，服務本身性能就越好。服務提供者按照平均反應時間排序，選擇前面少數幾個服務提供者就可以組成一個具備優先權的服務隊列。排隊體現了排隊論中排隊的概念［9］，但它不是針對用戶的排隊，而是針對網絡中可利用的服務資源的排隊。隊列靠前的服務提供者失效后，緊隨的服務提供者提供服務，保證了整體運行的高效性，利用排隊進行整體設計的效率很高。同時由于排隊中服務的合作關系整體設計也體現出了服務反饋結果的穩定性。

1.3 服務的排隊選擇模型

假設有4個功能相同的服務，考慮到服務會發生失效的情況，設計的排隊選擇模型通過3 種策略來應對，這3種策略將充分利用具備優先權的服務隊列。服務的排隊模型如圖1所示。

圖1 服務的排隊選擇模型

第一種策略是將用戶請求消息同時發送給備份服務。計算機軟硬件的設計中都考慮到了用備份來提高可靠性，如果原來的主要工作單元沒有發揮應有作用，備份就會恰當地作為補充發揮作用，在服務的排隊選擇模型中利用備份這一概念。當用戶請求消息到來的時候，按照一般方法將其發送到排隊的優先權高的服務上。而用戶請求消息會同時額外地發送給備份服務，優先權高的服務失效后，備份服務即可發揮作用；另外一個方面，雖然優先權高的服務未失效但偶然反應時間過多，備份服務發揮作用可以降低反應時間，使服務提供結果消息具有很好的穩定性。

第二種策略是在前兩個服務都失效的情況下，程序控制語句探測到并自動向后執行移位操作，然后重發用戶請求消息。而且只有一個服務失效的情況下，程序控制語句也會執行移位操作，保證下一次請求消息發送給兩個服務。計算機軟硬件資源的查找都會用到移位操作，最終定位所要查找的有效資源。服務的排隊選擇模型引入移位操作能大大提高服務反應消息的成功率，通過這種策略實際上是增加了服務成功返回結果消息的機會。

最后一種策略是服務的出隊歸隊操作，使用這種策略能夠更好地應對網絡環境中的動態變化。當某一個服務失效后即執行出隊操作，后續請求消息的調用將不會考慮失效服務，除非其恢復后歸隊。通過這種方式所維持的隊列依然是一個具備優先權的服務隊列。因為失效只是維持一段時間的失效狀態，一段時間后會重新恢復原來的平均狀態，歸隊操作會讓優質服務歸隊參與運行。

2 基于ESB的服務排隊路由

實驗的平臺是開源軟件Mule ESB。Mule ESB 是一個輕量級消息架構，能方便地集成各種應用，并具備很強的可擴展性［10］。其內部的各種組件可以很輕便地轉換各種消息格式等差異，實現非常好的消息轉換功能；同時其組件也可以通過各種方式路由消息，實現較高效的消息路由功能。在實驗中服務排隊路由就是很好地利用了Mule ESB的消息轉換和消息路由功能。

在Mule ESB中利用計算機語言或者說程序控制語句可以很好地實現服務排隊選擇模型。按照實驗的設想，選擇4個功能相同的Web服務進行研究，它們能夠利用IP地址查詢國家信息。服務排隊路由利用服務排隊選擇模型實現的整體流程如圖2所示。

圖2 服務排隊路由的整體流程

（1）用戶端發送請求消息，請求消息傳輸到位于圖2下方的基礎流和位于圖2上方的測試流。基礎流是一般情況下選擇服務對用戶請求消息進行處理的流程，同時負責對失效服務的出隊操作；測試流是在排隊中有失效服務情況下的測試流程，也就是說測試流測試失效服務并負責對恢復效果的服務進行歸隊。

（2）請求消息發送到基礎流后，需要查詢排隊信息。具備優先權的排隊信息可以保存在數據庫中，也可以保存在文件中。

（3）基礎流控制語句從排隊中按照優先權依次選擇兩個未失效的服務，選擇成功后兩個服務和用戶請求消息一并向后傳輸。在控制語句中如果探測到依次選擇的兩個未失效服務及測試流都未正確返回結果消息，則重新從排隊中向后選擇兩個未失效的服務，選擇成功后兩個服務和用戶請求消息再次一并向后傳輸。

（4）總的消息負載中所確定的有效服務接收用戶請求消息并進行相關處理最終得到反應結果消息。

（5）失效控制語句一旦從兩個服務反饋消息中探測到服務失效后，將排隊中相應位置的值置為 “失效”，并保存到數據庫或者文件中，“失效”服務會在下一次運行時被測試流利用，從而完成了服務的出隊操作。

（6）請求消息發送到測試流后，測試流同樣需要查詢位于數據庫或者文件中的排隊失效信息。

（7）測試流控制語句從排隊中選擇全部的失效服務，和用戶請求信息一起一并向后傳輸。

（8）利用用戶請求消息對總的消息負載中所確定的失效服務進行探測以判斷失效服務是否已經能夠正確返回結果消息。

（9）恢復控制語句探測到測試的失效服務已經恢復后，將排隊中相應位置的值置為 “有效”，完成了服務的歸隊操作。如果測試的服務先于基礎流提供的服務反饋結果消息，則立即起用測試流提供的結果消息，使服務排隊路由效率更高。

（10）測試流的所有調用的服務和基礎流的兩個服務都有可能提供結果消息，這些結果消息利用互斥的方法將只有一個最終輸出給用戶，而且輸出的是反應時間最少的那一個，這樣使服務的反應時間圍繞著一個平均值不會出現較大的波動，而更保證了服務反饋結果消息具有更高的穩定性。

3 服務排隊路由的效能分析

3.1 服務排隊路由的穩定性分析

利用服務排隊選擇模型的服務排隊路由在具體實施時測試流所調用的服務和基礎流的兩個服務都可能提供結果消息，而輸出的是反應時間最少的那一個服務。這樣在服務失效時不僅能夠保證提供結果消息，而且在具體網絡環境中服務的反應時間的變化不會特別大。為了分析穩定性實驗中考慮兩種情形，第一種是用戶請求消息到來只發送給服務1，也就是將服務請求固定路由給服務1；第二種情形是在服務排隊路由中服務1反應時間過長而起用后續服務提供結果消息。

實驗中選擇15 個IP 地址進行針對兩種情形的測試，測試的結果如圖3所示。只有一個服務參與的情形下，網絡環境動態變化會增加對服務反應時間的影響。從兩個折線的對比就可以看到利用單一服務進行路由服務反應時間幅度變化可以很大，穩定性不夠好。而利用服務排隊路由，其它功能相同的后續服務能夠提供支持，所以服務反應時間變化不大，服務反應時間會維持在一個小范圍內浮動，而且整體的反應時間是少的，具有較高的穩定性。

圖3 服務排隊路由的穩定性分析

3.2 服務排隊路由的高效性分析

排隊是根據反應時間多少來進行的，反應結果由于利用了ESB的消息轉換而都是相同的，所以反應時間越少，服務本身性能就越好，于是組成了一個具備平均反應時間優先權的排隊。當排隊中第一個服務沒有失效時，第一個服務就可滿足用戶調用需求。有可能會有排隊中后續服務的參與，因為偶然的延遲過大會利用排隊后續服務的結果消息。而當第一個服務失效時，第二個服務就會起作用，反應時間雖然會多一些，也可以滿足用戶需求。這樣整體的用戶請求總是會選擇排隊靠前的服務，說明服務排隊路由基于服務排隊選擇模型保證了用戶請求調用的高效性。

為了驗證高效性，可以從眾多可能出現的情況中選取4個服務執行典型事件。①服務執行典型事件為調用服務1；②服務執行典型事件為服務1失效而調用服務2；③服務執行典型事件為服務1、服務2失效而調用服務3；④服務執行典型事件為服務1、服務2、服務3均失效而調用服務4。為實驗測試可選取10個IP 地址。在測試時記錄每次的反應時間，如果10個IP 地址中對應的反應時間有偏離太大的，則對其進行重新測試。最后得到每個IP請求對應的反應時間，并計算得出平均反應時間，最后得到4個服務執行典型事件依次的平均反應時間如圖4所示。

由圖4可知，服務排隊路由面對網絡變化時會選擇排隊靠前的服務，因此平均反應時間在4個服務執行典型事件中依次增加，從而保證了服務排隊路由的高效性。

3.3 服務排隊路由的可靠性分析

圖4 服務排隊路由的高效性分析

由科學分析建立的具備優先權的排隊中服務全部失效的概率很小，保證了服務排隊路由的高可靠性。為了最大程度地考查程序控制和整體設計在面對網絡動態變化時對可靠性的保證，在測試時先設計一個測試列表。在測試列表中每次對整體流程的執行涉及3種對服務的操作，分別是失效即某一服務失去效果、恢復即某一服務失效后恢復效果、保持有效即服務保持上一次的有效狀態。在整個列表中失效操作是從前往后進行，恢復操作是從后往前進行，更好地展現整體設計必須面對的網絡變化。假設全部失效以一個小概率出現，這樣更接近于真實世界的網絡狀況。

在實驗測試中每40次運行記錄一個成功次數并得出成功率，一共進行600次實驗，得到如圖5所示的成功率圖。在折線圖中可看出成功率在很接近1的小范圍內波動，因為實驗運行會偶然地有幾次失敗的情況，而這種成功率可以滿足高可靠性，而且如果不考慮服務全部失效的情況，成功率更接近1，從而使高可靠性得到了很好的保證。

圖5 服務排隊路由的可靠性分析

4 結束語

經過科學分析得到一個有序的具備優先權的排隊在ESB中能夠產生很大的效用，在ESB 服務路由時利用這些已知的規律能提高用戶請求調用服務的整體效能。在具體實施中利用程序語句進行運行控制特別是針對出隊和歸隊操作的控制，整體流程得以有效運行。從排隊中可以看到，在服務中只要反應時間快整體高效性就會得到體現，而只要結果消息能盡快得到整體穩定性和可靠性也會得到很好的體現。利用服務排隊路由能夠在更大的方向上促進服務的交互和服務的組合，可實現更加穩定可靠的組合服務，而利用排隊整合服務資源會優化整個系統的業務活動。

［1］Laura González，Raúl Ruggia.Towards dynamic adaptation within an ESB－based service infrastructure layer ［C］／／Proceedings of the 3rd International Workshop on Monitoring，Adaptation and Beyond，2010：40－47.

［2］Laura González，Raúl Ruggia.Addressing QoS issues in service based systems through an adaptive ESB infrastructure［C］／／Proceedings of the 6th Workshop on Middleware for Service Oriented Computing，2011：1－7.

［3］Bai Xiaoying，Xie Jihui，Chen Bin，et al.DRESR：Dynamic routing in enterprise service bus ［C］／／IEEE International Conference on e－Business Engineering，2007：528－531.

［4］Wu Bin，Liu Shijun，Wu Lei.Dynamic reliable service routing in enterprise service bus ［C］／／IEEE Asia－Pacific Services Computing Conference，2008：349－354.

［5］Zhou Chunyan，Zhang Xin.A policy－configurable dynamic routing mechanism in enterprise service bus［C］／／International Conference on Educational and Information Technology，2010：480－485.

［6］Eyhab Al－Masri，Qusay H Mahmoud.Investigating web services on the world wide web ［C］／／Proceeding of the 17th International Conference on World Wide Web，2008：795－804.

［7］Al－Masri E，Mahmoud Qusay H.QoS－based discovery and ranking of web services［C］／／Proceedings of 16th International Conference on Computer Communications and Networks，2007：529－534.

［8］The QWS Dataset ［EB／OL］.http：／／www.uoguelph.ca／～qmahmoud／qws／，2008.

［9］Yang Shuo，Chen Haopeng.An improving fault detection mechanism in service－oriented applications based on queuing theory ［C］／／IEEE International Symposium on Service－Oriented System Engineering，2008：245－250.

［10］Mule fundamentals ［EB／OL］.http：／／www.mulesoft.org／documentation／display／current／Mule＋Fundamentals，2013.