基于變更事件驅動的微服務組合平臺設計與實現(xiàn) *

王 信,劉曉燕,張開琦,王 星，嚴 馨

(昆明理工大學信息工程與自動化學院,云南 昆明 650050)

1 引言

微服務作為一種將應用程序組織為松耦合服務的軟件開發(fā)技術，使得軟件系統(tǒng)變得模塊化，易于擴展，也有利于對每個模塊進行單獨的開發(fā)和部署。眾多互聯(lián)網企業(yè)如Google，Amazon和Twitter等都開始采用微服務架構。然而在實際應用場景中，不僅需要單個服務，更多的是需要編排多個服務的組合，即服務之間的協(xié)同工作。微服務架構出現(xiàn)之前，研究人員已經提出了幾種用于編排Web服務組合的解決方案，如：用于編排Web服務組合的業(yè)務過程執(zhí)行語言BPEL(Business Process Execution Language)及其擴展[1,2]；基于領域特定語言的方法，如S[3]和Bite[4]。然而，這些方案應用在微服務架構之后都失敗了，問題在于其要求服務有定義良好的接口以及交互信息的強類型約束，但快速變化的微服務使得難以快速定義其接口并且難以被快速部署。Yahia等人[5]提出了一種基于事件驅動的微服務組合平臺，但存在驅動事件形式單一，不支持細粒度數(shù)據(jù)訪問控制和微服務的動態(tài)部署，缺乏可擴展性、健壯性,無法檢測Web資源如XML文檔的更改事件從而觸發(fā)微服務組合的問題。

本文提出一種改進的微服務組合平臺，設計了一種支持細粒度數(shù)據(jù)訪問控制的微服務組合領域特定語言DSL(Domain-Specific Language)，實現(xiàn)基于標簽的、可配置的數(shù)據(jù)訪問控制，防止服務中的敏感數(shù)據(jù)泄漏給不受信任的服務，并在DSL層面上豐富了驅動事件的形式：事件之間的邏輯關系和疊加。同時，在現(xiàn)有微服務組合平臺中引入Spring Cloud Netflix生態(tài)系統(tǒng)，解決了微服務動態(tài)部署的問題，增強了可擴展性和容錯性。通過設計新的XML文檔比較算法，實現(xiàn)對Web資源在內容和結構2個層面的變更檢測，作為微服務組合的觸發(fā)條件，從而彌補了現(xiàn)有解決方案的不足。

2 微服務組合平臺概述

本文設計的微服務組合平臺，以領域特定語言DSL為基礎，DSL可為編程人員在高級業(yè)務邏輯與底層系統(tǒng)實現(xiàn)之間提供抽象層，從而使編程人員能專注于業(yè)務邏輯的編寫。該平臺主要包括DSL編譯器、運行時系統(tǒng)和Spring Cloud Netflix生態(tài)系統(tǒng)。平臺體系結構如圖1所示。 編程人員首先利用DSL編寫要進行編排的具體微服務組合的業(yè)務邏輯，由DSL編譯器將高級語言(DSL)代碼編譯成目標代碼(JavaScript代碼)，以在運行時系統(tǒng)上運行。在此過程中，微服務之間的組合被映射為進程間通信。 運行時系統(tǒng)基于Node.js構建，它是一個基于Chrome V8 JavaScript引擎開發(fā)的JavaScript運行時系統(tǒng)[6]。每個服務組合被隔離在不同的沙箱里面，因此不同的微服務組合之間不會互相影響。整個微服務組合平臺是輕量級的，可在有限資源的服務器如樹莓派和Docker容器中部署運行。Spring Cloud Netflix生態(tài)系統(tǒng)中的Zuul Gateway網關、Eureka服務注冊中心、Ribbon負載均衡組件和Hystrix服務熔斷機制將為平臺提供微服務動態(tài)部署的支持，提高平臺健壯性。

Figure 1 Architecture of microservice composition platform圖1 微服務組合平臺體系結構

2.1 DSL語言

為了實現(xiàn)微服務的組合，本文定義了一種領域特定語言DSL，使編程人員能夠以較高抽象層次描述微服務的組合邏輯。本文對現(xiàn)有的微服務組合平臺進行改進：通過在DSL層面定義基于標簽的訪問控制機制，實現(xiàn)可配置的細粒度數(shù)據(jù)訪問控制，防止服務中的敏感數(shù)據(jù)泄漏給不受信任的服務。對于驅動的事件，能對Web資源不同層面的變化進行變更檢測，并對驅動事件的形式進行擴展，以適應更加復雜的應用場景，如事件之間的與關系和或關系組合，同一事件重復出現(xiàn)多次的情況下才觸發(fā)微服務組合。

DSL的語法以BNF范式的形式定義如下：

comp::= composition{decl+ rule+}

decl::=pool? process ident=require(string);

|ident.init(json?);

|ident.add(ident*(,ident)*);

|ident.setlabel(user-label);

|user-label.setpolicy(motion,object-label);

rule::=on event do {action+}

event::= evt|event and evt|event or evt|(event)|evt countto integer

evt::= evt_kind(as ident)?

evt_kind::= ident:out|ident:err|ident:close| uri changed

action::=stream ident=ident.invoke(json?);

|ident.invoke(json?)

|if(expr) action(else action)?

|rule

|xpath.assign(object-label);

expr::=!expr|expr binop expr|(expr)|ident|string|integer|float|jsonpath|method(expr*(,expr)*)

xpath::={{string}}

jsonpath::={{string}}

method::=ident|jsonpath.ident

binop::=<|>|<=|>=|==|!=|&&|||

uri::=string

object-label::= confidential|secret|public

user-label::= manager|employee|stuff

motion::= read|write

在DSL的語法中，require方法創(chuàng)建進程，返回一個新的進程實例；init表示使用用戶定義的參數(shù)初始化一個進程；invoke方法表示調用一個進程，該方法返回進程調用產生的輸出流的引用。引入的進程池用pool關鍵字聲明，表示可調用多個作用相同、可互相替代的進程，當其中一個進程因錯誤無法被調用時，可調用進程池中的其他進程，保證了微服務組合中的容錯性。add方法表示向進程池內添加新的進程。

微服務組合中的事件驅動規(guī)則則由rule來表示，具體為on event do {action+}:即當事件(event)發(fā)生時觸發(fā)某一動作(action)。該事件可為進程被調用后生成的輸出流、Web資源的更改或事件之間的邏輯關系。

為了使服務中的敏感數(shù)據(jù)不被泄漏到其他不被授權的服務中，有必要在DSL層面上設計一種訪問控制機制。本文使用的訪問控制機制支持可配置的細粒度數(shù)據(jù)的訪問控制，而不是根據(jù)“全有或全無”的模式來定義訪問控制級別。此處的細粒度是指在XML文檔中屬性的內容部分。因此，使用了基于標簽的訪問控制方法LABAC(Lable-Based Access Control)[7]。

基于標簽的訪問控制方法LABAC不同于基于角色的訪問控制RBAC(Role-Based Access Control)將權限僅分配給特定的角色，用戶只能屬于某一特定角色而被賦予權限，LABAC的核心在于policy的概念，其可以表示一組復雜的布爾規(guī)則集，用于對多種不同的屬性進行評估，不僅可對用戶(user)賦予屬性，還可對資源、環(huán)境和操作賦予屬性，從而可以滿足幾乎所有的訪問控制需求[8]。

如圖2所示，object指需要施加訪問控制的對象，action表示可對對象進行的操作，如讀寫等。policy表示三元組(user-label,action,object- label)，其含義為具有某特定user-label的用戶可以對具有某object-label的對象進行指定的action操作。如前文用BNF范式表示的DSL語法，user-label可為不同的屬性，如manager、employee、stuff，且user-label可具有層次嵌套結構，例如，stuff能訪問的數(shù)據(jù)均能被employee訪問；employee能訪問的數(shù)據(jù)均能被manager所訪問。object-label可給特定對象賦予如confidential、secret、public定義隱私級別的屬性，同樣具有層次嵌套結構。setlabel和setpolicy分別表示設置用戶標簽user-label、設置策略policy。為了給細粒度的數(shù)據(jù)賦予標簽object-label，assign函數(shù)可對xpath中的對象進行操作。xpath是一種用于XML的查詢語言。

Figure 2 Label-based access control model圖2 基于標簽的訪問控制模型

2.2 DSL 編譯器

2.1節(jié)中定義的DSL代碼，可由DSL編譯器將其轉化為可在運行時系統(tǒng)中執(zhí)行的JavaScript目標代碼。DSL編譯器借助ANTLR4[9]實現(xiàn)，ANTLR4是一個語法解析器生成器，可以根據(jù)用戶所定義的語法生成語法解析器和監(jiān)聽器接口(listener interface)或訪問者(visitor)，以根據(jù)需求生成目標代碼。

ANTLR4定義了一種后綴為.g4的DSL語法文件。首先根據(jù).g4文件的語法要求，將2.1節(jié)所定義的BNF范式表示的語法轉化為.g4文件的語法。之后在Node.js的環(huán)境中，由ANTLR4根據(jù).g4文件生成所需要的語法解析器、監(jiān)聽器(listener)和訪問者。在此本文選擇以監(jiān)聽器(listener)的方式來生成目標代碼。

根據(jù)為微服務組合定義的語法，ANTLR4生成了Complistener.js文件，其包含用戶所定義的每個語法規(guī)則的enter和exit函數(shù)，但仍然需要用戶根據(jù)需求自己編寫為每個語法規(guī)則生成目標代碼的指令。但是，這種方法的缺陷在于，一旦DSL被修改，ANTLR4需重新生成Complistener.js文件，該文件原先所有的內容就被擦除，因此需要創(chuàng)建另一個名為JSlistener.js的文件，該JSlistener.js文件中再引入ANTLR4生成的Complistener.js文件，在新的listener文件中編寫代碼。

除了以上的listener文件，DSL編譯器將DSL高級代碼轉化為目標代碼還需要一個額外的implement.js文件。該implement.js文件被引入到listener文件中，主要包含3個函數(shù)：OpenTarget、CloseTarget和write，其作用分別是創(chuàng)建目標代碼文件、將數(shù)組保存到目標代碼文件中和將每一行目標代碼寫入到數(shù)組中。

2.3 Spring Cloud Netflix生態(tài)系統(tǒng)

在現(xiàn)有的微服務組合平臺解決方案中，進行微服務的組合作業(yè)之前需要先注冊每個微服務的端口等基本信息或定義“服務描述符”，這就使得無法在已有的微服務組合中動態(tài)添加新的微服務。此時必須終止微服務組合，重新注冊每個微服務的基本信息，再啟動微服務組合平臺。這使得微服務組合平臺缺乏動態(tài)部署和可擴展性。本文通過引入Spring Cloud Netflix生態(tài)系統(tǒng)中的Eureka服務注冊中心，則不需要事先注冊微服務信息，依靠服務發(fā)現(xiàn)模式即可動態(tài)確定微服務的位置，解決了微服務動態(tài)部署的問題，提高了可擴展性。此外，Spring Cloud Netflix生態(tài)系統(tǒng)中的Zuul Gateway網關、Ribbon負載均衡組件和Hystrix服務熔斷機制將為平臺提供負載均衡、熔斷保護的功能[10]，提高了平臺的容錯性和健壯性。

3 XML文檔比較算法

現(xiàn)有的基于事件驅動的微服務組合平臺，缺少對Web資源如XML文檔的比較算法或變更檢測方法，Web資源如XML文檔的變更可作為微服務組合的觸發(fā)事件?，F(xiàn)有的XML文檔比較算法多集中于對XML文檔內容或結構單一層面的比較，缺少對多種因素的綜合考慮[11]。本文提出一種新的XML文檔比較算法，能在內容和結構2個層面來比較XML文檔。具體而言，結合了內容和結構的相似度以實現(xiàn)綜合考慮的目的。對內容層面的XML文檔比較，用更先進的算法替換了原來的算法，提高了時間效率。

3.1 基于相似度的XML文檔內容和結構比較

研究人員已經提出了多種用于比較XML文檔的算法[12 - 15]，然而這些算法主要依賴于XML文檔中的主鍵，但主鍵并非在所有情況下都能定義，也并非在文檔變化中一成不變，算法也欠缺一定的靈活性，無法針對XML文檔中某個特定的元素進行相似度權重的配置。因此,Oliveira等人[16]提出了一種基于內容相似度的XML文檔比較算法。但是，該算法沒有考慮到XML文檔結構的相似度，算法的時間效率仍然可以提高。

對于結構層面的XML比較，本文將XML文檔結構轉化為時間序列，進而通過離散時間傅里葉變換得到的頻譜來進行比較[18],最后得到結構相似度。

良好的相似度函數(shù)應考慮到內容和結構的綜合，因此本文提出的相似度函數(shù)為內容相似度和結構相似度的加權平均值，如式(1)所示，內容和結構因素的權重均是可定制的，保證了一定的靈活性。

Similarity(d1,d2)=

(1)

其中，Similarity為總體相似度，contsim和strusim分別代表內容相似度和結構相似度，Wc和Ws分別代表內容和結構相似度的權重，d1和d2分別代表2個XML。

3.2 內容層面相似度的衡量

在2個XML文檔中，對于有子element的父element之間的相似度的衡量，本文采用動態(tài)規(guī)劃的思想來處理，同樣構造一個針對父element的相似度矩陣，用于衡量子element之間的相似度，這個過程一直持續(xù)到沒有更深層次結構的子element為止。對于2個(子)element之間的相似度，分為4種分量：

(1)element名稱相似度分量NS。

此處的名稱指表示一個element“是什么類型”的字符串。若此項不相同，則無法進行比較，因此假定XML文檔隨時間的演變，此項不會發(fā)生更改。

(2)內容相似度分量CS。

“內容”指element所包含的內容，可能是以下4種格式：布爾值、數(shù)字、日期/時間和字符串。對于布爾值內容，若相同，則該分量為1，不同則為0。若為數(shù)字內容，則用式(2)來衡量數(shù)字之間的相似度：

CS(e1,e2)=

(2)

其中，CS代表數(shù)字之間的相似度,abs為絕對值函數(shù)。

若為日期/時間內容，則將時間轉化為Unix時間戳，再利用式(2)計算相似度分量。若為字符串內容，則利用最長公共子序列LCS(Longest Common Subsequence)算法計算2個字符串之間的相似度。

(3)屬性相似度分量AS。

首先提取出2個element所包含的屬性名集合，若2個屬性名相同，則使用(2)中的方法比較2個屬性中內容的值。若屬性名不同，則將不同的屬性視為一個新屬性。若另一個element中沒有屬性，則將其相似度設為0。最后，將所有得到的屬性相似度除以開始得到的屬性數(shù)量，得到總體的屬性相似度分量。

(4)子element相似度分量SES。

分量的計算也使用動態(tài)規(guī)劃思想，遞歸地計算2個子element的相似度，得到相似度矩陣，由優(yōu)化算法得到總體相似度，作為子element相似度分量。

最后，2個XML element的總體相似度由上述4個分量進行加權平均得到。每個分量的權值都是可定制的，默認為25%。如式(3)所示：

Contsim(e1,e2)=(Wn*NS(e1,e2)+

Wc*CS(e1,e2)+Wa*AS(e1,e2)+

Ws*SES(e1,e2))/(Wc+Ws+Wa+Wn)

(3)

其中Contsim為內容相似度；NS,CS,AS,SES分別為計算以上4個相似度分量的函數(shù)；Wn,Wc,Wa,Ws分別為其相應的權值。

3.3 優(yōu)化算法

本文采用的優(yōu)化算法為一種改進的用于最大權二部圖匹配的分解算法，可以以更高的時間效率找出二部圖最大權匹配。該算法可以找出矩陣中滿足一定條件的元素值的最大和。在本文的背景下，即找出相似度矩陣中相似度最大的element的匹配，作為2個XML文檔的總體相似度的衡量。

找出相似度矩陣(無向帶權二部圖)中的最大element匹配的步驟如下所示：

(1)設矩陣中最大元素值為N。找出矩陣G中最大的2個元素值N和H2，并求出它們之間的差h=N-H2。記mm(G)為一個矩陣中滿足兩兩元素均不在同一行/列的元素值個數(shù)的最大值。MWBM(G)為一個矩陣中滿足兩兩元素均不在同一行/列，且元素之和最大的所有元素。Wt-MWBM(G)為MWBM(G)中所有元素之和。

(2)根據(jù)原矩陣G生成新矩陣Gh。新建一個矩陣Gh，其行列數(shù)與原矩陣相同。篩選出原矩陣中元素值在區(qū)間[N-h+1,N]內的元素，并重新賦值，賦值規(guī)則為：原矩陣元素值-h。其余元素賦以0值。

(3)為了便于表達下文的含義，如表1所示是一個矩陣以表格形式表示的例子，表格中數(shù)字即為原矩陣中的值。A和B分別代表矩陣的行和列的標號集合，Wt(A,B)表示矩陣中的元素值。定義一個函數(shù)C:A∪B→N0，滿足C(A)+C(B)≥Wt(A,B)。設Wt(C)= ∑x∈A∪BC(x)。當Wt(C)最小時，記C為一個最小覆蓋。求出矩陣Gh的最小覆蓋，記為Ch。

Table 1 Table representing matrix elements

用(5)得到的最終結果除以矩陣的秩，即可得到2個XML element的最大總體相似度。

算法偽代碼如算法1所示：

算法1最大權二部圖匹配

輸入：帶權無向二部圖G。

輸出：二部圖最大權匹配的權值和(Wt-MWBM(G))。

步驟1public static intWt-MWBM(G)= 0;/*初始值為0；*/

步驟2publicfindh(GraphG)/*計算出圖中最大2個權值之差h；*/

步驟3public classBipartiteMatching{

publicBipartiteMatching(GraphG) {}};//找出最大基數(shù)匹配mm(G)

步驟4publicformationGh(GraphG){};/*從圖G生成新圖Gh*/

步驟5public class MinimumWeightedVertexCover{

public static voidfindMinimumWeighted-VertexCoverApprox(ArrayList〈Edge〉graph,int[]weights){ };/*找出圖Gh的最小頂點覆蓋*/

步驟7BipartiteMatching(Gh)；//計算出mm(Gh)

returnh*|mm(Gh)|；/*得到最終結果Wt-MWBM(G)*/

}else{

4 微服務組合平臺實現(xiàn)

4.1 微服務組合平臺

第2節(jié)所述的微服務組合平臺可用如下DSL代碼實現(xiàn)運行：

composition {

process weather=require("getweather");

getweather.init({"latitude":"51.8498698","longitude":"-0.6637842"});

?

stream weather=getweather.invoke({"latitude":"51.8498698","longitude":"-0.6637842"});

on(weather:out as data) do {

weather-forecast.invoke("cityname":"beijing");}

DSL代碼作為高級代碼將被DSL編譯器編譯為可在運行時系統(tǒng)中運行的目標代碼(JavaScript代碼)。運行時系統(tǒng)Node.js的底層API被修改以適合微服務組合需求。如Node.js中的child_process.exec()函數(shù)應作為啟動Node.js微服務應用程序進程的函數(shù)，其子進程調用結束后的callback改為data或error，Node.js事件機制中的emitter.on(eventName,listener)修改為其函數(shù)參數(shù)與微服務組合代碼中事件驅動的參數(shù)相匹配。對于驅動微服務組合的事件形式，例如多個事件的疊加，采用基于事件訂閱/發(fā)布模式的EventProxy[19]中的after方法,可以偵聽多次相同事件或多次不同事件,待全部事件都發(fā)生后執(zhí)行相應操作。

以上示例代碼將實現(xiàn)若接收到用戶查詢當前天氣狀況的請求，作為事件驅動條件，則給出未來24 h的白天、夜晚的平均溫度(開式度)和平均氣壓數(shù)據(jù)(帕)。如圖3所示，用戶查詢到當前天氣之后，將自動啟動查詢未來天氣的微服務，以及Spring Cloud組件中的Zuul Gateway網關、Eureka服務注冊中心、Ribbon負載均衡組件和Hystrix服務熔斷組件，并在瀏覽器中查看運行結果。

Figure 3 Microservices after the composition of microservices and running results圖3 運行微服務組合后的各項微服務和運行結果

4.2 微服務組合平臺中的細粒度數(shù)據(jù)訪問控制

在微服務組合平臺中的細粒度數(shù)據(jù)訪問控制方面，本文采用的是基于標簽的訪問控制方法?；跇撕灥脑L問控制的實現(xiàn)借助PolicyLine[20]，它是一個基于屬性的Node.js訪問控制庫，涉及對4種實體(user、env、action和resource，分別代表用戶、訪問環(huán)境、操作和所訪問資源)的操作。訪問控制策略policy用于檢查訪問權限并計算condition的對象。new Policy (rules)將根據(jù)規(guī)則rules創(chuàng)建一個新的policy對象。規(guī)則rules代碼如下所示:

let rules={

effect:"permit",

algorithm:"all",

condition:[ "resource.label=confidential"]};

let policy=new Policy (rules);

其中user.label、resource.label和action.name分別代表基于標簽的訪問控制的3種標簽。target 表示用于計算policy的一組邏輯條件，可以包含任何邏輯表達式。algorithm表示根據(jù)規(guī)則計算策略的算法，可以取值為all或any。取值為all表示所有規(guī)則rules都應返回true，取值為any表示至少應有一個規(guī)則返回true。effect表示對policy計算結果所施加的影響，可取permit或deny值。當規(guī)則rules和算法algorithm綜合計算的結果為true時，則由effect值決定返回policy為true或false值。若允許則policy返回true，若拒絕則policy返回false。condition表示用于訪問資源的一組條件，可由user、env、action和resource這4種參數(shù)組成邏輯表達式。

以以下描述微服務組合的DSL代碼為例：

?

stream issues=getNewIssues.invoke({"repository":"medley/repo" });

on (issues:out as issue) do {

sendEmail.invoke({

"to":"john@doe.com","body":"New issue:{{$.issue.url}}" })};

?

為了避免issues中的數(shù)據(jù)泄漏到服務sendEmail中，需要根據(jù)基于標簽的訪問控制設定policy，核心代碼如前文規(guī)則rules所示，根據(jù)是否允許讀寫將effect的值改為permit或deny。利用Policy.check()方法驗證實例sendEmail是否可以根據(jù)所定義的訪問控制策略訪問到目標資源，結果將返回true或false。將代碼部署至CodeSandbox平臺上的運行結果如圖4所示。

Figure 4 Different access results obtained by two different access strategies圖4 2種不同的訪問策略得到的不同訪問結果

4.3 XML文檔比較

本文利用JavaFX技術構建了XML文檔比較工具，并選取不同文件大小的XML文檔組，進行10次5組XML文檔比較，每組比較分別使用匈牙利算法和3.1.2節(jié)中的優(yōu)化算法，在Eclipse控制臺中記錄得到的執(zhí)行時間(ms),結果如圖5，從圖5中可看出算法執(zhí)行耗時確實有所下降。

Figure 5 Time-consuming comparison of the two algorithms圖5 2種算法耗時比較

以圖6a中的2個XML文檔為例，根據(jù)3.1節(jié)中的公式可得內容相似度和結構相似度分別為0.75和0.58。

Figure 6 Overall similarity changes of two XML documents with different structures and different contents圖6 2個結構、內容不同的XML文檔及其總體相似度變化的曲線

考慮XML文檔內容和結構的綜合特征，通過改變權值Wc和Ws，可得到總體相似度變化的曲線為一次函數(shù)s=0.17w+0.58,如圖6b所示，w表示內容層面相似度。

5 結束語

本文設計了一種基于變更事件驅動的微服務組合平臺，其在領域特定語言層面上支持細粒度數(shù)據(jù)的訪問控制，防止敏感數(shù)據(jù)泄露給不受信任的服務，豐富了事件驅動的形式，并引入Spring Cloud Netflix生態(tài)系統(tǒng)，支持微服務的動態(tài)部署，提高了平臺的健壯性。對于觸發(fā)編排微服務組合事件的條件，增加了對Web資源(XML文檔)的變更檢測，即對XML文檔從內容和結構2個層面綜合比較，并對現(xiàn)有的XML文檔內容層面的比較算法進行了優(yōu)化。未來的工作著眼于利用機器學習技術，在執(zhí)行微服務組合作業(yè)的多節(jié)點集群的調度器中考慮每個組合的資源使用情況，以改進作業(yè)分配策略，提高集群整體資源利用率。