基于SOA架構(gòu)的新型云平臺(tái)服務(wù)管理中間件

陳世宜，葉德建

?

基于SOA架構(gòu)的新型云平臺(tái)服務(wù)管理中間件

陳世宜，葉德建

摘 要：隨著云計(jì)算技術(shù)的發(fā)展，針對(duì)細(xì)分行業(yè)的云平臺(tái)不斷涌現(xiàn)。以流媒體云平臺(tái)為代表的私有云，為了降低成本、兼容原系統(tǒng)，通常采用整合服務(wù)的方式實(shí)現(xiàn)，隨著系統(tǒng)的升級(jí)、模塊集群化的增強(qiáng)，傳統(tǒng)的負(fù)載均衡中間件難以有效處理服務(wù)間的頻繁長(zhǎng)鏈調(diào)用。針對(duì)傳統(tǒng)流媒體云平臺(tái)采用負(fù)載均衡中間件實(shí)現(xiàn)子服務(wù)調(diào)用存在的靈活性差、效率低、可用性低等問(wèn)題，設(shè)計(jì)并實(shí)現(xiàn)了一種新型的針對(duì)基于SOA構(gòu)架的流媒體云平臺(tái)應(yīng)用層服務(wù)管理系統(tǒng)，該系統(tǒng)采用生產(chǎn)者/消費(fèi)者模型，通過(guò)注冊(cè)中心配對(duì)的方式實(shí)現(xiàn)高效靈活的服務(wù)調(diào)用，提高云平臺(tái)整體性能。

關(guān)鍵詞：SOA；云平臺(tái)；服務(wù)管理；負(fù)載均衡中間件

0　引言

隨著互聯(lián)網(wǎng)行業(yè)的發(fā)展以及云計(jì)算技術(shù)日益成熟，云平臺(tái)因其低成本、可拓展、高可用、高性能等優(yōu)勢(shì)被業(yè)界廣泛使用，越來(lái)越多的企業(yè)業(yè)務(wù)被遷移至云平臺(tái)。因?yàn)楦黝I(lǐng)域業(yè)務(wù)需求千差萬(wàn)別，所以出現(xiàn)了各類行業(yè)細(xì)分云，如金融云、視頻流媒體云、電子商務(wù)云等。

為了降低成本、提高效率、應(yīng)對(duì)服務(wù)靈活多變的特性，企業(yè)云或行業(yè)云作為一種新型的產(chǎn)業(yè)升級(jí)方式，普遍采用服務(wù)整合的方式來(lái)架構(gòu)云平臺(tái)。具體體現(xiàn)為通過(guò)模塊化重構(gòu)原有系統(tǒng)，將原本業(yè)務(wù)系統(tǒng)抽象為功能服務(wù)，而隨著系統(tǒng)升級(jí)產(chǎn)生的新型業(yè)務(wù)則可以通過(guò)服務(wù)組合來(lái)實(shí)現(xiàn)。在技術(shù)實(shí)現(xiàn)層面上，服務(wù)組合表現(xiàn)為約定協(xié)議、統(tǒng)一接口系統(tǒng)間的調(diào)用，常以web服務(wù)調(diào)用作為其基本實(shí)現(xiàn)方式[1]。

隨著云平臺(tái)業(yè)務(wù)拓展，內(nèi)部模塊化服務(wù)系統(tǒng)間的調(diào)用日益復(fù)雜；同時(shí)，為了保證云平臺(tái)的性能需求，大量子服務(wù)系統(tǒng)采用分布式架構(gòu)。以上的發(fā)展趨勢(shì)都在一定程度上增大了子服務(wù)系統(tǒng)間通訊、調(diào)用的難度[2]。為了提高各個(gè)組合服務(wù)的吞吐率并縮短響應(yīng)時(shí)間，亟需開發(fā)一種高效的云平臺(tái)服務(wù)管理中間件[3]。

本文研究分析了現(xiàn)有流媒體云平臺(tái)服務(wù)通信機(jī)制，發(fā)現(xiàn)并指出其存在的效率低、靈活性差、可用性低等問(wèn)題，借鑒并改進(jìn)了 SOA（面向服務(wù)的架構(gòu)）的基本服務(wù)管理策略，針對(duì)流媒體云平臺(tái)具體應(yīng)用場(chǎng)景設(shè)計(jì)了一種基于SOA架構(gòu)的新型服務(wù)管理中間件，旨在提供一種高效靈活的云平臺(tái)服務(wù)間通信機(jī)制。

1　原流媒體云平臺(tái)服務(wù)管理

1.1 流媒體云平臺(tái)概況

流媒體云平臺(tái)如圖1所示：

圖1　流媒體云平臺(tái)架構(gòu)圖

底層實(shí)現(xiàn)可簡(jiǎn)單抽象為計(jì)算服務(wù)與存儲(chǔ)服務(wù)兩部分。計(jì)算服務(wù)，主要包括前端HTTP服務(wù)器及應(yīng)用服務(wù)器；存儲(chǔ)服務(wù)，主要包括SQL數(shù)據(jù)庫(kù)集群、內(nèi)存緩存集群、對(duì)象存儲(chǔ)服務(wù)和大數(shù)據(jù)處理平臺(tái)等。計(jì)算服務(wù)分布在虛擬機(jī)上，利用虛擬機(jī)平臺(tái)提供的資源隔離機(jī)制提高云平臺(tái)服務(wù)器資源的利用率，同時(shí)由于計(jì)算服務(wù)本身無(wú)狀態(tài)的特性，使用虛擬化技術(shù)并不損失系統(tǒng)的可用性。存儲(chǔ)服務(wù)分布在物理機(jī)上，確保數(shù)據(jù)訪問(wèn)性能并提供數(shù)據(jù)的可靠持久化。

海量客戶端發(fā)送請(qǐng)求至云平臺(tái)，通過(guò)負(fù)載均衡集群將請(qǐng)求轉(zhuǎn)發(fā)至前端HTTP服務(wù)器，前端服務(wù)器從對(duì)象存儲(chǔ)中讀取視頻圖片等資源，并調(diào)用應(yīng)用服務(wù)層服務(wù)，應(yīng)用服務(wù)借助內(nèi)存緩存集群提高操作響應(yīng)速度，將日志等信息存儲(chǔ)在NoSQL大數(shù)據(jù)平臺(tái)待進(jìn)一步數(shù)據(jù)挖掘與分析，而業(yè)務(wù)信息則統(tǒng)一存儲(chǔ)在SQL集群中。

云平臺(tái)的應(yīng)用服務(wù)層通過(guò)各個(gè)服務(wù)模塊系統(tǒng)的組合調(diào)用完成，將基本業(yè)務(wù)抽象為幾大核心服務(wù)，包括視頻點(diǎn)播、云解碼、視頻質(zhì)量監(jiān)控、終端狀態(tài)統(tǒng)計(jì)、個(gè)性化推薦、云推送等，借助各個(gè)服務(wù)間的組合提供彈性靈活的業(yè)務(wù)功能和各個(gè)核心服務(wù)內(nèi)部又可以劃分為更細(xì)粒度級(jí)的子服務(wù)組合。終端用戶請(qǐng)求視頻點(diǎn)播時(shí)調(diào)用的子服務(wù)，如圖2所示：

圖2　點(diǎn)播業(yè)務(wù)子服務(wù)分解

當(dāng)終端用戶請(qǐng)求視頻點(diǎn)播服務(wù)時(shí)，首先需要經(jīng)過(guò)用戶認(rèn)證系統(tǒng)加以認(rèn)證，確定用戶信息，進(jìn)行點(diǎn)播操作，依次調(diào)用賬戶查詢服務(wù)、定價(jià)服務(wù)以及收費(fèi)服務(wù)，同時(shí)系統(tǒng)也向用戶推薦影片，依次調(diào)用個(gè)性推薦服務(wù)及影片信息服務(wù)。所以在流媒體云平臺(tái)中的服務(wù)調(diào)用存在如下特點(diǎn)：1）存在大量針對(duì)業(yè)務(wù)邏輯的服務(wù)調(diào)用，因此大部分服務(wù)都需要在基于虛擬機(jī)的服務(wù)器上進(jìn)行。2）針對(duì)基礎(chǔ)服務(wù)的請(qǐng)求多為長(zhǎng)鏈調(diào)用。3）服務(wù)間的組合紛繁復(fù)雜，會(huì)出現(xiàn)交叉調(diào)用的情況。

1.2 基于負(fù)載均衡中間件的服務(wù)管理

目前流媒體云平臺(tái)采用負(fù)載均衡中間件來(lái)處理服務(wù)間的調(diào)用，如圖3所示：

圖3　負(fù)載均衡原理

負(fù)載均衡中間件一般用來(lái)應(yīng)對(duì)高并發(fā)用戶請(qǐng)求，通過(guò)負(fù)載均衡技術(shù)將不同的請(qǐng)求分配給不同的服務(wù)器處理，可以有效緩解單臺(tái)服務(wù)器的壓力[4]。而在云平臺(tái)的服務(wù)調(diào)用過(guò)程中，業(yè)界普遍利用負(fù)載均衡中間件對(duì)外表現(xiàn)統(tǒng)一接口，高效轉(zhuǎn)發(fā)請(qǐng)求的特性。在處理服務(wù)間的調(diào)用時(shí)，首先將不同服務(wù)的服務(wù)地址及路徑記錄在負(fù)載均衡“轉(zhuǎn)發(fā)表”中，從而使服務(wù)間的RPC調(diào)用請(qǐng)求首先發(fā)送到負(fù)載均衡中間件，負(fù)載均衡中間件根據(jù)已配置好的“轉(zhuǎn)發(fā)表”中的記錄，將客戶端的請(qǐng)求轉(zhuǎn)發(fā)對(duì)應(yīng)的應(yīng)用服務(wù)器來(lái)進(jìn)行處理。負(fù)載均衡器與服務(wù)器之間有心跳檢測(cè)，當(dāng)應(yīng)用服務(wù)器不可用時(shí)，負(fù)載均衡器將失效服務(wù)器的地址從“轉(zhuǎn)發(fā)表”中臨時(shí)性刪除，當(dāng)該服務(wù)器恢復(fù)工作之后，負(fù)載均衡器可以將其地址重新添加到“轉(zhuǎn)發(fā)表”。為了避免負(fù)載均衡中間件出現(xiàn)單點(diǎn)故障的風(fēng)險(xiǎn)，可通過(guò)心跳機(jī)制維持多臺(tái)備份。

然而負(fù)載均衡中間件在實(shí)際的使用中會(huì)出現(xiàn)如下問(wèn)題：1）負(fù)載均衡中間件轉(zhuǎn)發(fā)子服務(wù)模塊間的請(qǐng)求與響應(yīng)從而使處理效率低下。如圖1所示，服務(wù)間的交互均需要通過(guò)負(fù)載均衡中間層，即每次請(qǐng)求與響應(yīng)都經(jīng)過(guò)負(fù)載均衡中間件的轉(zhuǎn)發(fā)，那么服務(wù)器與負(fù)載均衡中間件的連接耗時(shí)勢(shì)必會(huì)影響服務(wù)的響應(yīng)時(shí)耗，尤其當(dāng)某服務(wù)的子服務(wù)間的調(diào)用鏈長(zhǎng)增長(zhǎng)時(shí)，連接轉(zhuǎn)發(fā)耗時(shí)會(huì)對(duì)于服務(wù)整體時(shí)耗的影響越發(fā)明顯。2）負(fù)載均衡中間件本身因其使用的單點(diǎn)布局而成為系統(tǒng)的性能瓶頸。服務(wù)對(duì)于負(fù)載均衡中間件的壓力會(huì)隨著該服務(wù)子服務(wù)鏈長(zhǎng)的增加而成線性增長(zhǎng)，完成一次子服務(wù)鏈長(zhǎng)為10的服務(wù)，需要訪問(wèn)負(fù)載均衡中間件10次，而一旦高并發(fā)訪問(wèn)此類長(zhǎng)鏈服務(wù)會(huì)造成中間件的崩潰，進(jìn)而整個(gè)系統(tǒng)癱瘓。3）負(fù)載均衡中間件需要手動(dòng)配置轉(zhuǎn)發(fā)地址，因此服務(wù)器變更時(shí)不能自動(dòng)動(dòng)態(tài)轉(zhuǎn)移，需要人工改變配置。這給系統(tǒng)的維護(hù)人員造成了很大的壓力。

目前主流的負(fù)載均衡中間件主要有Nginx、HAProxy、LVS等。針對(duì)問(wèn)題1，LVS技術(shù)只轉(zhuǎn)發(fā)請(qǐng)求不轉(zhuǎn)發(fā)響應(yīng)，在一定程度上提高了效率，但是LVS并不適用于虛擬機(jī)通訊，因此在流媒體云平臺(tái)系統(tǒng)中無(wú)法發(fā)揮優(yōu)勢(shì)；由于流媒體云平臺(tái)的基礎(chǔ)服務(wù)多為長(zhǎng)鏈調(diào)用，問(wèn)題1、2在流媒體云平臺(tái)中表現(xiàn)得更為突出；由于流媒體云平臺(tái)中的服務(wù)調(diào)用復(fù)雜，在出現(xiàn)問(wèn)題3時(shí)人力成本加重。所以，負(fù)載均衡中間件并不是流媒體云平臺(tái)服務(wù)管理的最佳方案。

2　新型云平臺(tái)服務(wù)管理系統(tǒng)

針對(duì)以上問(wèn)題，本文設(shè)計(jì)并實(shí)現(xiàn)了一種基于SOA 的新型服務(wù)管理中間件來(lái)解決流媒體云平臺(tái)中系統(tǒng)調(diào)用的問(wèn)題。本系統(tǒng)將服務(wù)間 RPC調(diào)用抽象為應(yīng)用層服務(wù)，將服務(wù)調(diào)用的雙方抽象為生產(chǎn)者和消費(fèi)者的模型，服務(wù)提供方與請(qǐng)求方通過(guò)注冊(cè)中心完成配對(duì)，在請(qǐng)求方緩存可調(diào)用提供方信息，同時(shí)監(jiān)控中心記錄消費(fèi)者與生產(chǎn)者調(diào)用記錄，作為日后負(fù)載均衡評(píng)估算法權(quán)重的數(shù)據(jù)信息。這樣的設(shè)計(jì)首先縮短了采用負(fù)載均衡模式產(chǎn)生的通信耗時(shí)，注冊(cè)中心只負(fù)責(zé)配對(duì)，而具體交互由請(qǐng)求方和提供方獨(dú)立完成，不必經(jīng)由負(fù)載均衡器轉(zhuǎn)發(fā)；注冊(cè)中心采用Zookeeper集群，同時(shí)請(qǐng)求方緩存提供方信息，這都提高了系統(tǒng)的可用性；注冊(cè)機(jī)制以及實(shí)時(shí)監(jiān)控也保證了服務(wù)提供方的變更可以及時(shí)更新。本中間件處理服務(wù)調(diào)用的具體流程如圖4所示：

圖4　中間件工作流程

1）服務(wù)提供方向注冊(cè)中心注冊(cè)所提供的服務(wù)。2）請(qǐng)求方向注冊(cè)中心請(qǐng)求服務(wù)。3）注冊(cè)中心在注冊(cè)表中查找相關(guān)服務(wù)，并通過(guò)負(fù)載均衡策略將特定服務(wù)提供方通知給請(qǐng)求方。4）請(qǐng)求方此時(shí)獲得了提供方的地址，可以直接調(diào)用提供方的服務(wù)，同時(shí)在收到注冊(cè)中心下一次通知前持續(xù)調(diào)用該提供方服務(wù)。5）同時(shí)服務(wù)請(qǐng)求方與提供方將此次調(diào)用的結(jié)果記錄在監(jiān)控中心，作為負(fù)載權(quán)重計(jì)算的原始數(shù)據(jù)[5]。6）監(jiān)控中心將計(jì)算結(jié)果以通知的方式發(fā)送給注冊(cè)中心。以下小節(jié)針對(duì)本中間件各層實(shí)現(xiàn)具體展開。

2.1 通信層

本中間件通訊層采用基于NIO的Netty框架實(shí)現(xiàn)。相較于傳統(tǒng)IO，NIO通過(guò)選擇器、通道、緩沖區(qū)的設(shè)計(jì)實(shí)現(xiàn)了高性能非阻塞IO讀寫機(jī)制，支持高并發(fā)，同時(shí)編程實(shí)現(xiàn)簡(jiǎn)單。Netty在NIO的基礎(chǔ)上對(duì)其進(jìn)行了封裝，提供了一套異步的、事件驅(qū)動(dòng)的網(wǎng)絡(luò)應(yīng)用程序框架和工具。在此框架下，本中間件設(shè)計(jì)了符合應(yīng)用場(chǎng)景的自定義協(xié)議來(lái)完成服務(wù)提供方、服務(wù)請(qǐng)求方、注冊(cè)中心、監(jiān)控中心間的交互。

通訊協(xié)議主要包括協(xié)議頭與協(xié)議數(shù)據(jù)兩部分內(nèi)容。如圖5所示：

圖5　自定義協(xié)議內(nèi)容

協(xié)議頭主要包括：信息標(biāo)志位、操作標(biāo)志位、協(xié)長(zhǎng)度以及超時(shí)時(shí)間字段。信息標(biāo)志位可設(shè)置值為請(qǐng)求、回復(fù)與通知，可用2比特位表示。操作標(biāo)志位取值為服務(wù)注冊(cè)、服務(wù)請(qǐng)求、服務(wù)通知、請(qǐng)求調(diào)用記錄、調(diào)用結(jié)果記錄以及監(jiān)控回饋，可用1字節(jié)表示。長(zhǎng)度字段顯示協(xié)議體字節(jié)長(zhǎng)度。超時(shí)時(shí)間字段確保服務(wù)無(wú)法得到回應(yīng)時(shí)，由請(qǐng)求方再次發(fā)起請(qǐng)求。

協(xié)議體設(shè)計(jì)針對(duì)具體的通信場(chǎng)景設(shè)計(jì)了服務(wù) ID、服務(wù)類型、IP地址、端口號(hào)、服務(wù)位置、會(huì)話ID、時(shí)間戳以及操作結(jié)果字段。在以上通信場(chǎng)景中，各字段的使用情況如表1所示：

表1　自定義協(xié)議內(nèi)容

2.2 注冊(cè)中心

注冊(cè)中心實(shí)現(xiàn)了本中間件的主要業(yè)務(wù)功能：為服務(wù)請(qǐng)求方和服務(wù)提供方的連接提供了媒介；通過(guò)最優(yōu)選擇方式實(shí)現(xiàn)了負(fù)載均衡；與服務(wù)提供方保持長(zhǎng)連接以及時(shí)修改各服務(wù)當(dāng)前狀態(tài)。

2.2.1 流程設(shè)計(jì)

注冊(cè)中心的基本業(yè)務(wù)流程如圖6所示：

圖6　注冊(cè)中心流程設(shè)計(jì)

在本服務(wù)啟動(dòng)階段，注冊(cè)中心接受來(lái)自各個(gè)服務(wù)器的消息，通過(guò)信息類型判斷后續(xù)操作。如果為請(qǐng)求信息，則再次通過(guò)解析協(xié)議頭的操作標(biāo)志位字段判斷協(xié)議類型。若為注冊(cè)服務(wù)，在當(dāng)前注冊(cè)表中根據(jù)IP地址，端口號(hào)以及服務(wù)地址構(gòu)成的服務(wù)唯一標(biāo)識(shí)判斷服務(wù)是否已經(jīng)注冊(cè)，對(duì)于已經(jīng)注冊(cè)的服務(wù)回復(fù)注冊(cè)失敗消息，消息體中包含錯(cuò)誤碼及錯(cuò)誤信息，對(duì)于新注冊(cè)的服務(wù)，將其寫入注冊(cè)表中，并回復(fù)注冊(cè)成功，同時(shí)與其保持長(zhǎng)連接，通過(guò)心跳機(jī)制確定服務(wù)提供方是否可用；若為請(qǐng)求服務(wù)，則在注冊(cè)表中查找該類型服務(wù)的提供方，同時(shí)根據(jù)權(quán)重選擇最優(yōu)服務(wù) ID，將其通知給請(qǐng)求方。若信息類型為通知類型，則修改注冊(cè)表中的選擇權(quán)重?cái)?shù)值，同時(shí)通知給全部消費(fèi)者。

2.2.2 存儲(chǔ)支持

本中間件作為云平臺(tái)應(yīng)用層服務(wù)，為了實(shí)現(xiàn)平臺(tái)整體的可拓展、高性能、高可用等特性，注冊(cè)中心采用了分布式的設(shè)計(jì)，即建立注冊(cè)中心集群，這樣一方面避免了單點(diǎn)故障的風(fēng)險(xiǎn)，另一方面在注冊(cè)中心處理大規(guī)模并發(fā)請(qǐng)求時(shí)極大地縮短了等待時(shí)間，提高系統(tǒng)性能，改善服務(wù)質(zhì)量。

注冊(cè)中心通過(guò)Zookeeper來(lái)實(shí)現(xiàn)分布式存儲(chǔ)。Zookeeper是一種開源的分布式應(yīng)用程序協(xié)調(diào)服務(wù)，提供了配置維護(hù)、名字服務(wù)、分布式同步、組服務(wù)等功能，其核心基于 Fast Paxos算法，通過(guò)投票選舉協(xié)議確保存放在各個(gè)節(jié)點(diǎn)上的數(shù)據(jù)能夠保持強(qiáng)一致性。

注冊(cè)中心主要存儲(chǔ)各個(gè)服務(wù)的注冊(cè)信息以及當(dāng)前狀態(tài)。注冊(cè)表以關(guān)系型數(shù)據(jù)庫(kù)表的形式將注冊(cè)服務(wù)持久化，該表中包含的字段為：服務(wù)ID、IP地址、端口號(hào)、服務(wù)位置、服務(wù)類型、選擇權(quán)重以及可用狀態(tài)。服務(wù)ID為自增字段，每當(dāng)有一個(gè)新的服務(wù)請(qǐng)求注冊(cè)時(shí)，根據(jù)核對(duì)之前表中的IP地址、端口號(hào)和服務(wù)位置來(lái)判斷該服務(wù)是否應(yīng)該被注冊(cè)，若為新服務(wù)則產(chǎn)生新服務(wù)ID分配給該服務(wù)。每個(gè)服務(wù)的IP地址、端口號(hào)和服務(wù)位置從通信信息中直接讀取，并記錄在注冊(cè)表中。選擇權(quán)重用于注冊(cè)中心匹配算法，由監(jiān)控中心產(chǎn)生，并發(fā)送給注冊(cè)中心。服務(wù)類型用以區(qū)分提供方提供的不同服務(wù)，多個(gè)服務(wù)可提供相同類型服務(wù)。可用狀態(tài)信息根據(jù)注冊(cè)中心與各個(gè)服務(wù)提供者間的心跳狀態(tài)及時(shí)更新。

2.2.3 匹配策略

注冊(cè)中心針對(duì)請(qǐng)求服務(wù)會(huì)首先在注冊(cè)表中選擇提供該類型服務(wù)的一組服務(wù) ID。此時(shí)為了提高系統(tǒng)效率，減少調(diào)用失敗，注冊(cè)中心首先會(huì)篩選此時(shí)可用的服務(wù)，即可用狀態(tài)為True的服務(wù)。在完成第一輪篩選后，根據(jù)權(quán)重值，選出權(quán)重最大的服務(wù)，將其封裝為通知消息發(fā)給服務(wù)請(qǐng)求方。權(quán)重值的計(jì)算由監(jiān)控中心完成，這在一定程度上減輕了注冊(cè)中心的負(fù)擔(dān)。

2.3 監(jiān)控中心

本中間件中的監(jiān)控中心主要負(fù)責(zé)收集數(shù)據(jù)，并根據(jù)權(quán)重算法計(jì)算注冊(cè)表中的新權(quán)重，計(jì)算結(jié)束后將結(jié)果以信息形式發(fā)送給注冊(cè)中心，作為每次匹配依據(jù)的權(quán)重值。

2.3.1 數(shù)據(jù)采集

監(jiān)控中心接收來(lái)自請(qǐng)求方與提供方的記錄信息。搜集的主要信息內(nèi)容包括會(huì)話ID、操作結(jié)果、IP地址、服務(wù)類型以及時(shí)間戳等。以會(huì)話ID為標(biāo)識(shí)，不同IP地址的同一會(huì)話ID的信息收集，可以獲得當(dāng)前不同IP地址服務(wù)器目前尚未處理的任務(wù)數(shù) n(IP)。在協(xié)議頭中可以讀取信息超時(shí)時(shí)間αexp。根據(jù)請(qǐng)求方的操作結(jié)果信息可獲得針對(duì)不同IP地址服務(wù)器請(qǐng)求超時(shí)的結(jié)果γ(IP)。根據(jù)相同會(huì)話ID的時(shí)間戳可以獲得指定 IP地址服務(wù)器處理特定服務(wù)類型耗時(shí) t(end, IP, sType,sID)- t(start, IP, sType,sID)。

2.3.2 權(quán)重計(jì)算

為了提高系統(tǒng)的整體效率，縮短調(diào)用耗時(shí)，同時(shí)合理分配資源，注冊(cè)中心針對(duì)每次具體請(qǐng)求的配對(duì)過(guò)程中，應(yīng)考慮以下4點(diǎn)主要因素：1）提供方服務(wù)器最近是否過(guò)載，目前無(wú)法處理服務(wù)請(qǐng)求；2）當(dāng)前各服務(wù)提供方機(jī)器任務(wù)分配情況；3）服務(wù)提供方機(jī)器最新處理特定服務(wù)請(qǐng)求耗時(shí)情況；4）服務(wù)提供方歷史處理特定請(qǐng)求情況。以上四點(diǎn)因素對(duì)于分配結(jié)果的影響效果依次遞減。結(jié)合監(jiān)控中心收集的數(shù)據(jù)，可以依次表示以上因素如下。

服務(wù)提供方是否過(guò)載可通過(guò)請(qǐng)求方請(qǐng)求超時(shí)的結(jié)果γ(IP)表示。對(duì)于分配權(quán)重的影響直接表示為 Wγ(IP) {0,1}，0代表當(dāng)前狀態(tài)未過(guò)載，1表示出現(xiàn)過(guò)載，即收到請(qǐng)求方發(fā)送的超時(shí)消息。

當(dāng)前各服務(wù)提供方機(jī)器任務(wù)分配情況以任務(wù)數(shù)來(lái)進(jìn)行表示，即 N=,n N。機(jī)器分配情況對(duì)于權(quán)重的影響可以抽象為。即權(quán)重隨著請(qǐng)求方任務(wù)數(shù)的增多而急劇減少，這在一定程度上可以避免服務(wù)發(fā)生過(guò)載情況。

服務(wù)提供方機(jī)器最近處理特定服務(wù)請(qǐng)求耗時(shí)情況根據(jù)最近次耗時(shí)的絕對(duì)值進(jìn)行計(jì)算。最近次耗時(shí)的絕對(duì)值表示為t(end)- t(start)，分配權(quán)重為WT，具體計(jì)算方式如公式（1）：

WT的取值區(qū)間通過(guò)歸一化處理，將其映射到（0、1）區(qū)間。

服務(wù)提供方歷史情況基于以往 N次處理此類服務(wù)所需時(shí)間進(jìn)行計(jì)算，即 H=<Δt1,Δt2,Δt3…>,其中分配權(quán)重為WH。WH主要由兩部分組成，即以往歷史調(diào)和均值以及歷史波動(dòng)，即均值越高處理時(shí)間越長(zhǎng)，浮動(dòng)越大越不穩(wěn)定，那么相應(yīng)的權(quán)重值也越低。具體計(jì)算方式如公式（2）：

影響匹配結(jié)果的權(quán)重計(jì)算基于以上 4種子權(quán)重的綜合考慮，根據(jù)各個(gè)權(quán)重的影響強(qiáng)弱，綜合為最終的權(quán)重計(jì)算方式如公式（3）：

即計(jì)算權(quán)重時(shí)，可以充分保證4種因素對(duì)于權(quán)重的影響的優(yōu)先級(jí)順序，即若

根據(jù)以上一套計(jì)算權(quán)重的算法，對(duì)每一臺(tái)提供服務(wù)的機(jī)器都產(chǎn)生相應(yīng)的權(quán)重值，以在匹配過(guò)程中使用。監(jiān)控中心的權(quán)重算法配合注冊(cè)中心的匹配機(jī)制保證系統(tǒng)盡可能使用運(yùn)轉(zhuǎn)良好，處理速度快，性能穩(wěn)定的機(jī)器來(lái)應(yīng)答請(qǐng)求，從而降低系統(tǒng)平均處理用時(shí)，提高系統(tǒng)的處理效率，增強(qiáng)系統(tǒng)可用性，縮短請(qǐng)求方等待時(shí)間，提升整體性能，使得用戶有更好的使用體驗(yàn)。

2.4 服務(wù)提供方/服務(wù)請(qǐng)求方

在本中間件中，服務(wù)提供方和請(qǐng)求方采用了簡(jiǎn)潔的設(shè)計(jì)模式，計(jì)算處理主要由注冊(cè)中心及監(jiān)控中心完成。請(qǐng)求方與提供方依托自定義協(xié)議向注冊(cè)中心及監(jiān)控中心發(fā)送信息，包括注冊(cè)，請(qǐng)求以及記錄等類型消息，并且對(duì)于來(lái)自注冊(cè)中心以及監(jiān)控中心的信息進(jìn)行解析處理，完成業(yè)務(wù)邏輯。同時(shí)為了提高系統(tǒng)的吞吐量和可用性，請(qǐng)求方緩存處理相應(yīng)服務(wù)的提供方地址，只在接收到注冊(cè)中心通知的情況下更改服務(wù)提供方信息，減少了反復(fù)請(qǐng)求建立連接的消耗，同時(shí)也便于在注冊(cè)中心失效時(shí)，依然可以正常調(diào)用服務(wù)。

3　系統(tǒng)測(cè)試

本中間件作為應(yīng)用層系統(tǒng)中間件應(yīng)用于清鶴流媒體云平臺(tái)，解決私有云平臺(tái)中業(yè)務(wù)服務(wù)間RPC調(diào)用的問(wèn)題。針對(duì)該系統(tǒng)的處理效率和吞吐量等指標(biāo)設(shè)計(jì)了相應(yīng)實(shí)驗(yàn)進(jìn)行測(cè)試。實(shí)驗(yàn)環(huán)境為清鶴流媒體云平臺(tái)的虛擬機(jī)測(cè)試環(huán)境，每臺(tái)虛擬機(jī)的配置相同，如表2所示：

表2　測(cè)試環(huán)境硬件配置

各服務(wù)器網(wǎng)卡均為千兆網(wǎng)卡，所在網(wǎng)絡(luò)的交換機(jī)速率為10Gbit/s，即網(wǎng)絡(luò)環(huán)境不會(huì)成為實(shí)驗(yàn)瓶頸。原系統(tǒng)負(fù)載均衡中間件采用HAProxy1.4.24，Web服務(wù)采用Apache Tomcat 8.0服務(wù)器。

3.1 響應(yīng)時(shí)間測(cè)試

本實(shí)驗(yàn)在服務(wù)調(diào)用效率方面對(duì)新型中間件與傳統(tǒng)負(fù)載均衡中間件進(jìn)行了對(duì)比。由于在單次服務(wù)調(diào)用過(guò)程中會(huì)發(fā)生多次RPC調(diào)用，因此，本文定義服務(wù)調(diào)用的鏈長(zhǎng)為單次服務(wù)請(qǐng)求過(guò)程中發(fā)生的RPC次數(shù)。本實(shí)驗(yàn)通過(guò)測(cè)試不同鏈長(zhǎng)的服務(wù)請(qǐng)求的響應(yīng)時(shí)間來(lái)衡量新舊中間件通信效率。

實(shí)驗(yàn)過(guò)程如下：使用CURL工具模擬服務(wù)調(diào)用的HTTP請(qǐng)求，模擬過(guò)程共分20組，每組服務(wù)調(diào)用鏈長(zhǎng)不同；每組進(jìn)行20次服務(wù)調(diào)用，記錄每次通信耗時(shí)；將每組的實(shí)驗(yàn)數(shù)據(jù)進(jìn)行排序，選擇排序結(jié)果為8至12位的5組數(shù)據(jù)作為最終結(jié)果，以排除測(cè)試中由于網(wǎng)絡(luò)環(huán)境等因素影響而產(chǎn)生的數(shù)據(jù)噪點(diǎn)如圖7所示：

圖7　新舊系統(tǒng)效率對(duì)比

圖7為新舊中間件針對(duì)相同簡(jiǎn)單長(zhǎng)鏈請(qǐng)求時(shí)耗的測(cè)試結(jié)果，從中可以看出隨著鏈長(zhǎng)的增加改進(jìn)中間件相對(duì)于原始中間件的優(yōu)勢(shì)越明顯。如當(dāng)服務(wù)鏈長(zhǎng)為20時(shí)，新系統(tǒng)平均處理時(shí)間為447.2毫秒而原始系統(tǒng)則高達(dá)517.6毫秒，針對(duì)鏈長(zhǎng)大于5的服務(wù)調(diào)用，新中間件的效率提高了10%以上。而產(chǎn)生這樣改變的主要原因在于去中心化的設(shè)計(jì)思路，隨著系統(tǒng)的啟動(dòng)，當(dāng)服務(wù)請(qǐng)求方獲得了來(lái)自注冊(cè)中心的通知后，再次進(jìn)行服務(wù)調(diào)用時(shí)可以省去與中間件的交互，從而極大的提高了通信效率。

3.2 吞吐量測(cè)試

本實(shí)驗(yàn)在服務(wù)吞吐量方面對(duì)新型中間件與傳統(tǒng)負(fù)載均衡中間件進(jìn)行了對(duì)比。由于系統(tǒng)吞吐量本身也受服務(wù)請(qǐng)求鏈長(zhǎng)的影響，因而在實(shí)驗(yàn)中設(shè)計(jì)了針對(duì)不同服務(wù)請(qǐng)求鏈長(zhǎng)下新舊中間件的吞吐量測(cè)試。

實(shí)驗(yàn)過(guò)程如下：采用http_load壓力測(cè)試軟件，模擬50個(gè)客戶端同時(shí)發(fā)起的10000個(gè)服務(wù)請(qǐng)求，記錄新舊中間件在以下情況下的吞吐量；針對(duì)不同鏈長(zhǎng)的服務(wù)調(diào)用進(jìn)行測(cè)試，分為鏈長(zhǎng)2-4的短鏈服務(wù)組與鏈長(zhǎng)為10左右的長(zhǎng)鏈服務(wù)組，長(zhǎng)、短鏈組分別進(jìn)行9次測(cè)試，并記錄每次測(cè)試的吞吐量；將每組的九次實(shí)驗(yàn)結(jié)果排序，取排序結(jié)果第五位的數(shù)據(jù)作為最終結(jié)果，以排除意外情況造成的偏差。

實(shí)驗(yàn)結(jié)果如下圖8所示：

圖8　新舊系統(tǒng)吞吐量對(duì)比

由實(shí)驗(yàn)結(jié)果可以看出，改進(jìn)系統(tǒng)的吞吐量明顯優(yōu)于原系統(tǒng)，而且相對(duì)于短鏈請(qǐng)求，長(zhǎng)鏈請(qǐng)求的優(yōu)勢(shì)更明顯。同時(shí)原系統(tǒng)由于HAProxy本身的壓力，在鏈長(zhǎng)增加的情況下吞吐量顯著減少，而新系統(tǒng)在一定程度上緩解了這種壓力，在應(yīng)對(duì)長(zhǎng)鏈請(qǐng)求時(shí)也表現(xiàn)了很好的性能。

4　總結(jié)

本文分析了目前流媒體云平臺(tái)使用的傳統(tǒng)負(fù)載均衡中間件系統(tǒng)原理，提出了其在長(zhǎng)鏈調(diào)用等工業(yè)界應(yīng)用場(chǎng)景日漸復(fù)雜過(guò)程中出現(xiàn)的實(shí)際問(wèn)題，并且針對(duì)細(xì)分領(lǐng)域、結(jié)合流媒體云平臺(tái)的特點(diǎn)，設(shè)計(jì)并實(shí)現(xiàn)了一種用以解決應(yīng)用層 RPC調(diào)用服務(wù)的基于 SOA 構(gòu)架的新型云平臺(tái)服務(wù)管理中間件。該設(shè)計(jì)實(shí)現(xiàn)改善了原本使用負(fù)載均衡中間件產(chǎn)生的系統(tǒng)性能瓶頸，在長(zhǎng)鏈調(diào)用中使得系統(tǒng)的吞吐量提升了近5倍。其次，本中間件縮短了服務(wù)調(diào)用耗時(shí)，提高了系統(tǒng)效率，在長(zhǎng)鏈調(diào)用中時(shí)耗縮短了近10%。因此，本中間件提供了一種真正靈活高效，性能優(yōu)越的流媒體云平臺(tái)服務(wù)調(diào)用解決方案。

參考文獻(xiàn)

[1] 梁爽. 基于 SOA的云計(jì)算框架模型的研究與實(shí)現(xiàn)[J].計(jì)算機(jī)工程與應(yīng)用,2011,35:92-94+142

[2] Baude F, Filali I, Huet F, et al. ESB federation for large-scale SOA[C]//Proceedings of the 2010ACM Sym -posium on Applied Computing. ACM, 2010: 2459-2466.

[3] Yang X, Zhang H. Cloud computing and SOA convergence research[C]//Computational Intelligence and Design (ISCID), 2012 Fifth International Symposium on. IEEE, 2012, 1: 330-335.

[4] 杜垚,郭濤,陳俊杰. 云環(huán)境下機(jī)群彈性負(fù)載均衡機(jī)制[J].計(jì)算機(jī)應(yīng)用,2013,03:830-833

[5] Zha J, Wang J, Han R, et al. Research on load balance of service capability interaction management[C]//Broadband Network and Multimedia Technology (IC-BNMT), 20103rd IEEE International Conference on. IEEE, 2010: 212-217.

中圖分類號(hào)：TP312

文獻(xiàn)標(biāo)志碼：A

文章編號(hào)：1007-757X(2016)07-0029-05

收稿日期：（2016.01.02）

基金項(xiàng)目：上海市科委項(xiàng)目（12511503002）；

作者簡(jiǎn)介：陳世宜（1990-），女，吉林，復(fù)旦大學(xué)軟件學(xué)院，碩士研究生，研究方向：網(wǎng)絡(luò)多媒體，上海，201203葉德建（1976-），男，浙江，復(fù)旦大學(xué)軟件學(xué)院，副教授，研究方向：網(wǎng)絡(luò)多媒體，上海，201203

SOA-based Service Management Middleware of Cloud Platform

Chen Shiyi, Ye Dejian
(College of Computer and Information Technology, Northeast Petroleum University, Daqing 163318, China)

Abstract:With the development of the cloud computing, industry-specific clouds have come out increasingly for these years. The private clouds are set up by grouping the services in order to cut the cost while keeping compatible with the old system. However, caused by the system upgrade and module clustering, it is difficult for the load balancer to handle with the long-chain complicated system-calls between the services effectively. Therefore, a new SOA-based service management system for Cloud platform is proposed to make it more flexible, effective and feasible. This system is in producer/consumer mode and actually a matcher for caller and callee so that it contributes to the better performance of the Cloud platform.

Key words:SOA; Stream Cloud Platform; Service Management；Load Balancer