鐘陳星,李杉杉,張 賀,章 程
1(南京大學(xué) 軟件學(xué)院,江蘇 南京 210023)
2(計算機(jī)軟件新技術(shù)國家重點(diǎn)實驗室(南京大學(xué)),江蘇 南京 210023)
3(安徽大學(xué) 計算機(jī)科學(xué)與技術(shù)學(xué)院,安徽 合肥 230601)
伴隨著互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展和市場需求的急劇擴(kuò)增,軟件應(yīng)用是否可以靈活地調(diào)整業(yè)務(wù)與規(guī)模,持續(xù)交付部署,快速更新迭代成為企業(yè)在現(xiàn)代化商業(yè)競爭中取勝的決定性因素.然而,傳統(tǒng)的軟件開發(fā)采用單體架構(gòu)(monolithic architecture)[1]方式,將應(yīng)用程序的所有功能封裝在一個獨(dú)立的單元中,隨著軟件系統(tǒng)復(fù)雜度的劇增和開發(fā)團(tuán)隊的擴(kuò)大,逐漸暴露出其不夠靈活、開發(fā)效率低下以及妨礙持續(xù)交付與部署等缺點(diǎn).
針對軟件敏捷性、靈活性和可擴(kuò)展性需求的不斷增長,使得突破單體架構(gòu)的限制成為亟待解決的問題,也使得微服務(wù)架構(gòu)(microservices architecture)[2]應(yīng)運(yùn)而生.微服務(wù)架構(gòu)將一個獨(dú)立的應(yīng)用程序分成多個協(xié)同工作的小而自治的服務(wù),每個微服務(wù)通常只完成某個特定的功能,并且運(yùn)行在單獨(dú)的進(jìn)程中.相較于單體架構(gòu),微服務(wù)在面對快速發(fā)展變化的業(yè)務(wù)需求時表現(xiàn)出更加敏捷(agility)、靈活(flexibility)及可擴(kuò)展性(scalability)等優(yōu)點(diǎn).具體來說,微服務(wù)擁有技術(shù)異構(gòu),不同的服務(wù)采用適合的技術(shù);對數(shù)據(jù)進(jìn)行“去中心化”控制,不同的服務(wù)無需共享一個中心數(shù)據(jù)庫;智能端點(diǎn),服務(wù)管理相關(guān)業(yè)務(wù)邏輯并通過輕量級的消息交互與其他服務(wù)通信;圍繞業(yè)務(wù)功能組織服務(wù),負(fù)責(zé)服務(wù)開發(fā)的團(tuán)隊同時負(fù)責(zé)該服務(wù)相關(guān)業(yè)務(wù)需求的所有實現(xiàn)細(xì)節(jié)等特性[3].微服務(wù)的這些特點(diǎn)與DevOps 提倡的生產(chǎn)環(huán)境的彈性、可靠性、穩(wěn)定性以及高頻率部署是一致的,這使其在Netflix、Amazon 以及eBay 等世界領(lǐng)先的互聯(lián)網(wǎng)公司中率先流行起來.
然而,微服務(wù)的這些優(yōu)勢并不是一蹴而就的.微服務(wù)劃分是微服務(wù)領(lǐng)域的一項難題.其原因主要來自于以下4 個方面:第一,項目設(shè)計的初級階段可以為解決微服務(wù)劃分問題做決策提供支撐的信息過少;第二,微服務(wù)的劃分不僅與系統(tǒng)的領(lǐng)域知識相關(guān),還需要綜合考慮開發(fā)團(tuán)隊的組織結(jié)構(gòu)、項目的可用資源以及系統(tǒng)的非功能性需求等多個因素;第三,微服務(wù)劃分問題本身就是一個極富挑戰(zhàn)性的多目標(biāo)優(yōu)化問題.合理的微服務(wù)劃分要求設(shè)計者在多個相互排斥的性質(zhì)之間權(quán)衡利弊[4].比如,微服務(wù)提倡小而自治的服務(wù)之間相互合作[2].小而自治的服務(wù)符合單一職責(zé)原則(簡稱SRP),簡化了開發(fā)過程,但同時由于更多的服務(wù)需要部署也增加了運(yùn)維人員的壓力[5].從內(nèi)聚與耦合的角度看,粒度越小的服務(wù)具有越高的內(nèi)聚性,然而粒度越小的服務(wù)要實現(xiàn)同一個用例必然涉及更頻繁的服務(wù)間的通信交互,這使得服務(wù)間的耦合性提高,系統(tǒng)的復(fù)雜性更大;第四,微服務(wù)領(lǐng)域仍缺少針對服務(wù)設(shè)計本身的質(zhì)量評估方法.發(fā)展成熟的面向?qū)ο箢I(lǐng)域有許多評估面向?qū)ο笤O(shè)計的有效方法.然而,這些方法通常聚焦于代碼實現(xiàn)層的概念(比如類),與面向服務(wù)的微服務(wù)架構(gòu)的關(guān)注點(diǎn)不同.另外,在代碼實現(xiàn)后才評估微服務(wù)劃分的粒度所需要的系統(tǒng)重構(gòu)代價實在太大.因此,將評估面向?qū)ο笤O(shè)計的方法直接應(yīng)用于微服務(wù)架構(gòu)中不具備合理性.在很大程度上,架構(gòu)師對微服務(wù)劃分的合理性評估仍然依賴于他們對領(lǐng)域知識的理解和直覺[4].
針對上述問題,本文旨在利用限界上下文(bounded context)理論[6]對微服務(wù)架構(gòu)的服務(wù)劃分粒度進(jìn)行研究,為微服務(wù)劃分粒度的質(zhì)量評估問題提供理論方法及工具支持,幫助實現(xiàn)傳統(tǒng)單體應(yīng)用向微服務(wù)架構(gòu)的遷移.本文的主要貢獻(xiàn)在于提出的微服務(wù)粒度評估模型及其工具可用于指導(dǎo)微服務(wù)架構(gòu)中合理的服務(wù)劃分[7],輔助架構(gòu)師做出微服務(wù)設(shè)計決策,一方面可以降低不合理的微服務(wù)設(shè)計所造成的軟件開發(fā)與部署難度;另一方面可以提高團(tuán)隊開發(fā)效率和系統(tǒng)性能,提升軟件企業(yè)的競爭力.
本文第1 節(jié)介紹背景及相關(guān)工作.第2 節(jié)提出評估方法.第3 節(jié)給出4 種評估指標(biāo)及指標(biāo)合并過程.第4 節(jié)實現(xiàn)自動化工具原型,并利用案例研究驗證模型的有效性.第5 節(jié)總結(jié)論文,并提出下一步的工作.
合理的微服務(wù)劃分是微服務(wù)架構(gòu)敏捷、靈活和可擴(kuò)展性的先決條件,也是微服務(wù)領(lǐng)域所面臨的一項嚴(yán)峻挑戰(zhàn).過去的幾年里,一些研究人員致力于探究微服務(wù)劃分問題.Richardson[8]提出了用于指導(dǎo)微服務(wù)劃分的4 個策略,包括根據(jù)業(yè)務(wù)能力(business capability)進(jìn)行劃分、基于領(lǐng)域驅(qū)動設(shè)計中子領(lǐng)域(subdomain)的概念進(jìn)行劃分、利用動詞和用例圖進(jìn)行劃分以及利用名詞和資源定義服務(wù)等.Richardson[8]提出的指導(dǎo)微服務(wù)劃分的4 個策略并沒有為微服務(wù)劃分問題提供系統(tǒng)化的指導(dǎo)方法,具體的微服務(wù)劃分過程仍然依賴于系統(tǒng)架構(gòu)人員對領(lǐng)域業(yè)務(wù)需求的理解和主觀經(jīng)驗判斷.Gysel 等人[9]開發(fā)了微服務(wù)劃分工具Service Cutter.他們根據(jù)軟件架構(gòu)設(shè)計的經(jīng)驗定義了16 種耦合度度量標(biāo)準(zhǔn),用以衡量系統(tǒng)中的nanoentities(包括數(shù)據(jù)、操作和軟件制品)之間的耦合度,從而提取出以nanoentities 為節(jié)點(diǎn)的系統(tǒng)無向加權(quán)圖,在此基礎(chǔ)上實施聚類算法,實現(xiàn)微服務(wù)的劃分.Service Cutter存在兩個方面的問題,其一,系統(tǒng)架構(gòu)人員需要學(xué)習(xí)16 種耦合度度量標(biāo)準(zhǔn)的定義,并且結(jié)合系統(tǒng)的領(lǐng)域業(yè)務(wù)需求規(guī)定耦合度度量標(biāo)準(zhǔn)的優(yōu)先級,這極大地依賴于系統(tǒng)架構(gòu)人員的主觀經(jīng)驗;其二,由Service Cutter 計算得到的候選微服務(wù)準(zhǔn)確度較低,系統(tǒng)架構(gòu)人員仍需結(jié)合自己的預(yù)期劃分決定是否采納Service Cutter 提供的劃分方案.Baresi 等人[10]以符合OpenAPI 規(guī)范的系統(tǒng)API 為輸入,使用DISCO 相似度評估算法計算API 操作之間的相似度,將相似度高的操作及其數(shù)據(jù)劃分到同一服務(wù),從而實現(xiàn)微服務(wù)的劃分.該方法同樣存在兩個方面的問題,其一,該方法以系統(tǒng)API 中操作之間的相關(guān)性而不是領(lǐng)域業(yè)務(wù)邏輯層面的業(yè)務(wù)需求作為劃分依據(jù),操作的具體實現(xiàn)對最終劃分結(jié)果的影響較大;其二,該方法以實現(xiàn)層面的API 為輸入,適用于單體應(yīng)用到微服務(wù)應(yīng)用的遷移,而不適用于全新的微服務(wù)應(yīng)用的開發(fā).Chen 等人[11]將系統(tǒng)的領(lǐng)域業(yè)務(wù)邏輯繪制成數(shù)據(jù)流圖,將所有具有相同輸出數(shù)據(jù)的操作合并為一個操作,最終得到的每個操作及其數(shù)據(jù)都成為一個候選微服務(wù).該方法僅考慮了處理相同數(shù)據(jù)的操作應(yīng)屬于同一服務(wù),而忽略了微服務(wù)劃分的其他重要原則,可能存在微服務(wù)粒度過大的缺陷.顯然,微服務(wù)劃分問題仍缺少系統(tǒng)可行的理論指導(dǎo)方法.
更重要的是,當(dāng)前的研究對于“什么樣的微服務(wù)劃分是合理的”這一問題還缺乏標(biāo)準(zhǔn)而統(tǒng)一的認(rèn)識.缺乏微服務(wù)劃分合理性的評估標(biāo)準(zhǔn)使得比較不同微服務(wù)劃分方案變得困難.Baresi 等人[10]與Chen 等人[11]在將其工作與Service Cutter 進(jìn)行比較時,都僅討論了兩種方法在實現(xiàn)層面的復(fù)雜程度,而未提及微服務(wù)劃分結(jié)果之間的優(yōu)劣對比情況.在評估微服務(wù)劃分問題上,Newman[2]指出,微服務(wù)劃分的核心原則是高內(nèi)聚與低耦合.高內(nèi)聚將相關(guān)聯(lián)的業(yè)務(wù)邏輯包含在同一個服務(wù)中,便于代碼管理;低耦合降低了服務(wù)間的依賴與通信開銷,允許服務(wù)的獨(dú)立修改和部署.Newman[2]給出的評估微服務(wù)劃分的討論屬于定性分析,存在含糊不清的情況.Zdun 等人[12]基于微服務(wù)架構(gòu)的實踐模式設(shè)計了幾種評估微服務(wù)劃分的標(biāo)準(zhǔn),并定義了相關(guān)算法,定量地計算當(dāng)前微服務(wù)劃分遵循該實踐模式的程度.設(shè)計的評估標(biāo)準(zhǔn)包括“所有組件是否都可獨(dú)立部署或者所有組件可獨(dú)立部署的程度”以及“當(dāng)前微服務(wù)劃分方案是否避免了共享其他組件或者避免了以緊耦合的方式共享其他組件”.該微服務(wù)劃分的評估方法僅衡量了當(dāng)前微服務(wù)劃分是否符合微服務(wù)架構(gòu)的實踐模式,而未考慮系統(tǒng)的具體領(lǐng)域業(yè)務(wù)邏輯以及當(dāng)前微服務(wù)劃分下系統(tǒng)的內(nèi)聚性等其他方面的問題.
限界上下文是領(lǐng)域驅(qū)動設(shè)計(domain-driven design,簡稱DDD)[6]的核心概念.在應(yīng)對高復(fù)雜度的軟件開發(fā)任務(wù)時,DDD 提倡將應(yīng)用按照領(lǐng)域業(yè)務(wù)邏輯劃分為多個限界上下文,不同上下文使用獨(dú)立的模型,并且顯式地定義每個限界上下文的邊界和限界上下文之間的映射關(guān)系.限界上下文與微服務(wù)是天然契合的.其關(guān)注點(diǎn)分離的思想有助于系統(tǒng)架構(gòu)人員從每個服務(wù)內(nèi)部和服務(wù)之間兩個角度設(shè)計架構(gòu).從限界上下文視角討論微服務(wù)粒度能夠幫助我們分離出問題的核心點(diǎn).
本文基于限界上下文理論提出了一種微服務(wù)劃分的評估模型,具有以下優(yōu)點(diǎn):(1)以用例圖和實體關(guān)系圖為輸入,充分考慮了系統(tǒng)的領(lǐng)域業(yè)務(wù)邏輯;(2)設(shè)計了 4 種評估指標(biāo),定量地衡量微服務(wù)劃分在各項指標(biāo)上的表現(xiàn);(3)設(shè)計的4 種評估指標(biāo)都結(jié)合了微服務(wù)劃分的核心原則,包括高內(nèi)聚與低耦合;(4)進(jìn)行了指標(biāo)合并,提供綜合評分,用以比較不同微服務(wù)劃分方案;(5)實現(xiàn)了工具原型,可以自動化地評估微服務(wù)劃分;(6)提出的評估模型不涉及微服務(wù)應(yīng)用的具體實現(xiàn),既適用于單體應(yīng)用向微服務(wù)應(yīng)用的遷移,又適用于全新的微服務(wù)應(yīng)用的開發(fā).
本節(jié)為解決微服務(wù)粒度界定問題提出一種基于限界上下文的量化評估方法,并給出具體的評估步驟.
以評估微服務(wù)劃分為目的,基于UML 2.0[13]對微服務(wù)設(shè)計初級階段的關(guān)鍵元素建模以便于闡述后文.建模結(jié)果如圖1 所示.
基于限界上下文劃分微服務(wù)將一個獨(dú)立的應(yīng)用程序劃分為多個協(xié)同工作的小而自治的服務(wù),每個服務(wù)對應(yīng)一個特定的限界上下文,規(guī)定了一組領(lǐng)域業(yè)務(wù)邏輯和相應(yīng)的領(lǐng)域?qū)嶓w.服務(wù)通過完成用例實現(xiàn)應(yīng)用的領(lǐng)域業(yè)務(wù)邏輯,即軟件系統(tǒng)的功能需求.一個服務(wù)允許實現(xiàn)多個用例,一個用例允許由多個服務(wù)通過消息交互實現(xiàn).屬性描述了實體的特征,是實體的組成元素,也是微服務(wù)劃分中不可再分的原子單元.一個用例涉及到的屬性可以分為輸入和輸出兩部分,分別由對應(yīng)服務(wù)的讀操作和寫操作完成[8].實體與關(guān)聯(lián)關(guān)系之間的對應(yīng)關(guān)系與傳統(tǒng)ER模型一致.
Fig.1 Modeling of key elements in microservices decomposition圖1 微服務(wù)設(shè)計中關(guān)鍵元素的建模
在評估微服務(wù)粒度的工作中,服務(wù)模型的表現(xiàn)形式包括軟件制品(Artifact,包括用例圖和實體關(guān)系圖等)和候選微服務(wù).
(1)用例圖描述了軟件系統(tǒng)的功能需求.每個用例對應(yīng)于軟件系統(tǒng)的一項業(yè)務(wù)邏輯,完成一個用例有時需要多個服務(wù)之間的協(xié)同合作.Richardson[8]指出,用例可以作為微服務(wù)劃分的依據(jù).
(2)實體關(guān)系圖與自然語言相對應(yīng),描述了軟件系統(tǒng)中關(guān)鍵的領(lǐng)域?qū)嶓w及實體與實體之間的關(guān)系,可用于指導(dǎo)微服務(wù)的拆分.關(guān)聯(lián)關(guān)系緊密的領(lǐng)域?qū)嶓w傾向于劃分到同一個服務(wù)中.
(3)候選微服務(wù)描述了微服務(wù)劃分中服務(wù)與用例、實體之間的對應(yīng)關(guān)系,規(guī)定了每個服務(wù)負(fù)責(zé)的領(lǐng)域業(yè)務(wù)邏輯和相關(guān)限界上下文.本文通過評估候選微服務(wù)在各量化指標(biāo)上的表現(xiàn)來評估微服務(wù)劃分的合理性.
本文提出的微服務(wù)粒度的評估過程可以分為4 個步驟,如圖2 所示.
Fig.2 Evaluating the rationality of microservices decomposition圖2 評估微服務(wù)劃分合理性的過程
(1)輸入服務(wù)模型數(shù)據(jù):包括用例圖、實體關(guān)系和候選微服務(wù)3 種表現(xiàn)形式.
(2)指標(biāo)計算:以服務(wù)模型數(shù)據(jù)作為輸入,定量地計算候選微服務(wù)在所有評估指標(biāo)上的值,衡量該微服務(wù)劃分在各項指標(biāo)上的表現(xiàn).
(3)指標(biāo)合并:對指標(biāo)計算的結(jié)果做歸一化處理與加權(quán)求和,得到該微服務(wù)劃分的綜合評分,用以比較不同的微服務(wù)劃分方案.
(4)評估模型是否可優(yōu)化:設(shè)計人員根據(jù)指標(biāo)計算及合并過程得到的結(jié)果對微服務(wù)劃分進(jìn)行分析,判斷能否重新調(diào)整劃分以獲得更優(yōu)的微服務(wù)粒度.
容易看出,微服務(wù)粒度的評估是一個向更優(yōu)劃分靠近的不斷迭代的過程.架構(gòu)設(shè)計人員應(yīng)選擇評估過程得到的最優(yōu)劃分方案作為最終的微服務(wù)劃分結(jié)果.
本節(jié)根據(jù)業(yè)界廣泛采用的微服務(wù)劃分原則[2,8]定義一系列評估指標(biāo),用于衡量微服務(wù)劃分,指出各項指標(biāo)的有效性,并給出具體的指標(biāo)計算公式.
服務(wù)內(nèi)聚性是指服務(wù)內(nèi)用例之間的功能相關(guān)性[14].服務(wù)的內(nèi)聚性越高,設(shè)計模型的可理解性越強(qiáng),系統(tǒng)也就越敏捷[14].
3.1.1 指標(biāo)有效性分析
內(nèi)聚性是軟件系統(tǒng)中的主要屬性,也是微服務(wù)設(shè)計質(zhì)量評估的重要因素.服務(wù)的內(nèi)聚性越低,一方面意味著該服務(wù)存在越多功能邏輯不相關(guān)的代碼,其他服務(wù)對該服務(wù)存在越多的依賴,該服務(wù)越難以獨(dú)立修改;另一方面意味著不同服務(wù)中存在越多功能邏輯相關(guān)的代碼,代碼的冗余度越大.與此同時,系統(tǒng)的技術(shù)可選性越小[2].另外,高內(nèi)聚性的服務(wù)由于實現(xiàn)了功能邏輯緊密相關(guān)的用例,因而具有更清晰的限界上下文,可理解性更強(qiáng).當(dāng)系統(tǒng)的微服務(wù)劃分與開發(fā)團(tuán)隊的組織結(jié)構(gòu)一致時,具有高內(nèi)聚性的微服務(wù)開發(fā)速度更快.并且,由于服務(wù)的內(nèi)聚性減少了微服務(wù)內(nèi)部組件間的消息交互,因此具有更高的系統(tǒng)效率[15].
正確定義服務(wù)邊界、分析系統(tǒng)語義是提高服務(wù)內(nèi)聚性的前提[15].Newman[2]指出,高內(nèi)聚是微服務(wù)領(lǐng)域的重要概念,是指將邏輯相關(guān)的代碼盡可能地放在相同服務(wù)中.通過領(lǐng)域驅(qū)動設(shè)計中的限界上下文劃分微服務(wù)邊界,每個服務(wù)聚焦于一個具體的業(yè)務(wù)邏輯,可以避免服務(wù)粒度過大,實現(xiàn)高內(nèi)聚從而實現(xiàn)微服務(wù)優(yōu)勢的最大化.
3.1.2 計算方法
服務(wù)的內(nèi)聚性可通過服務(wù)內(nèi)部的實體間內(nèi)聚性來度量.現(xiàn)有的許多研究[16-18]通過為ER 模型中的關(guān)聯(lián)關(guān)系信息定義優(yōu)先級來衡量實體間的內(nèi)聚性,涉及到的關(guān)聯(lián)關(guān)系信息包括類型、基數(shù)(cardinality ratios)和參與約束(participation)等.文獻(xiàn)[18]使用距離的概念度量實體間的內(nèi)聚性,并為不同優(yōu)先級別的實體間內(nèi)聚性設(shè)置了不同的距離值,距離的值越大,實體間的內(nèi)聚性越小.文獻(xiàn)[17]指出,強(qiáng)實體與弱實體(strong-weak)之間的內(nèi)聚性最高,擁有第1 優(yōu)先級.擁有內(nèi)聚性第2 優(yōu)先級的是具有特殊化/概化(generalization)關(guān)系的超類和子類.另外,聚合(aggregation)關(guān)聯(lián)關(guān)系由于具有部分與整體生存周期上的聯(lián)系,同樣屬于第2 優(yōu)先級隊列.具有限制(exclusive binary)關(guān)聯(lián)關(guān)系的實體間內(nèi)聚性較低,擁有第3 優(yōu)先級[18].具體的實體間關(guān)聯(lián)關(guān)系類別與距離值的對應(yīng)見表1.
Table 1 Correspondences between relationship of entities and distances in ER diagrams表1 ER 圖中實體間關(guān)聯(lián)關(guān)系類別與距離值的對應(yīng)
對于ER 模型中的其他關(guān)聯(lián)關(guān)系類別,我們根據(jù)基數(shù)與參與約束信息定義不同的優(yōu)先級,以表現(xiàn)實體間不同程度的內(nèi)聚性特征.針對關(guān)聯(lián)關(guān)系的基數(shù),不同基數(shù)的關(guān)聯(lián)關(guān)系對應(yīng)的實體內(nèi)聚性特征如下:一對一>一對多>多對多.針對關(guān)聯(lián)關(guān)系的參與約束,不難理解,強(qiáng)制性(mandatory)參與的關(guān)聯(lián)關(guān)系比可選(optional)參與的關(guān)聯(lián)關(guān)系具有更強(qiáng)的內(nèi)聚性,因此,不同參與約束的關(guān)聯(lián)關(guān)系對應(yīng)的實體間內(nèi)聚性特征如下:強(qiáng)制-強(qiáng)制(M-M)>強(qiáng)制-可選(M-O)>可選-可選(O-O).據(jù)此,Mohammad[14]列出了表2.
Table 2 Correspondences between cardinality and participation of relationship and distances in ER diagrams[14]表2 ER 圖中一般關(guān)聯(lián)關(guān)系的基數(shù)與參與約束信息對應(yīng)的距離值[14]
在計算三元及其他n(n>2)元關(guān)聯(lián)關(guān)系時,我們將表2 數(shù)據(jù)乘以10n-2得到對應(yīng)的距離值.表1 和表2 中距離值的數(shù)值選擇只反映了ER 模型中不同關(guān)聯(lián)關(guān)系對應(yīng)的實體內(nèi)聚性的強(qiáng)弱,與具體數(shù)值多少無關(guān).比如,1 和10的差距使得具有M-M 參與約束的兩個實體比具有M-O 參與約束的兩個實體內(nèi)聚性更強(qiáng).最后,出于完整性考慮,規(guī)定兩個相同實體之間的距離值為1.
那么,任意實體E1和E2之間的距離值可以表示為ER 圖中兩個實體之間所有路徑上的邊的距離值之和的最小值,即最短路徑的長度,如式(1)所示.
其中,p表示ER 圖中實體E1和E2之間的路徑數(shù),ep表示當(dāng)前路徑的邊數(shù),di表示邊的距離值.實體E1和E2的內(nèi)聚性如式(2)所示.
由式(1)得到任意ER 圖對應(yīng)的ER 模型中所有實體之間的距離值,文獻(xiàn)[14]稱其為距離表(distance table).接下來,利用ER 模型中實體之間的距離值來度量服務(wù)內(nèi)聚性.根據(jù)第1 節(jié)提出的服務(wù)模型,一個服務(wù)允許實現(xiàn)多個用例.一個服務(wù)實現(xiàn)的用例越多,該服務(wù)的內(nèi)聚性就越低[2].對于服務(wù)內(nèi)的任意兩個用例1 和2,我們得到對一個實體集(BE1,BE2)以及所有的1 中實體與2 中實體之間的距離值(由距離表可得),從而構(gòu)建二分圖G(V,E),二分圖中每條邊E(i)的距離值用Weight(E(i))表示.使用貪心算法選出連接用例1 和用例2 中所有實體的距離值最小的邊的集合R可用于度量兩個用例間的內(nèi)聚性.具體算法如Algorithm 1 偽碼所示.
Algorithm 1.使用貪心算法選出符合條件的R.
輸入:BE1,BE2,距離表DistanceTable;
輸出:R:連接用例1 和用例2 中所有實體的距離值最小的邊的集合.
4:從G中選出具有最小距離值的邊e
5:ife不屬于邊集R且e不與R內(nèi)其他邊構(gòu)成環(huán)then
6:將e加入集合R
7:將e的端點(diǎn)加入集合S
8:end if
9:end while
根據(jù)得到的符合條件的邊集R,我們由式(3)計算用例之間的內(nèi)聚性UCC(use case cohesion).不難理解,式(3)的計算結(jié)果是邊集R的內(nèi)聚性平均值.
對應(yīng)的服務(wù)K的內(nèi)聚性SC(service cohesion)可以表示如下,其中,a表示第k個服務(wù)中的用例數(shù).
同時,得到微服務(wù)系統(tǒng)設(shè)計的服務(wù)內(nèi)聚性SDC(service design cohesion)如下,s表示系統(tǒng)中的所有服務(wù)數(shù):
服務(wù)耦合性描述了一個服務(wù)依賴于其他服務(wù)的程度,或者說一個服務(wù)的改變對其他服務(wù)的影響程度[15].
3.2.1 指標(biāo)有效性分析
微服務(wù)的特征之一是服務(wù)自治,允許服務(wù)獨(dú)立地修改和部署.這就要求減少服務(wù)之間的依賴,降低服務(wù)的耦合度.服務(wù)之間的低耦合可以帶來兩個好處.一方面,服務(wù)之間的通信交互越小,意味著系統(tǒng)具有更高的效率和更好的性能.另一方面,低耦合度意味著其他服務(wù)的修改對當(dāng)前服務(wù)的影響較小,系統(tǒng)具有更好的靈活性,能夠快速適應(yīng)需求的變化[2].低耦合是軟件工程中衡量系統(tǒng)設(shè)計的重要標(biāo)準(zhǔn).
依據(jù)限界上下文定義微服務(wù)邊界,正確實現(xiàn)微服務(wù)劃分可以保證實現(xiàn)服務(wù)間的松耦合[19].Martin[20]的單一職責(zé)原則——“Gather together the things that change for the same reasons.Separate those things that change for different reasons.”——同樣可以降低微服務(wù)劃分的耦合度.具體來說,將同一個用例涉及到的屬性劃分到同一個服務(wù),將具有緊密關(guān)聯(lián)關(guān)系的實體劃分到同一個服務(wù),減少服務(wù)之間的通信數(shù)量,消除不必要的服務(wù)之間的關(guān)聯(lián)和依賴[9].
3.2.2 計算方法
服務(wù)間的耦合度體現(xiàn)了服務(wù)間的相互依賴程度.若服務(wù)A訪問服務(wù)B的實體以實現(xiàn)其業(yè)務(wù)用例,則稱服務(wù)A依賴于服務(wù)B,服務(wù)A與B之間存在耦合.在微服務(wù)應(yīng)用中,服務(wù)之間通過輕量級消息機(jī)制實現(xiàn)交互.服務(wù)之間的消息交互越多,系統(tǒng)的通信開銷就越大,系統(tǒng)性能也就越差.因此,可以用服務(wù)間傳遞消息的大小,包括傳遞的屬性個數(shù)以及屬性的復(fù)雜度等,來度量服務(wù)間的耦合度[11].其中,屬性的復(fù)雜度由屬性本身的組成結(jié)構(gòu)決定.類級別的屬性具有比基本數(shù)據(jù)類型屬性更高的復(fù)雜度,集合類型的屬性也具有比基本數(shù)據(jù)類型屬性更高的復(fù)雜度.為此,定義兩種不同的屬性復(fù)雜度級別:類與集合(ClassOrList)復(fù)雜度為10,原子(primitive)級別復(fù)雜度為1,所有屬性的默認(rèn)復(fù)雜度為原子級別.另外,服務(wù)之間以不同的頻率傳遞消息體現(xiàn)的服務(wù)耦合程度是不同的.在項目設(shè)計階段,消息頻率表現(xiàn)為用例頻率(frequency of use).用例頻率屬于用例圖的內(nèi)容,根據(jù)業(yè)務(wù)邏輯預(yù)估該用例在系統(tǒng)運(yùn)行時單位時間內(nèi)的調(diào)用次數(shù)獲得.比如,修改用戶密碼等涉及到基礎(chǔ)配置的用例調(diào)用次數(shù)較少,頻率較低.我們定義3 種不同的用例頻率:低、中、高(分別對應(yīng)頻率值1、10、100),并設(shè)置默認(rèn)用例頻率為中.為屬性和用例頻率設(shè)置默認(rèn)值降低了設(shè)計人員使用該工具進(jìn)行服務(wù)粒度評估的輸入工作量.基于以上分析,用式(6)度量系統(tǒng)設(shè)計的服務(wù)耦合性.
其中,
ul表示服務(wù)l實現(xiàn)的用例總數(shù)(ul≥0);
flt表示服務(wù)l中的用例t的頻率(flt≥0);
rlt表示服務(wù)l中的用例t包含的在服務(wù)間讀屬性的總數(shù)(rlt≥0);
wlt表示服務(wù)l中的用例t包含的在服務(wù)間寫屬性的總數(shù)(wlt≥0);
cltm表示服務(wù)l中的用例t包含的在服務(wù)間讀屬性m的復(fù)雜度(cltm≥0);
cltn表示服務(wù)l中的用例t包含的在服務(wù)間寫屬性n的復(fù)雜度(cltn≥0).
用例收斂性指代單個服務(wù)聚焦于處理特定領(lǐng)域業(yè)務(wù)功能的程度.
3.3.1 指標(biāo)有效性分析
微服務(wù)劃分的原則之一是每個服務(wù)要足夠小.著名的面向?qū)ο笤O(shè)計原則——單一職責(zé)原則(SRP)——規(guī)定每個類/模塊都應(yīng)該有單一的功能,并且該功能應(yīng)由這個類/模塊完全封裝起來.SRP 對于面向服務(wù)的微服務(wù)設(shè)計同樣有效[8].服務(wù)實現(xiàn)的用例體現(xiàn)了該服務(wù)為軟件系統(tǒng)提供的業(yè)務(wù)功能.服務(wù)實現(xiàn)的用例越多,意味著微服務(wù)設(shè)計不符合SRP 的程度越大,系統(tǒng)可復(fù)用性和內(nèi)聚性就越低.
另一方面,實現(xiàn)單個用例涉及的服務(wù)越多,需要的服務(wù)之間的通信開銷就越大,系統(tǒng)延遲也就越高.不僅如此,這還需要越多的開發(fā)團(tuán)隊之間的合作,一定程度上提高了服務(wù)間耦合和開發(fā)團(tuán)隊間的依賴,降低了服務(wù)及其開發(fā)團(tuán)隊的自治性,應(yīng)盡量避免.
3.3.2 計算方法
基于第3.3.1 節(jié)中的分析,微服務(wù)設(shè)計中,(1)每個服務(wù)實現(xiàn)的用例應(yīng)盡可能地少;(2)實現(xiàn)單個用例涉及的服務(wù)應(yīng)盡可能地少.為了評估(1),計算微服務(wù)設(shè)計中服務(wù)實現(xiàn)的用例平均數(shù).為了評估(2),計算設(shè)計中實現(xiàn)每個用例涉及的服務(wù)平均數(shù).微服務(wù)劃分的用例收斂性用公式(7)表示如下:
其中,
s表示當(dāng)前微服務(wù)設(shè)計中的服務(wù)數(shù);
Uk表示服務(wù)k中對應(yīng)的用例數(shù);
u表示當(dāng)前微服務(wù)設(shè)計中的用例數(shù);
Sl表示實現(xiàn)用例l涉及的服務(wù)數(shù).
實體收斂性指代單個服務(wù)聚焦于處理特定領(lǐng)域?qū)嶓w的程度.
3.4.1 指標(biāo)有效性分析
微服務(wù)傾向于讓每個服務(wù)管理自己的數(shù)據(jù)庫[19],包括對領(lǐng)域?qū)嶓w數(shù)據(jù)的增加、刪除、更改和查詢.為滿足單一職責(zé)原則,降低服務(wù)的數(shù)據(jù)庫管理負(fù)載,單個服務(wù)管理的實體數(shù)應(yīng)盡可能地少.
另一方面,共同閉包原則(common closure principle,簡稱CCP)——“the packages should not have more than one reason to change.”——強(qiáng)調(diào)從變化的角度看待軟件架構(gòu)設(shè)計,可用于提高微服務(wù)設(shè)計的可維護(hù)性.具體來說,訪問同一實體的用例趨向于劃分到同一服務(wù).這樣,當(dāng)某一領(lǐng)域?qū)嶓w發(fā)生需求變更時,需要做出修改的服務(wù)應(yīng)盡可能地少,帶來的服務(wù)間耦合也應(yīng)盡可能地小.
3.4.2 計算方法
基于第3.4.1 節(jié)中的分析,微服務(wù)設(shè)計中,(1)每個服務(wù)管理的實體數(shù)據(jù)應(yīng)盡可能地少;(2)同一實體數(shù)據(jù)涉及的服務(wù)也應(yīng)盡可能地少.為了評估(1),計算微服務(wù)設(shè)計中服務(wù)管理的實體平均數(shù).為了評估(2),計算設(shè)計中實體涉及的服務(wù)平均數(shù).微服務(wù)劃分的實體收斂性用公式(8)表示如下:
其中,
s表示當(dāng)前微服務(wù)設(shè)計中的服務(wù)數(shù);
Ek表示服務(wù)k中管理的實體數(shù)據(jù)數(shù);
e表示當(dāng)前微服務(wù)設(shè)計中的實體數(shù);
Sl表示實體l涉及的服務(wù)數(shù).
合理的微服務(wù)劃分要求設(shè)計者在多個相互排斥的性質(zhì)之間權(quán)衡利弊[4].減少服務(wù)實現(xiàn)的用例數(shù)以降低微服務(wù)粒度,使微服務(wù)設(shè)計更符合單一職責(zé)原則.一方面,這不僅提高了服務(wù)內(nèi)聚性,同時還降低了對應(yīng)開發(fā)團(tuán)隊的工作強(qiáng)度.另一方面,這也帶來了更多的服務(wù)間數(shù)據(jù)流,增加了服務(wù)間的耦合與依賴.在劃分微服務(wù)時,需要更多數(shù)據(jù)交互的用例及其數(shù)據(jù)應(yīng)趨向于被劃分到同一個服務(wù)內(nèi).另外,當(dāng)微服務(wù)劃分具有良好的實體收斂性時,服務(wù)需要接收更多的服務(wù)間消息才能完成同一用例,服務(wù)間的耦合度較高.而當(dāng)微服務(wù)劃分具有較小的用例收斂性時,一方面要求服務(wù)包含較少的用例,另一方面要求用例涉及的輸入輸出屬性盡量包含在更少的服務(wù)中,這就與較小的實體收斂性目標(biāo),即要求每個服務(wù)包含的實體較少發(fā)生了沖突.根據(jù)上述分析,我們需要合并計算得到的所有指標(biāo)以得到對微服務(wù)劃分的綜合評分.假設(shè)當(dāng)前存在n個不同的微服務(wù)劃分,對每個劃分都能通過前文所述的公式得到4 個指標(biāo),從而得到指標(biāo)矩陣M,M的每一列分別對應(yīng)服務(wù)內(nèi)聚性、服務(wù)耦合性、實體收斂性和用例收斂性:
由于每種指標(biāo)表示的含義不同,其量綱和取值范圍也存在很大的差別,將不同指標(biāo)直接累加可能造成某一維指標(biāo)對結(jié)果影響過大.因此,為了更公平地合并不同的指標(biāo),我們需要對指標(biāo)計算結(jié)果進(jìn)行歸一化處理,使所有指標(biāo)數(shù)據(jù)的歸一化結(jié)果在[0,1]之間.另外,為了使加權(quán)結(jié)果越大與微服務(wù)設(shè)計越合理的目標(biāo)相統(tǒng)一,在歸一化過程中還應(yīng)考慮到指標(biāo)本身.根據(jù)前4 節(jié)的分析,更合理的微服務(wù)劃分具有更高的服務(wù)內(nèi)聚性、更低的服務(wù)耦合性、用例收斂性以及實體收斂性.
(1)對于劃分目標(biāo)為更高的指標(biāo)i,對mij作如下歸一化處理:
(2)對于劃分目標(biāo)為更低的指標(biāo)i,對mij作如下歸一化處理:
其中,mimax和mimin分別是指標(biāo)i在n個不同劃分結(jié)果下的最大值和最小值.
接下來,對歸一化處理后的指標(biāo)進(jìn)行加權(quán)以獲得綜合評分.顯然,不同的軟件系統(tǒng)對不同指標(biāo)的優(yōu)先級要求不同.比如,對于具有更高性能要求的軟件系統(tǒng),耦合性對系統(tǒng)設(shè)計非常關(guān)鍵,服務(wù)耦合性指標(biāo)應(yīng)具有更高的權(quán)重.相反地,更強(qiáng)調(diào)可復(fù)用性的軟件系統(tǒng)應(yīng)增加服務(wù)內(nèi)聚性和實體收斂性在評估微服務(wù)劃分工作中的權(quán)重.假設(shè)各指標(biāo)的權(quán)重向量為W={w1,w2,w3,w4},那么候選微服務(wù)k的綜合評分為
為了驗證提出的微服務(wù)劃分的評估模型,我們實現(xiàn)了service candidates evaluating(SCE)工具原型,自動化地計算候選微服務(wù)于服務(wù)內(nèi)聚性、服務(wù)耦合性、用例收斂性和實體收斂性4 個方面的指標(biāo),并給出綜合評分,以比較不同微服務(wù)劃分的優(yōu)劣.SCE 的實現(xiàn)基于Python 2.7.13 與Gui 編程技術(shù)PyQt5.圖3 描述了該SCE 的圖形化用戶接口,主要包括以下幾個方面:軟件制品與候選微服務(wù)的輸入,指標(biāo)優(yōu)先級的輸入,當(dāng)前候選微服務(wù)的評估結(jié)果輸出以及歷史評估結(jié)果的排行輸出.SCE 規(guī)定軟件制品與候選微服務(wù)的輸入應(yīng)嚴(yán)格遵循特定格式的JSON 文件形式.
Fig.3 Interface of the SCE system prototype圖3 SCE 系統(tǒng)界面
本節(jié)將評估模型應(yīng)用于領(lǐng)域驅(qū)動設(shè)計中的經(jīng)典場景——貨物跟蹤系統(tǒng)(cargo tracking system,簡稱CTS)——以闡述評估模型的具體使用過程,并驗證模型的有效性.利用評估模型對CTS 案例下的幾種微服務(wù)劃分方案進(jìn)行評估,若評估結(jié)果排序與微服務(wù)架構(gòu)設(shè)計人員的預(yù)期相符,則認(rèn)為評估模型有效.
4.2.1 業(yè)務(wù)場景
CTS 是Evans[6]用于闡述領(lǐng)域驅(qū)動設(shè)計的經(jīng)典案例,(1)具有合適的問題復(fù)雜度;(2)具有完整且合理的架構(gòu)分析;(3)具有公認(rèn)合理的限界上下文劃分方案;(4)GitHub 上具有已實現(xiàn)的完整代碼:DDDSample.對DDDSample 進(jìn)行逆向分析,不難得到CTS 的業(yè)務(wù)需求如下.
(1)將Cargo 從Location A 運(yùn)送到Location B.每個Cargo 創(chuàng)建時都伴隨著一個TrackingId,Cargo 的具體說明用類RouteSpecification 來實現(xiàn).一旦Cargo 被創(chuàng)建,一到多個Itinerary 將分配給該Cargo;
(2)系統(tǒng)通過計算現(xiàn)有的Voyage 給Cargo 分配合適的Itinerary,每個Voyage 都包含一系列的Carrier Movement;
(3)在Cargo 的路線確定以后,HandlingEvent 跟蹤C(jī)argo 的每個Itinerary,完成貨物跟蹤;
(4)Cargo 的Delivery 實例描述了具體的運(yùn)輸狀態(tài)、預(yù)計到達(dá)時間以及該Cargo 當(dāng)前是否被跟蹤.
進(jìn)一步分析后可得到CTS 的用例圖和實體關(guān)系圖.同時,得到CTS 的業(yè)務(wù)用例和領(lǐng)域?qū)嶓w如下.
(1)業(yè)務(wù)用例:View Tracking,View Cargo,Book Cargo,Change Cargo Destination,Route Cargo,Create Location,Create Voyage,Add Carrier Movement,Handle Cargo Event.
下文使用的縮寫形式為VT,VC,BC,CCD,RC,CL,ACM,HC.
(2)領(lǐng)域?qū)嶓w:Cargo,HandlingEvent,Delivery,Voyage,RouteSpecification,Location,Itinerary,CarrierMovement,Leg.
下文使用的縮寫形式為Car,HE,Del,Voy,RS,Loc,Iti,CM,Leg.
表3 給出CTS 系統(tǒng)中業(yè)務(wù)用例與領(lǐng)域?qū)嶓w之間的對應(yīng).
Table 3 Use cases of CTS表3 CTS 的業(yè)務(wù)用例及其領(lǐng)域?qū)嶓w
4.2.2 模型驗證
接下來,通過驗證CTS 案例下5 個候選微服務(wù)在評估模型中的表現(xiàn)來驗證提出的微服務(wù)劃分評估模型的有效性.5 個候選微服務(wù)的具體細(xì)節(jié)見表4.
Table 4 Microservices candidates of CTS application表4 CTS 應(yīng)用程序中的候選微服務(wù)
候選微服務(wù)SC0 到候選微服務(wù)SC3 在設(shè)計時僅考慮評估模型的一項指標(biāo).在候選微服務(wù)SC0 中,每個服務(wù)僅負(fù)責(zé)一個用例的開發(fā)與實現(xiàn),服務(wù)的內(nèi)聚性最大.在候選微服務(wù)SC1 中,服務(wù)S10 將系統(tǒng)中所有業(yè)務(wù)用例與領(lǐng)域?qū)嶓w都組合在一起,實現(xiàn)任意用例都只需訪問本地領(lǐng)域?qū)嶓w,無服務(wù)間消息交互,具有最小的服務(wù)耦合性.候選微服務(wù)SC2 從用例收斂性的角度出發(fā),在保證服務(wù)實現(xiàn)的用例平均數(shù)較小的前提下,盡可能地將實現(xiàn)同一業(yè)務(wù)用例涉及到的領(lǐng)域?qū)嶓w劃分到相同服務(wù).比如,實現(xiàn)業(yè)務(wù)用例ViewTracking 涉及到的領(lǐng)域?qū)嶓w有Cargo、HandlingEvent、Delivery、Voyage 和RouteSpecification,若將這5 個領(lǐng)域?qū)嶓w(CTS 共有9 個領(lǐng)域?qū)嶓w)都劃分到同一服務(wù),則違背服務(wù)實現(xiàn)的用例平均數(shù)較小的原則.注意到,領(lǐng)域?qū)嶓wCargo 和RouteSpecification 在業(yè)務(wù)用例ViewTracking、ViewCargo、BookCargo、ChangeCargoDestination 以及RouteCargo 中均有涉及,因此,將領(lǐng)域?qū)嶓wCargo 和RouteSpecification 劃分到一個服務(wù)中.候選微服務(wù)SC3 中,在保證服務(wù)管理的實體平均數(shù)較小的前提下,盡可能地將處理相同領(lǐng)域?qū)嶓w的業(yè)務(wù)用例劃分到同一服務(wù),劃分方式與SC2 同理.SC4 對領(lǐng)域?qū)嶓w的劃分與領(lǐng)域驅(qū)動設(shè)計對CTS 的劃分一致.在領(lǐng)域驅(qū)動設(shè)計中,Evans 根據(jù)限界上下文方法將CTS 劃分為4 個服務(wù):(1)Voyage 服務(wù)負(fù)責(zé)所有航運(yùn)的信息管理,包含領(lǐng)域?qū)嶓wVoyage 和CarrierMovement;(2)系統(tǒng)中的地點(diǎn)數(shù)據(jù)具有“多讀少寫”的業(yè)務(wù)特點(diǎn),由Location 服務(wù)負(fù)責(zé)管理,包含領(lǐng)域?qū)嶓wLocation;(3)Planning 服務(wù)負(fù)責(zé)管理系統(tǒng)中所有的貨物及其航段信息,包含領(lǐng)域?qū)嶓wCargo,RouteSpecification,Itinerary 和Leg;(4)Tracking 服務(wù)用于跟蹤貨物的具體事件,包含領(lǐng)域?qū)嶓wHandlingEvent.SC4 實現(xiàn)了在4 個指標(biāo)之間的權(quán)衡.
由于SC4 是公認(rèn)合理的限界上下文劃分方案,而SC0 到SC3 都僅考慮了4 個評估指標(biāo)中的一項,因此,預(yù)計在評估模型給出的評估結(jié)果中候選微服務(wù)4 即SC4 應(yīng)具有最好的綜合評分.
在運(yùn)行SCE 進(jìn)行微服務(wù)劃分評估時,根據(jù)CTS 的項目需求指定4 個指標(biāo)的優(yōu)先級參數(shù)為[0.25,0.25,0.25,0.25].運(yùn)行SCE,對5 個候選微服務(wù)分別計算其指標(biāo),得到如下指標(biāo)矩陣M(M的每一行對應(yīng)SC0~SC4):
對指標(biāo)計算結(jié)果進(jìn)行歸一化處理得到矩陣M′如下.分析矩陣M′后發(fā)現(xiàn),候選微服務(wù)SC0 具有最大的服務(wù)內(nèi)聚性,SC1 具有最小的服務(wù)耦合性,SC2 具有較小的用例收斂性,SC3 具有最小的實體收斂性,與此前的服務(wù)設(shè)計的分析相一致.
之后,再按照優(yōu)先級參數(shù)對M′做加權(quán)求和后,得到5 個候選微服務(wù)的綜合指標(biāo)為[0.663,0.254,0.733,0.806,0.831].候選微服務(wù)SC4 由于權(quán)衡了微服務(wù)劃分的多個方面,具有最好的綜合指標(biāo)結(jié)果.綜合指標(biāo)的計算結(jié)果與預(yù)想一致,一定程度上說明了評估模型的有效性.
4.2.3 與Service Cutter 對比
由于微服務(wù)領(lǐng)域缺少評估微服務(wù)劃分的系統(tǒng)化工作,我們選擇劃分微服務(wù)的工具原型Service Cutter,使用本評估模型對CTS 在Service Cutter 中的幾種劃分結(jié)果進(jìn)行評估,將評估結(jié)果與Service Cutter 的人為評估結(jié)果進(jìn)行比較.
Service Cutter 的微服務(wù)劃分過程包括 4 個步驟:系統(tǒng)定義(system definition)、系統(tǒng)說明(system specification)、服務(wù)劃分(service decomposition)和分析服務(wù)劃分結(jié)果(analyze service cuts).在利用CTS 進(jìn)行微服務(wù)劃分的模型驗證時,Gysel 等人[9]同樣通過對DDDSample 的逆向分析得到相關(guān)用戶描述(user representation),并以此作為系統(tǒng)定義和系統(tǒng)說明步驟的輸入,得到的用戶描述包括用例圖、實體關(guān)系圖、nanoentities 的內(nèi)容易變性和結(jié)構(gòu)易變性特征等.Service Cutter 通過逆向分析得到的用例圖和實體關(guān)系圖與第4.2.1 節(jié)中的基本一致.除用例圖和實體關(guān)系圖外,Service Cutter 分析DDDSample 得到的部分用戶描述列舉見表5.Service Cutter 對Location 的內(nèi)容易變性與結(jié)構(gòu)易變性的定義與本文第4.2.2 節(jié)的討論相一致.在服務(wù)劃分步驟中,Gysel等人還根據(jù)CTS 的需求特性對16 種耦合度度量標(biāo)準(zhǔn)的優(yōu)先級進(jìn)行了調(diào)整,以使微服務(wù)劃分結(jié)果更接近預(yù)期結(jié)果.
Table 5 Part of user representations of CTS application in Service Cutter表5 Service Cutter 得到的CTS 部分用戶描述
以用戶描述和調(diào)整后的耦合度度量標(biāo)準(zhǔn)的優(yōu)先級作為輸入,Service Cutter 在劃分CTS 系統(tǒng)時調(diào)整聚類算法得到了兩種劃分方案,具體細(xì)節(jié)見表6.
Table 6 Microservices candidates of CTS application in Service Cutter表6 Service Cutter 對CTS 應(yīng)用程序劃分得到的候選微服務(wù)
Service Cutter 對劃分結(jié)果的討論認(rèn)為,CUT0 將領(lǐng)域?qū)嶓wLocation 劃分到兩個服務(wù),并且依據(jù)劃分結(jié)果與預(yù)期結(jié)果的一致程度判定CUT0 為“壞”劃分,CUT1 為“可接受”的劃分.運(yùn)行SCE 得到本評估模型對兩種劃分方案的評估結(jié)果見表7.
Table 7 Evaluation of two decompositions in Service Cutter by SCE表7 SCE 對Service Cutter 兩種劃分方案的評估結(jié)果
SCE 的運(yùn)行結(jié)果顯示,微服務(wù)CUT0 具有更高的綜合評分,與Service Cutter 的人為評估結(jié)果不一致.盡管候選微服務(wù)CUT1 的服務(wù)耦合性更小,但是由于CUT1 中只有3 個服務(wù),每個服務(wù)實現(xiàn)的業(yè)務(wù)用例和管理的領(lǐng)域?qū)嶓w更多,因此,用例收斂性和實體收斂性都更大.并且,對比候選微服務(wù)CUT0 和CUT1 的具體劃分,CUT0 將業(yè)務(wù)用例AddCarrierMovement 劃分出來,成為一個服務(wù),使服務(wù)S00 更符合SRP 原則,提高了劃分的服務(wù)內(nèi)聚性.從服務(wù)內(nèi)聚性、服務(wù)耦合性、用例收斂性和實體收斂性4 個方面綜合考慮,CUT0 對應(yīng)的微服務(wù)劃分更合理.與本模型相比,Service Cutter 對劃分結(jié)果的人為評估具有更強(qiáng)的主觀性.
微服務(wù)和DevOps 在縮短交付周期、提高團(tuán)隊自治性等特性方面是相輔相成的.然而,合理的微服務(wù)粒度是微服務(wù)一切特性的前提,也是微服務(wù)領(lǐng)域的一項難題.本文從限界上下文視角提出一種微服務(wù)劃分粒度的評估模型.首先,針對微服務(wù)劃分問題給出完整的評估過程;然后,結(jié)合微服務(wù)劃分的核心原則包括高內(nèi)聚、低耦合等設(shè)計4 項評估指標(biāo)以量化評估過程;其次,引入指標(biāo)合并得到微服務(wù)劃分的綜合評分以比較不同微服務(wù)劃分方案;再次,實現(xiàn)工具原型SCE 自動化地評估微服務(wù)劃分;最后,比較評估結(jié)果與架構(gòu)師心理預(yù)期驗證模型的有效性.
目前,該方法仍存在如下待改進(jìn)的問題:首先,評估模型僅考慮了微服務(wù)劃分的4 個優(yōu)化目標(biāo),評估結(jié)果不夠精確,評估過程考慮的因素不夠全面,后續(xù)工作將圍繞微服務(wù)架構(gòu)本身及限界上下文討論更多的微服務(wù)劃分原則,并結(jié)合實際工程項目完善評估模型;其次,工具原型SCE 要求架構(gòu)設(shè)計人員將軟件制品轉(zhuǎn)化為格式規(guī)范的JSON 文件作為輸入,后續(xù)工作考慮將SCE 集成到微服務(wù)工具鏈,使圖形化軟件制品直接轉(zhuǎn)化為SCE 輸入,減少架構(gòu)設(shè)計人員的工作負(fù)擔(dān).