資源約束下的基于類依賴關系的微服務識別方法

邵建偉，劉其群，王煥強，陳耀旺，俞東進*，SALAMAT Boranbaev

（1.浙江天正思維信息技術有限公司，杭州 310006；2.杭州電子科技大學計算機學院，杭州 310018；3.河南農業職業學院旅游管理學院，鄭州 451450）

（?通信作者電子郵箱yudj@hdu.edu.cn）

0 引言

傳統的軟件系統往往基于單體式架構開發，所有的組件、模塊和資源等都集中在同一個軟件實體中。然而，隨著業務復雜度的不斷攀升，單體式軟件系統的整體復雜度和系統各個組件之間的耦合度變得越來越高，代碼也因此變得更加不可控且難以理解。微服務架構作為一個靈活的軟件架構體系，采用了分布式的服務管理模式，它將一個龐大的復雜軟件系統分解成一組相互配合的小型服務，即微服務，從而能很好地解決單體式架構高復雜度和高耦合度等問題。但是將一個單體式遺留軟件系統遷移至微服務架構是一項代價較高的任務，開發人員不僅要理清業務邏輯，更要理解程序的運行方式。特別是，如果系統功能高度耦合，這項工作將會變得極具挑戰性。因此，設計一種可自動化識別微服務的方法對于將遺留軟件系統遷移至微服務架構至關重要。

眾所周知，類通常被用來描述某個單一實體資源的屬性和行為，存在依賴關系的兩個類所操作的資源數據之間一般存在著一定相關性。而根據微服務定義，一個業務微服務可以理解為對一個業務資源的緊密相關的操作的集合。基于上述思路，本文提出了一種資源約束下基于類依賴關系的微服務識別方法。這里所謂的資源約束是指耦合較為緊密的不同類所操作的資源數據往往存在一定相關性這一事實。該方法根據遺留軟件程序中的類依賴關系構建類依賴關系圖，并設計了基于資源實體標簽的類依賴關系圖劃分算法，通過合并依賴程度較高的候選微服務，從而得到最終的微服務集合。實驗結果表明，所提方法具有較高的微服務劃分準確率，驗證了同時考慮不同類之間的依賴關系和資源約束對于微服務識別的合理性和有效性。

1 相關工作

在遷移微服務的過程中，一個重要的挑戰是如何從遺留軟件系統中識別并提取微服務。在工業界，微服務的識別與提取大多是由經驗豐富的系統架構師和業務專家一同從業務的角度著手，運用領域驅動設計［1］的方法對系統的業務領域進行領域建模，逐步分解、識別并提取微服務［2-3］。在實際應用中，Dragoni 等［4］率先嘗試將丹麥銀行的外匯核心系統FX Core 遷移至微服務架構。Gouigoux 等［5］幫助法國軟件供應商MGDIS SA基于微服務架構重新實現他們的現有應用程序，現已完成且面向公眾開放運行。同時，他們提出了將遺留軟件系統遷移到微服務架構時的三個關鍵點：合適的微服務粒度、合適的部署方式和有效的編排方式。Lotz 等［6］基于微服務架構對高級駕駛員輔助系統（Advanced Driver Assistant System，ADAS）項目進行案例研究，討論了如何解決微服務架構中錯誤分配服務等潛在危害，并分析了微服務架構在汽車場景中的弱點和威脅。O’Brien 等［7］構建了基于微服務架構提供健康解決方案的服務平臺：BPM（Beats-Per-Minute）。該平臺展示了微服務架構如何有助于BPM 系統持續獲取、分析和可視化健康相關數據。王煥強等［8］引入第三方非對稱混合加密方法，將其封裝為微服務，以解決基于微服務架構的業務流程管理平臺的通信安全問題。

在學術界，研究人員也開展了大量的研究工作。Rahman等［9］描述了行為驅動開發（Behavior-Driven Development，BDD）在微服務架構中的應用，以減少開發人員的維護負擔并鼓勵使用驗收測試。Pahl等［10］對現有的微服務研究機構進行了審查和分類，發現在現有技術水平上缺乏對微服務的工具支持。Gysel 等［11］提出了Service Cutter 方法以試圖提供一種從原始單體式架構中識別微服務的結構化方法，提出了一種通過圖切割的方法來支持結構化服務分解的工具，把軟件描述和文檔（比如領域模型和用例）作為輸入輸出以構建圖中各節點的耦合值；但是，該方法無法自動從遺留軟件系統挖掘或構造必要的結構信息，因此必須依賴用戶在特定的模型中提供軟件信息。Levcovitz 等［12］提出可以從用戶界面及其調用的業務功能和此功能所使用的數據庫表著手，通過對這些元素進行分組，以此識別微服務；然而，該方法的主要不足是它基于關于待分解的整體結構（即MVC（Model View Controller）架構）的限制性假設。Mazlami等［13］提出了三種從單體式應用程序中提取微服務的耦合策略（邏輯耦合策略、語義耦合策略和貢獻者耦合策略），并將其嵌入基于圖的聚類算法中，得到候選的微服務；但是在該方法中，其耦合策略取決于代碼的版本提交歷史。所以，如果它不可用或僅由有限數量的代碼提交組成，則該方法難以達到預期的效果。Baresi 等［14］則提出了一種基于OpenAPI（Application Programming Interface）規范中接口信息識別微服務的方法，通過將規范中使用的API 術語作為輸入并與參考詞匯表進行匹配來進行系統分解，以識別潛在的候選微服務；該方法的局限性在于依賴開發者必須提供有意義和良好定義的接口。Amiri 等［15］提出了一種基于業務流程來識別微服務的方法，該方法首先提取出業務流程，然后找出每個業務流程對實體的一個（讀/寫）操作情況以構建業務之間的相關性，最后分類提取候選微服務。此外，微服務粒度的界定也是微服務領域的一項難題。為此，鐘陳星等［16］提出了4 項評估指標，用于衡量微服務劃分的合理性，并基于此進一步提出了一種基于限界上下文的微服務粒度評估模型。

2 相關定義

定義1類依賴關系。如兩個類存在方法調用、繼承和類型依賴等關系時，則稱這兩個類具有類依賴關系，記為，其中，Ccaller表示依賴關系的發起者，Ccallee表示被依賴類。類依賴關系反映了類與類之間的耦合程度。

定義2類依賴關系圖。類依賴關系圖G=(V，E)表示了軟件程序中存在的類依賴關系，其中：V為圖中所有頂點的集合，定義為V={v1，v2，…，vi，…，vn}，每個頂點vi對應了軟件程序中的一個類ci；E為圖中所有有向邊的集合，記為E={e1，e2，…，ej，…，em}，每條邊ej即一組類依賴關系ej=。圖1給出了一個類依賴關系圖的示例。

圖1 類依賴關系圖示例Fig.1 Example of class dependency graph

定義3實體類型，實體類型集合。實體類型集合是表示用戶輸入的資源類型的集合，記為R={r1，r2，…，rk，…，rl}，其中rk即表示一個實體類型。

定義4實體匹配度。實體匹配度表示實體類型在類源碼中的重要程度，記為s(rk，cp)。

定義5實體標簽。實體標簽表示類依賴關系圖中節點vi所對應的實體類型，記為tagrk。如圖1 所示，節點v1對應的實體類型為A，實體標簽記為tagA，節點v2對應的實體類型為B，實體標簽記為tagB。

定義6繼承的實體標簽數組。由一個節點vi的所有直接父節點的實體標簽及其繼承的實體標簽集合組成的集合，記為PTags(vi)=[tag1，tag2，…，tagh]。若vi是起始節點，則其繼承的實體標簽集合為空，即PTags(vi)=[]。

在圖1 中，節點v1和節點v2的繼承的實體標簽數組為[]，節點v4的繼承的實體標簽數組為［tagA，tagB］。

定義7類依賴關系標記圖。將類依賴關系圖G中所有節點打上實體標簽之后得到的新的圖模型稱之為類依賴關系標記圖，記為Gtag。

定義8關鍵節點。在類依賴關系標記圖中同時滿足以下兩個條件的節點稱為關鍵節點。條件1：該節點的繼承的實體標簽數組中包含了多個不同類型的實體標簽；條件2：該節點的不同父節點中的實體標簽及其繼承的實體標簽數組中的實體標簽的類型不同。

如圖1 所示，節點v4就是一個關鍵節點，因為該節點的繼承的實體標簽數組中包含了tagA和tagB這兩個不同類型的實體標簽，且其父節點v1、v2包含的實體標簽也不同，分別為tagA和tagB。而節點v8則不是一個關鍵節點，因為該節點繼承的實體標簽數組中僅包含了tagB這一類實體標簽。因為微服務識別的關鍵是將原有軟件劃分為一系列耦合度較少的服務模塊，從資源調用角度講，即需要滿足：單個服務模塊內部的相同實體類型盡可能多、不同服務模塊共享的相同實體類型盡可能少，因此找到與不同實體類型相關的關鍵節點至關重要。

3 整體流程

本文方法的整體流程分為以下4個步驟，如圖2所示。

圖2 資源約束下的基于類依賴關系的微服務識別方法整體流程Fig.2 Overall process of microservice identification method based on class dependencies under resource constraints

1）構建類依賴關系圖。從軟件源碼中提取類的依賴關系轉換成Caller?Callee二維數組，并構建類依賴關系圖模型。

2）設置實體標簽。對軟件源碼進行詞法分析并構建類語料庫，通過實體類型集合設置每個類的實體標簽，并繼承和重置自身的實體標簽，得到類依賴關系標記圖。

3）圖模型劃分。根據本文提出的基于實體標簽的劃分算法對類依賴關系標記圖進行分割。

4）合并微服務。根據微服務對外依賴程度合并聯系緊密的候選微服務。

4 方法描述

4.1 構建類依賴關系圖

本文使用如下方法識別類依賴關系：首先，使用工具javacallgraph（https：//github.com/gousiosg/java-callgraph）從軟件程序源碼中提取出類之間所有的依賴關系保存為Caller?Callee二維數組，其中Caller?Callee二維數組的第一維度是依賴類Ccaller，第二維度是被依賴類Ccallee。然后對Caller?Callee二維數組進行依賴關系清洗，清洗操作包含以下3個步驟：

1）過濾無關依賴。開源工具java-callgraph 提取出來的依賴關系包含大量對第三方類的依賴，比如對java.util.*和org.springframework.*的依賴關系。這些依賴關系的存在對研究軟件資源的相關性毫無幫助，還會影響類依賴圖結構的完整性。

2）過濾重復依賴。因為類依賴圖屬于有向無權圖，每一對依賴只需要記錄一次即可，所以需要把重復的依賴關系過濾掉。

3）過濾自我依賴。為了避免后續設置實體標簽時的自我循環設置，需要預先過濾自我依賴的類依賴關系。

最后將清洗后的Caller?Callee二維數組構建為類依賴關系圖G，并用鄰接矩陣表示，其中Ai，j表示節點vi和節點vj在圖中是否存在依賴關系，其計算方法如式（1）所示：

4.2 設置類實體標簽

為了給每個類設置實體標簽，需要提取出軟件程序中所有類的源碼，并根據用戶設置的實體類別，計算每個類實體匹配度，將值最高的實體類別作為該類的實體標簽。

1）詞法分析。

軟件程序的類中包含大量體現類作用的代碼元素（類名、方法名和變量名等），但是也存在一些對理解類作用沒有幫助的元素（停用詞和關鍵字等），所以需要從軟件源程序中提取出所有能體現類作用的代碼元素。為此，本文將軟件程序中的每一個類分別構建成一棵抽象語法樹（Abstract Syntax Tree，AST），再從對應AST 中的類節點提出類源碼，并對獲得的類源碼進行詞法分析，構建一個由類組成的語料庫C={c1，c2，…，cp，…，cn}，其中語料庫中的每個元素cp由源碼中對應類的詞匯組成。

2）設置節點自身的實體標簽。

實體匹配度表示實體類型在類源程序中的重要程度。本文方法使用詞頻-逆文檔頻率（Term Frequency-Inverse Document Frequency，TF-IDF）算法計算類與實體類型rk的實體匹配度s(rk，cp)，計算公如式（2）所示：

此外，在軟件程序中，類可以分為負責業務邏輯的業務功能類和提供通用操作的工具類。前者一般具有較高的實體辨識度，而后者則相反。如式（3）所示，對于業務功能類，可以直接選出實體匹配度最高的那個實體類型作為該類的實體標簽；而對于工具類，因為其與任何實體類型計算所得實體匹配度都為0，所以將其實體標簽設置為NULL。

最后在計算完類cp的實體標簽tagrk之后，將其標記到類依賴關系圖中對應節點上，得到新的類依賴關系標記圖Gtag。

3）繼承父節點的實體標簽。

因為一組存在依賴關系的兩個類具有資源操作相關性，所以為了更好地表示類之間的資源上的聯系，類依賴關系圖中的后續節點的繼承的實體標簽數組應該包含所有父節點的實體標簽及其繼承的實體標簽數組。如圖3 所示，節點v5本身的實體標簽為tagA，且該類分別被節點v1、節點v2和節點v4所依賴，那么節點v5最終繼承實體標簽數組PTags(v5)為[tagA，tagB，tagC，tagC]。

圖3 繼承父節點實體標簽示意圖Fig.3 Schematic diagram of inheriting entity labels of parent nodes

4）重置實體標簽。

對于任意節點vi，如果該節點的所有父節點均屬于同一實體類型，但是與該節點自身的實體標簽不同，則將該節點自身的實體標簽更新為父節點的實體標簽。如圖4 所示，節點v4自身的實體標簽為tagB，而其所有父節點v1、v2和v3的實體標簽均為tagA，所以應當將節點v4的實體標簽更新為父節點的實體標簽tagA。

4.3 基于實體標簽的圖模型劃分

為了從軟件系統中識別出合理的微服務，本文將軟件系統按照實體類型進行劃分，即一個微服務中的類所標記的實體類型盡可能一致。因此，本節提出了基于實體標簽的圖模型劃分方法，該方法的劃分原則是將重置實體標簽后的類依賴關系標記圖Gtag劃分成一系列沒有交集的子圖，且滿足子圖內部節點的相同實體類型盡可能多、子圖之間的相同實體類型盡可能少。其關鍵是要識別類依賴關系標記圖中所有合理的關鍵節點，并根據對應的劃分規則將所有關鍵節點劃分至合理的子圖中，這些相互獨立的子圖就是一個個初步識別的候選微服務。

圖4 重置實體標簽示意圖Fig.4 Schematic diagram of resetting entity labels

1）識別合理的關鍵節點。

如何識別類依賴關系標記圖中的關鍵節點是本文方法的關鍵之一，對于任一節點，若該節點是關鍵節點，則必須要遞歸判斷父節點是否為關鍵節點。這是因為當一個節點vA的父節點和祖先節點中也存在關鍵節點vp時，如果把節點vp按照劃分規則處理完后，節點vA則可能會變成非關鍵節點。如圖5 所示，節點v3和節點v4都是關鍵節點，且節點v3是節點v4的父節點。如果直接根據關鍵節點劃分規則處理節點v4，則還需要再處理一次節點v3，但是事實上這是沒有必要的，因為只需要將節點v3按照關鍵節點劃分之后，節點v4就會變成非關鍵節點，所以需要先遞歸處理父節點中的關鍵節點以保證方法的高效性。

圖5 遞歸父節點劃分示意圖Fig.5 Schematic diagram of dividing parent nodes recursively

2）劃分關鍵節點。

對于關鍵節點的劃分，根據節點類型的不同，其劃分規則也不相同。

a）對于業務功能類型的關鍵節點，根據其自身的實體標簽，將其歸類至相同實體標簽的父節點所處子圖，并將該節點與不同實體標簽的父節點連接的邊斷開，完成后更新該節點及其子節點的繼承的實體標簽集合。

b）對于工具類的關鍵節點，本文將其在每個不同資源的父節點下都復制一份，完成后更新該節點及其子節點的繼承的實體標簽集合。

基于實體標簽的圖模型劃分算法如算法1所示。

4.4 候選微服務優化

在基于資源約束初步識別微服務之后，有些微服務之間還可能存在著頻繁的依賴關系，比如微服務MSb中的類依賴微服務MSd中的類所提供的數據和操作，如果直接部署使用這些依賴頻繁的微服務，將會增大微服務MSb中對外接口的使用成本（比如增加了接口調用的時間成本），因此可以合并相互依賴頻次高的微服務以提高其服務質量。

本節基于微服務間依賴頻次最小化原則設置了微服務對外依賴指標。本文把微服務MSb對微服務MSd的所有類中的函數調用稱之為微服務MSb對微服務MSd的依賴值dep(MSb，MSd)，并把微服務MSb對其他微服務的依賴值的集合定義為dep(MSb)={dep(MSb，MSd)|b∈h，d≠b}，其中h表示微服務的總數量。當微服務MSb對微服務MSd的依賴值dep(MSb，MSd)大于微服務整體的依賴值時，可以認為兩個微服務之間的緊密程度過高，可合并成一個微服務，其中微服務的整體依賴值計算方法如式（4）所示：

其中，|dep(MSb)|表示MSb對其他微服務的依賴值的集合中元素的個數。

5 實驗與結果分析

5.1 實驗環境

本文實驗的環境配置如下：處理器為Intel Core i5-6500 CPU@3.20 GHz；內存為12 GB；操作系統為Windows 10 企業版64 位；編譯語言為Python 3.7.0；集成開發環境為PyCharm 182.5107.22。

本文實驗使用的數據集為來源于GitHub 的4 個項目：Kanban （https：//github.com/eventuate-examples/es-kanbanboard）、Money Transfer（https：//github.com/cer/event-sourcingexamples）、Piggy Metrics （https：//github.com/sqshq/PiggyMetrics）和Microservice Event Sourcing（https：//github.com/chaokunyang/microservices-event-sourcing）。

5.2 實例分析

本節使用測試項目MES（Microservice Event Souring）進行實例分析。圖6和圖7展示了實驗結果。

圖6 未過濾合理劃分的類的實驗結果Fig.6 Experimental results without filtering out reasonably divided classes

圖7 過濾合理劃分的類之后的實驗結果Fig.7 Experimental results after filtering out reasonably divided classes

作為本文方法的一個設計原則，一個微服務不應該包含其他微服務的業務類。如果一個微服務需要使用其他微服務的業務數據，可以通過訪問對應的業務接口來完成數據請求，所以圖6 中微服務User、Shopping Cart、Inventory 和Order 中未包含其他微服務的業務類是合理和符合設計原則的，比如微服務Shopping Cart 中的Order、OrderEevent、OrderEventType 和OrderStatus 四個類都是屬于微服務Order 的類，同時Address和AddressType 這兩個類在微服務Inventory 中僅類被Order使用，所以本文方法的劃分中也應該是不屬于微服務Inventory。

此外，通過本文方法識別得到的微服務Inventory 中包含的類AddressType 和類BaseEntity 也是屬于合理劃分的，因為微服務Inventory 中包含了類Address 和類DatabaseInitializer，這兩個類分別對類AddressType 和類BaseEntity 存在依賴關系，且類AddressType 和類BaseEntity 屬于非業務類，所以其被劃分在微服務Inventory中是合理的。

在過濾掉上述合理劃分的類之后，重新整理實驗結果，如圖7 所示。結合MES 源程序可以發現，微服務中應該包含而沒有出現的類具有以下兩類特征：

1）依賴關系中未包含該類信息。比如微服務User 中的ResourceServerConfig、CacheConfig、LoginController和WebMvcConfig 這四個類，這些類不存在和其他類的依賴關系，所以類依賴關系圖中沒有這四個類的信息。

2）雖然微服務中未包含該類，但是依賴關系中存在微服務中某類對該類的依賴。比如微服務Order 中的Invoice、InvoiceRepository、InvoiceStatus 和Customer 這四個類，Invoice、InvoiceRepository 和InvoiceStatus 這三個類存在相互之間的依賴關系，但是在原程序的微服務Order中沒有其他類對其存在依賴關系，所以本文方法在劃分時沒有將其劃分到微服務Order中。同理也沒有將類Customer劃分到微服務Order中。

而通過對微服務中原本沒有包含卻出現了的類進行分析，發現微服務Inventory 之所以包含了類CreditCard 和類CreditCardType 是因為這兩個不屬于任何一個實體類型，而且在微服務Inventory 中存在對類CreditCard 的依賴關系，所以本文方法將類CreditCard和類CreditCardType劃分到了微服務Inventory中。

5.3 評價指標分析

本文實驗通過正確識別的類來計算微服務劃分準確率指標，計算方法如式（5）所示：

其中：|Cright|表示項目中正確劃分的類的數量；|Call|表示項目中類的總數量。

從表1 可以看出，本文方法對各個實驗測試項目都能取得良好的效果。對Kanban、Money Transfer 和Piggy Metrics 三個測試項目，本文方法都取得了極高的微服務劃分準確率，幾乎和原程序的劃分一致。而對于測試應用程序MES，本文方法雖然準確率略低于其他三個，但是仍具有高于90%的微服務劃分準確率。

表1 本文方法的類劃分結果Tab.1 Results of class division obtained by proposed method

另外，本實驗從微服務劃分是否合理的角度出發，設置了微服務識別精確率來驗證本文所提方法的有效性。該指標用來衡量本文方法識別出來的微服務中屬于合理微服務的比例。

圖8 給出了本文方法與文獻［17］方法的對比結果。從圖8 中可以看出，本文方法的微服務識別精確率相較于文獻［17］方法性能更優。

5.4 性能分析

最后，實驗還分析了本文方法的性能，即不同測試項目的實驗所需時間。為排除偶然因素的影響，對每一個測試項目都重復50次實驗，實驗結果如圖9所示。其中，圖9（a）縱坐標軸表示本文方法執行一次所需的時間，圖9（b）表示各測試項目的類及類依賴關系的數量。從圖9 中可以得知，本文方法具有良好的運行性能，其執行時間隨著測試項目中的類數量的增加而增加。同時由測試項目MES 和測試項目Piggy Metrics 的執行時間對比可知，本文方法的性能同時還受到類依賴關系數量的影響。

圖8 微服務識別精確率對比Fig.8 Accuracy comparison of microservices identification

圖9 本文方法的性能實驗結果Fig.9 Experimental results on performance of proposed method

6 結語

本文提出了一種資源約束下的基于類依賴關系的微服務識別提取方法。該方法不僅可從遺留軟件代碼中自動識別出合理的微服務，還可幫助開發人員將源程序中的類劃分至相應的微服務中，進一步降低了開發人員遷移遺留軟件系統的工作量。因為該方法依賴第三方開源工具從源程序中提取類依賴關系，如果提取出來的類依賴關系不完全，則會在一定程度上影響微服務識別的結果。因此，在未來的工作中，我們計劃進一步研究如何提取完整的類依賴關系，以便進一步提高識別合理的類依賴關系的準確性。