基于SOA架構的新型云平臺服務管理中間件

陳世宜，葉德建

?

基于SOA架構的新型云平臺服務管理中間件

陳世宜，葉德建

摘 要：隨著云計算技術的發展，針對細分行業的云平臺不斷涌現。以流媒體云平臺為代表的私有云，為了降低成本、兼容原系統，通常采用整合服務的方式實現，隨著系統的升級、模塊集群化的增強，傳統的負載均衡中間件難以有效處理服務間的頻繁長鏈調用。針對傳統流媒體云平臺采用負載均衡中間件實現子服務調用存在的靈活性差、效率低、可用性低等問題，設計并實現了一種新型的針對基于SOA構架的流媒體云平臺應用層服務管理系統，該系統采用生產者/消費者模型，通過注冊中心配對的方式實現高效靈活的服務調用，提高云平臺整體性能。

關鍵詞：SOA；云平臺；服務管理；負載均衡中間件

0　引言

隨著互聯網行業的發展以及云計算技術日益成熟，云平臺因其低成本、可拓展、高可用、高性能等優勢被業界廣泛使用，越來越多的企業業務被遷移至云平臺。因為各領域業務需求千差萬別，所以出現了各類行業細分云，如金融云、視頻流媒體云、電子商務云等。

為了降低成本、提高效率、應對服務靈活多變的特性，企業云或行業云作為一種新型的產業升級方式，普遍采用服務整合的方式來架構云平臺。具體體現為通過模塊化重構原有系統，將原本業務系統抽象為功能服務，而隨著系統升級產生的新型業務則可以通過服務組合來實現。在技術實現層面上，服務組合表現為約定協議、統一接口系統間的調用，常以web服務調用作為其基本實現方式[1]。

隨著云平臺業務拓展，內部模塊化服務系統間的調用日益復雜；同時，為了保證云平臺的性能需求，大量子服務系統采用分布式架構。以上的發展趨勢都在一定程度上增大了子服務系統間通訊、調用的難度[2]。為了提高各個組合服務的吞吐率并縮短響應時間，亟需開發一種高效的云平臺服務管理中間件[3]。

本文研究分析了現有流媒體云平臺服務通信機制，發現并指出其存在的效率低、靈活性差、可用性低等問題，借鑒并改進了 SOA（面向服務的架構）的基本服務管理策略，針對流媒體云平臺具體應用場景設計了一種基于SOA架構的新型服務管理中間件，旨在提供一種高效靈活的云平臺服務間通信機制。

1　原流媒體云平臺服務管理

1.1 流媒體云平臺概況

流媒體云平臺如圖1所示：

圖1　流媒體云平臺架構圖

底層實現可簡單抽象為計算服務與存儲服務兩部分。計算服務，主要包括前端HTTP服務器及應用服務器；存儲服務，主要包括SQL數據庫集群、內存緩存集群、對象存儲服務和大數據處理平臺等。計算服務分布在虛擬機上，利用虛擬機平臺提供的資源隔離機制提高云平臺服務器資源的利用率，同時由于計算服務本身無狀態的特性，使用虛擬化技術并不損失系統的可用性。存儲服務分布在物理機上，確保數據訪問性能并提供數據的可靠持久化。

海量客戶端發送請求至云平臺，通過負載均衡集群將請求轉發至前端HTTP服務器，前端服務器從對象存儲中讀取視頻圖片等資源，并調用應用服務層服務，應用服務借助內存緩存集群提高操作響應速度，將日志等信息存儲在NoSQL大數據平臺待進一步數據挖掘與分析，而業務信息則統一存儲在SQL集群中。

云平臺的應用服務層通過各個服務模塊系統的組合調用完成，將基本業務抽象為幾大核心服務，包括視頻點播、云解碼、視頻質量監控、終端狀態統計、個性化推薦、云推送等，借助各個服務間的組合提供彈性靈活的業務功能和各個核心服務內部又可以劃分為更細粒度級的子服務組合。終端用戶請求視頻點播時調用的子服務，如圖2所示：

圖2　點播業務子服務分解

當終端用戶請求視頻點播服務時，首先需要經過用戶認證系統加以認證，確定用戶信息，進行點播操作，依次調用賬戶查詢服務、定價服務以及收費服務，同時系統也向用戶推薦影片，依次調用個性推薦服務及影片信息服務。所以在流媒體云平臺中的服務調用存在如下特點：1）存在大量針對業務邏輯的服務調用，因此大部分服務都需要在基于虛擬機的服務器上進行。2）針對基礎服務的請求多為長鏈調用。3）服務間的組合紛繁復雜，會出現交叉調用的情況。

1.2 基于負載均衡中間件的服務管理

目前流媒體云平臺采用負載均衡中間件來處理服務間的調用，如圖3所示：

圖3　負載均衡原理

負載均衡中間件一般用來應對高并發用戶請求，通過負載均衡技術將不同的請求分配給不同的服務器處理，可以有效緩解單臺服務器的壓力[4]。而在云平臺的服務調用過程中，業界普遍利用負載均衡中間件對外表現統一接口，高效轉發請求的特性。在處理服務間的調用時，首先將不同服務的服務地址及路徑記錄在負載均衡“轉發表”中，從而使服務間的RPC調用請求首先發送到負載均衡中間件，負載均衡中間件根據已配置好的“轉發表”中的記錄，將客戶端的請求轉發對應的應用服務器來進行處理。負載均衡器與服務器之間有心跳檢測，當應用服務器不可用時，負載均衡器將失效服務器的地址從“轉發表”中臨時性刪除，當該服務器恢復工作之后，負載均衡器可以將其地址重新添加到“轉發表”。為了避免負載均衡中間件出現單點故障的風險，可通過心跳機制維持多臺備份。

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

目前主流的負載均衡中間件主要有Nginx、HAProxy、LVS等。針對問題1，LVS技術只轉發請求不轉發響應，在一定程度上提高了效率，但是LVS并不適用于虛擬機通訊，因此在流媒體云平臺系統中無法發揮優勢；由于流媒體云平臺的基礎服務多為長鏈調用，問題1、2在流媒體云平臺中表現得更為突出；由于流媒體云平臺中的服務調用復雜，在出現問題3時人力成本加重。所以，負載均衡中間件并不是流媒體云平臺服務管理的最佳方案。

2　新型云平臺服務管理系統

針對以上問題，本文設計并實現了一種基于SOA 的新型服務管理中間件來解決流媒體云平臺中系統調用的問題。本系統將服務間 RPC調用抽象為應用層服務，將服務調用的雙方抽象為生產者和消費者的模型，服務提供方與請求方通過注冊中心完成配對，在請求方緩存可調用提供方信息，同時監控中心記錄消費者與生產者調用記錄，作為日后負載均衡評估算法權重的數據信息。這樣的設計首先縮短了采用負載均衡模式產生的通信耗時，注冊中心只負責配對，而具體交互由請求方和提供方獨立完成，不必經由負載均衡器轉發；注冊中心采用Zookeeper集群，同時請求方緩存提供方信息，這都提高了系統的可用性；注冊機制以及實時監控也保證了服務提供方的變更可以及時更新。本中間件處理服務調用的具體流程如圖4所示：

圖4　中間件工作流程

1）服務提供方向注冊中心注冊所提供的服務。2）請求方向注冊中心請求服務。3）注冊中心在注冊表中查找相關服務，并通過負載均衡策略將特定服務提供方通知給請求方。4）請求方此時獲得了提供方的地址，可以直接調用提供方的服務，同時在收到注冊中心下一次通知前持續調用該提供方服務。5）同時服務請求方與提供方將此次調用的結果記錄在監控中心，作為負載權重計算的原始數據[5]。6）監控中心將計算結果以通知的方式發送給注冊中心。以下小節針對本中間件各層實現具體展開。

2.1 通信層

本中間件通訊層采用基于NIO的Netty框架實現。相較于傳統IO，NIO通過選擇器、通道、緩沖區的設計實現了高性能非阻塞IO讀寫機制，支持高并發，同時編程實現簡單。Netty在NIO的基礎上對其進行了封裝，提供了一套異步的、事件驅動的網絡應用程序框架和工具。在此框架下，本中間件設計了符合應用場景的自定義協議來完成服務提供方、服務請求方、注冊中心、監控中心間的交互。

通訊協議主要包括協議頭與協議數據兩部分內容。如圖5所示：

圖5　自定義協議內容

協議頭主要包括：信息標志位、操作標志位、協長度以及超時時間字段。信息標志位可設置值為請求、回復與通知，可用2比特位表示。操作標志位取值為服務注冊、服務請求、服務通知、請求調用記錄、調用結果記錄以及監控回饋，可用1字節表示。長度字段顯示協議體字節長度。超時時間字段確保服務無法得到回應時，由請求方再次發起請求。

協議體設計針對具體的通信場景設計了服務 ID、服務類型、IP地址、端口號、服務位置、會話ID、時間戳以及操作結果字段。在以上通信場景中，各字段的使用情況如表1所示：

表1　自定義協議內容

2.2 注冊中心

注冊中心實現了本中間件的主要業務功能：為服務請求方和服務提供方的連接提供了媒介；通過最優選擇方式實現了負載均衡；與服務提供方保持長連接以及時修改各服務當前狀態。

2.2.1 流程設計

注冊中心的基本業務流程如圖6所示：

圖6　注冊中心流程設計

在本服務啟動階段，注冊中心接受來自各個服務器的消息，通過信息類型判斷后續操作。如果為請求信息，則再次通過解析協議頭的操作標志位字段判斷協議類型。若為注冊服務，在當前注冊表中根據IP地址，端口號以及服務地址構成的服務唯一標識判斷服務是否已經注冊，對于已經注冊的服務回復注冊失敗消息，消息體中包含錯誤碼及錯誤信息，對于新注冊的服務，將其寫入注冊表中，并回復注冊成功，同時與其保持長連接，通過心跳機制確定服務提供方是否可用；若為請求服務，則在注冊表中查找該類型服務的提供方，同時根據權重選擇最優服務 ID，將其通知給請求方。若信息類型為通知類型，則修改注冊表中的選擇權重數值，同時通知給全部消費者。

2.2.2 存儲支持

本中間件作為云平臺應用層服務，為了實現平臺整體的可拓展、高性能、高可用等特性，注冊中心采用了分布式的設計，即建立注冊中心集群，這樣一方面避免了單點故障的風險，另一方面在注冊中心處理大規模并發請求時極大地縮短了等待時間，提高系統性能，改善服務質量。

注冊中心通過Zookeeper來實現分布式存儲。Zookeeper是一種開源的分布式應用程序協調服務，提供了配置維護、名字服務、分布式同步、組服務等功能，其核心基于 Fast Paxos算法，通過投票選舉協議確保存放在各個節點上的數據能夠保持強一致性。

注冊中心主要存儲各個服務的注冊信息以及當前狀態。注冊表以關系型數據庫表的形式將注冊服務持久化，該表中包含的字段為：服務ID、IP地址、端口號、服務位置、服務類型、選擇權重以及可用狀態。服務ID為自增字段，每當有一個新的服務請求注冊時，根據核對之前表中的IP地址、端口號和服務位置來判斷該服務是否應該被注冊，若為新服務則產生新服務ID分配給該服務。每個服務的IP地址、端口號和服務位置從通信信息中直接讀取，并記錄在注冊表中。選擇權重用于注冊中心匹配算法，由監控中心產生，并發送給注冊中心。服務類型用以區分提供方提供的不同服務，多個服務可提供相同類型服務。可用狀態信息根據注冊中心與各個服務提供者間的心跳狀態及時更新。

2.2.3 匹配策略

注冊中心針對請求服務會首先在注冊表中選擇提供該類型服務的一組服務 ID。此時為了提高系統效率，減少調用失敗，注冊中心首先會篩選此時可用的服務，即可用狀態為True的服務。在完成第一輪篩選后，根據權重值，選出權重最大的服務，將其封裝為通知消息發給服務請求方。權重值的計算由監控中心完成，這在一定程度上減輕了注冊中心的負擔。

2.3 監控中心

本中間件中的監控中心主要負責收集數據，并根據權重算法計算注冊表中的新權重，計算結束后將結果以信息形式發送給注冊中心，作為每次匹配依據的權重值。

2.3.1 數據采集

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

2.3.2 權重計算

為了提高系統的整體效率，縮短調用耗時，同時合理分配資源，注冊中心針對每次具體請求的配對過程中，應考慮以下4點主要因素：1）提供方服務器最近是否過載，目前無法處理服務請求；2）當前各服務提供方機器任務分配情況；3）服務提供方機器最新處理特定服務請求耗時情況；4）服務提供方歷史處理特定請求情況。以上四點因素對于分配結果的影響效果依次遞減。結合監控中心收集的數據，可以依次表示以上因素如下。

服務提供方是否過載可通過請求方請求超時的結果γ(IP)表示。對于分配權重的影響直接表示為 Wγ(IP) {0,1}，0代表當前狀態未過載，1表示出現過載，即收到請求方發送的超時消息。

當前各服務提供方機器任務分配情況以任務數來進行表示，即 N=,n N。機器分配情況對于權重的影響可以抽象為。即權重隨著請求方任務數的增多而急劇減少，這在一定程度上可以避免服務發生過載情況。

服務提供方機器最近處理特定服務請求耗時情況根據最近次耗時的絕對值進行計算。最近次耗時的絕對值表示為t(end)- t(start)，分配權重為WT，具體計算方式如公式（1）：

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

服務提供方歷史情況基于以往 N次處理此類服務所需時間進行計算，即 H=<Δt1,Δt2,Δt3…>,其中分配權重為WH。WH主要由兩部分組成，即以往歷史調和均值以及歷史波動，即均值越高處理時間越長，浮動越大越不穩定，那么相應的權重值也越低。具體計算方式如公式（2）：

影響匹配結果的權重計算基于以上 4種子權重的綜合考慮，根據各個權重的影響強弱，綜合為最終的權重計算方式如公式（3）：

即計算權重時，可以充分保證4種因素對于權重的影響的優先級順序，即若

根據以上一套計算權重的算法，對每一臺提供服務的機器都產生相應的權重值，以在匹配過程中使用。監控中心的權重算法配合注冊中心的匹配機制保證系統盡可能使用運轉良好，處理速度快，性能穩定的機器來應答請求，從而降低系統平均處理用時，提高系統的處理效率，增強系統可用性，縮短請求方等待時間，提升整體性能，使得用戶有更好的使用體驗。

2.4 服務提供方/服務請求方

在本中間件中，服務提供方和請求方采用了簡潔的設計模式，計算處理主要由注冊中心及監控中心完成。請求方與提供方依托自定義協議向注冊中心及監控中心發送信息，包括注冊，請求以及記錄等類型消息，并且對于來自注冊中心以及監控中心的信息進行解析處理，完成業務邏輯。同時為了提高系統的吞吐量和可用性，請求方緩存處理相應服務的提供方地址，只在接收到注冊中心通知的情況下更改服務提供方信息，減少了反復請求建立連接的消耗，同時也便于在注冊中心失效時，依然可以正常調用服務。

3　系統測試

本中間件作為應用層系統中間件應用于清鶴流媒體云平臺，解決私有云平臺中業務服務間RPC調用的問題。針對該系統的處理效率和吞吐量等指標設計了相應實驗進行測試。實驗環境為清鶴流媒體云平臺的虛擬機測試環境，每臺虛擬機的配置相同，如表2所示：

表2　測試環境硬件配置

各服務器網卡均為千兆網卡，所在網絡的交換機速率為10Gbit/s，即網絡環境不會成為實驗瓶頸。原系統負載均衡中間件采用HAProxy1.4.24，Web服務采用Apache Tomcat 8.0服務器。

3.1 響應時間測試

本實驗在服務調用效率方面對新型中間件與傳統負載均衡中間件進行了對比。由于在單次服務調用過程中會發生多次RPC調用，因此，本文定義服務調用的鏈長為單次服務請求過程中發生的RPC次數。本實驗通過測試不同鏈長的服務請求的響應時間來衡量新舊中間件通信效率。

實驗過程如下：使用CURL工具模擬服務調用的HTTP請求，模擬過程共分20組，每組服務調用鏈長不同；每組進行20次服務調用，記錄每次通信耗時；將每組的實驗數據進行排序，選擇排序結果為8至12位的5組數據作為最終結果，以排除測試中由于網絡環境等因素影響而產生的數據噪點如圖7所示：

圖7　新舊系統效率對比

圖7為新舊中間件針對相同簡單長鏈請求時耗的測試結果，從中可以看出隨著鏈長的增加改進中間件相對于原始中間件的優勢越明顯。如當服務鏈長為20時，新系統平均處理時間為447.2毫秒而原始系統則高達517.6毫秒，針對鏈長大于5的服務調用，新中間件的效率提高了10%以上。而產生這樣改變的主要原因在于去中心化的設計思路，隨著系統的啟動，當服務請求方獲得了來自注冊中心的通知后，再次進行服務調用時可以省去與中間件的交互，從而極大的提高了通信效率。

3.2 吞吐量測試

本實驗在服務吞吐量方面對新型中間件與傳統負載均衡中間件進行了對比。由于系統吞吐量本身也受服務請求鏈長的影響，因而在實驗中設計了針對不同服務請求鏈長下新舊中間件的吞吐量測試。

實驗過程如下：采用http_load壓力測試軟件，模擬50個客戶端同時發起的10000個服務請求，記錄新舊中間件在以下情況下的吞吐量；針對不同鏈長的服務調用進行測試，分為鏈長2-4的短鏈服務組與鏈長為10左右的長鏈服務組，長、短鏈組分別進行9次測試，并記錄每次測試的吞吐量；將每組的九次實驗結果排序，取排序結果第五位的數據作為最終結果，以排除意外情況造成的偏差。

實驗結果如下圖8所示：

圖8　新舊系統吞吐量對比

由實驗結果可以看出，改進系統的吞吐量明顯優于原系統，而且相對于短鏈請求，長鏈請求的優勢更明顯。同時原系統由于HAProxy本身的壓力，在鏈長增加的情況下吞吐量顯著減少，而新系統在一定程度上緩解了這種壓力，在應對長鏈請求時也表現了很好的性能。

4　總結

本文分析了目前流媒體云平臺使用的傳統負載均衡中間件系統原理，提出了其在長鏈調用等工業界應用場景日漸復雜過程中出現的實際問題，并且針對細分領域、結合流媒體云平臺的特點，設計并實現了一種用以解決應用層 RPC調用服務的基于 SOA 構架的新型云平臺服務管理中間件。該設計實現改善了原本使用負載均衡中間件產生的系統性能瓶頸，在長鏈調用中使得系統的吞吐量提升了近5倍。其次，本中間件縮短了服務調用耗時，提高了系統效率，在長鏈調用中時耗縮短了近10%。因此，本中間件提供了一種真正靈活高效，性能優越的流媒體云平臺服務調用解決方案。

參考文獻

[1] 梁爽. 基于 SOA的云計算框架模型的研究與實現[J].計算機工程與應用,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] 杜垚,郭濤,陳俊杰. 云環境下機群彈性負載均衡機制[J].計算機應用,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.

中圖分類號：TP312

文獻標志碼：A

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

收稿日期：（2016.01.02）

基金項目：上海市科委項目（12511503002）；

作者簡介：陳世宜（1990-），女，吉林，復旦大學軟件學院，碩士研究生，研究方向：網絡多媒體，上海，201203葉德建（1976-），男，浙江，復旦大學軟件學院，副教授，研究方向：網絡多媒體，上海，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