吳化堯 鄧文俊

(計(jì)算機(jī)軟件新技術(shù)國家重點(diǎn)實(shí)驗(yàn)室(南京大學(xué)) 南京 210023)(hywu@nju.edu.cn)

為了滿足企業(yè)動(dòng)態(tài)多變的業(yè)務(wù)需求、提高開發(fā)效率和業(yè)務(wù)擴(kuò)展能力，軟件工程的從業(yè)者在單體架構(gòu)的基礎(chǔ)上提出了面向服務(wù)的軟件開發(fā)方法.這一新方法使用相互獨(dú)立的服務(wù)作為構(gòu)建應(yīng)用程序的基本單元，可以在不影響系統(tǒng)運(yùn)行的情況下對(duì)服務(wù)進(jìn)行增刪和修改，從而實(shí)現(xiàn)軟件產(chǎn)品的快速構(gòu)建和動(dòng)態(tài)調(diào)整.此外，每個(gè)服務(wù)都可以選用最合適的技術(shù)體系進(jìn)行獨(dú)立開發(fā)，有助于提升軟件開發(fā)和維護(hù)的效率.

微服務(wù)是面向服務(wù)軟件開發(fā)的最新發(fā)展趨勢，其通常采用去中心化的服務(wù)管理方式，在傳統(tǒng)面向服務(wù)開發(fā)模式的基礎(chǔ)上進(jìn)一步降低了系統(tǒng)的耦合度.微服務(wù)還充分借鑒了云計(jì)算、容器技術(shù)以及DevOps等新的實(shí)踐方式，提高了每個(gè)服務(wù)的可伸縮性，能實(shí)現(xiàn)服務(wù)的快速部署和更改［1].在工業(yè)界，面向微服務(wù)的軟件開發(fā)方法已得到了許多成功的應(yīng)用，例如騰訊的微信(1)https://cloud.tencent.com/developer/article/1346997和優(yōu)步(2)https://cloud.tencent.com/developer/article/1346869等都采用了基于微服務(wù)的架構(gòu).

目前，已有研究工作對(duì)面向服務(wù)軟件開發(fā)方法進(jìn)行了總結(jié)［2-4]，但在遵循這些已有的理論和方法之外，微服務(wù)本身的一些新特性也要求人們設(shè)計(jì)更加契合的軟件開發(fā)方法.本文因此嘗試對(duì)面向微服務(wù)軟件開發(fā)方法進(jìn)行全面系統(tǒng)的總結(jié)，以幫助研究者和從業(yè)者了解該領(lǐng)域的最新研究進(jìn)展.具體地，我們首先使用系統(tǒng)文獻(xiàn)調(diào)研方法收集當(dāng)前與面向微服務(wù)軟件開發(fā)相關(guān)的研究論文；隨后，分別在需求分析、設(shè)計(jì)與實(shí)現(xiàn)、測試以及重構(gòu)這4個(gè)軟件工程生命周期的關(guān)鍵活動(dòng)上總結(jié)已有的方法、工具和實(shí)踐.在此基礎(chǔ)上，討論面向微服務(wù)軟件開發(fā)未來的研究方向.

1 背 景

軟件架構(gòu)定義了應(yīng)用程序的組件結(jié)構(gòu)及其之間的相互關(guān)系［5].隨著客戶需求的不斷演化，應(yīng)用程序通常會(huì)變得龐大且復(fù)雜，這就需要在軟件開發(fā)時(shí)定義并選擇最合適的架構(gòu)方式來盡可能地以最小成本滿足客戶的各種功能和非功能性需求［6].

1.1 面向服務(wù)架構(gòu)

單體架構(gòu)將整個(gè)應(yīng)用程序部署為一個(gè)統(tǒng)一的解決方案，其中各個(gè)組成模塊無法獨(dú)立運(yùn)行［7].這種架構(gòu)的優(yōu)勢在于其易于開發(fā)、測試和部署，但是隨著應(yīng)用程序規(guī)模的增長，單體應(yīng)用程序會(huì)變得難以理解和維護(hù)，對(duì)其中任何組件的更新都必須重新測試和部署整個(gè)應(yīng)用程序.此外，單體架構(gòu)還會(huì)產(chǎn)生技術(shù)鎖定，即所有組件都必須遵循同樣的框架和技術(shù)體系［8].

為了克服單體架構(gòu)的潛在缺陷，滿足應(yīng)用程序?qū)τ诳蓴U(kuò)展性、持續(xù)開發(fā)和技術(shù)選擇自由等需求，面向服務(wù)架構(gòu)(service oriented architecture, SOA)應(yīng)運(yùn)而生.SOA由Gartner公司在1996年首次提出［9]，它將整個(gè)應(yīng)用程序分解為若干個(gè)相互獨(dú)立、自包含、可重用的服務(wù)，使得整個(gè)應(yīng)用程序具有動(dòng)態(tài)、松耦合和分布式的特性.其中，每個(gè)服務(wù)是一個(gè)實(shí)現(xiàn)特定業(yè)務(wù)能力的與平臺(tái)無關(guān)實(shí)體，通過良好定義的標(biāo)準(zhǔn)化接口進(jìn)行通信，開發(fā)者可以對(duì)服務(wù)進(jìn)行描述、發(fā)布、發(fā)現(xiàn)和動(dòng)態(tài)組合［10-11].

SOA的實(shí)現(xiàn)需要3種角色的參與，即服務(wù)提供者、服務(wù)消費(fèi)者和服務(wù)注冊中心［9].服務(wù)提供者提供服務(wù)并將服務(wù)注冊到服務(wù)注冊中心，服務(wù)消費(fèi)者通過服務(wù)注冊中心獲取和使用服務(wù)，而服務(wù)注冊中心作為中間平臺(tái)聯(lián)通服務(wù)提供者和消費(fèi)者.與SOA相關(guān)的協(xié)議和標(biāo)準(zhǔn)包括描述3種參與者之間消息傳輸格式和方式的簡單對(duì)象訪問協(xié)議(simple object access protocol, SOAP［12])；描述服務(wù)功能、接口和位置等信息的Web服務(wù)描述語言(Web services description language， WSDL)；以及對(duì)服務(wù)進(jìn)行檢索的統(tǒng)一描述、發(fā)現(xiàn)和集成協(xié)議(universal descrip-tion, discovery, and integration, UDDI)等.

1.2 微服務(wù)架構(gòu)

微服務(wù)架構(gòu)可以視為面向服務(wù)軟件架構(gòu)的一個(gè)特定子類型.有研究者認(rèn)為微服務(wù)一詞由Lewis和Fowler在2014年首次提出［13-14]，不過據(jù)上述2人所述，這一概念至少在2012年之前就已存在［15].Lewis和Fowler將微服務(wù)架構(gòu)定義為通過一套小型服務(wù)(即微服務(wù))的集合來構(gòu)造單個(gè)應(yīng)用程序，其中每個(gè)微服務(wù)都在自己的進(jìn)程中運(yùn)行，并以輕量級(jí)機(jī)制(例如HTTP)進(jìn)行通信.

微服務(wù)架構(gòu)在軟件開發(fā)上主要有2種應(yīng)用模式，其中一種是從需求分析出發(fā)，從無到有地開發(fā)一個(gè)新的微服務(wù)應(yīng)用程序，本文第3～5節(jié)將分別從需求分析、設(shè)計(jì)與實(shí)現(xiàn)、測試這3個(gè)角度來梳理和總結(jié)相關(guān)研究的當(dāng)前進(jìn)展.另一種應(yīng)用是將已有系統(tǒng)(通常是單體應(yīng)用程序)重構(gòu)到微服務(wù)架構(gòu)，本文第6節(jié)將討論這種應(yīng)用的當(dāng)前研究進(jìn)展.

1.3 微服務(wù)架構(gòu)與SOA的主要區(qū)別

微服務(wù)可以直觀地理解為細(xì)粒度的SOA，但兩者的差異并不局限在粒度上.Lewis和Fowler［15]在給出微服務(wù)定義的同時(shí)，也總結(jié)了微服務(wù)架構(gòu)的九大特性，即服務(wù)組件化、按業(yè)務(wù)組織團(tuán)隊(duì)、做產(chǎn)品而不是項(xiàng)目、輕量級(jí)通信、去中心化治理、去中心化數(shù)據(jù)管理、基礎(chǔ)設(shè)施自動(dòng)化、容錯(cuò)設(shè)計(jì)以及演進(jìn)式設(shè)計(jì).上述特性通常被視為面向微服務(wù)開發(fā)的指導(dǎo)原則，從中我們可以發(fā)現(xiàn)微服務(wù)有別于SOA的一些特點(diǎn)：

1) 微服務(wù)的去中心化管理與SOA的集中式管理形成鮮明對(duì)比.每個(gè)微服務(wù)都是一個(gè)獨(dú)立的應(yīng)用程序，具有獨(dú)立的數(shù)據(jù)庫和運(yùn)行環(huán)境，這一自治性使得微服務(wù)能夠獨(dú)立部署和運(yùn)行.而SOA通常采用統(tǒng)一的數(shù)據(jù)中心，并依賴于企業(yè)服務(wù)總線或其他同類重量級(jí)中間件等產(chǎn)品［16].

2) 相比于SOA，微服務(wù)架構(gòu)更加重視高可用性、可伸縮性、負(fù)載均衡、故障轉(zhuǎn)移等特性.微服務(wù)運(yùn)行在高可用的分布式環(huán)境當(dāng)中，加上配套的監(jiān)控和容錯(cuò)管理機(jī)制，系統(tǒng)更加穩(wěn)定可靠.

3) 相比于SOA，微服務(wù)的細(xì)粒度特性在提高開發(fā)效率、增強(qiáng)對(duì)需求變化的響應(yīng)的同時(shí)也使得微服務(wù)數(shù)目成倍增長，微服務(wù)架構(gòu)尤其需要相應(yīng)的自動(dòng)化基礎(chǔ)設(shè)施來實(shí)現(xiàn)自動(dòng)集成、測試和部署.

2 文獻(xiàn)收集和匯總

我們采用系統(tǒng)文獻(xiàn)調(diào)研(systematic literature review, SLR)方法［17]來進(jìn)行文獻(xiàn)收集，以確保系統(tǒng)全面地覆蓋所有與微服務(wù)軟件開發(fā)相關(guān)的研究論文.

我們利用ACM Digital Library,IEEE Xplore,ScienceDirect,Springer Link和DBLP這5個(gè)英文數(shù)據(jù)庫以及中國知網(wǎng)中文數(shù)據(jù)庫對(duì)2019年6月之前發(fā)表的微服務(wù)開發(fā)相關(guān)文章進(jìn)行檢索，表1給出了文獻(xiàn)檢索使用的中、英文關(guān)鍵詞:

Table 1 Keywords of Literature Search表1 論文檢索關(guān)鍵詞

對(duì)于檢索到的文獻(xiàn)，我們首先閱讀標(biāo)題、摘要和結(jié)論，并應(yīng)用下述包含和排除標(biāo)準(zhǔn)來進(jìn)行第1輪篩選.具體地，我們將符合全部3個(gè)條件的文獻(xiàn)考慮在內(nèi)(包含標(biāo)準(zhǔn))：

1) 關(guān)注微服務(wù)軟件開發(fā)周期(需求分析、設(shè)計(jì)與實(shí)現(xiàn)、測試、重構(gòu))的一個(gè)或多個(gè)階段.

2) 發(fā)表形式為會(huì)議、期刊或書籍.

3) 發(fā)表日期為2014年至2019年6月.

并將符合2個(gè)條件中的任一條件的文獻(xiàn)排除在外(排除標(biāo)準(zhǔn))：

1) 僅將微服務(wù)軟件開發(fā)作為例子來討論.

2) 以中文和英文之外的語言發(fā)表.

第1輪篩選完成之后我們共得到103篇文獻(xiàn).然后，應(yīng)用滾雪球方法對(duì)上述103篇文獻(xiàn)進(jìn)行進(jìn)一步擴(kuò)充，即對(duì)文獻(xiàn)的所有參考文獻(xiàn)都應(yīng)用上述標(biāo)準(zhǔn)進(jìn)行篩選，補(bǔ)充新的相關(guān)文獻(xiàn).重復(fù)這一步驟直到不再加入新的文獻(xiàn)為止，這一步驟結(jié)束后我們獲得的文獻(xiàn)總數(shù)為134篇.最后，我們對(duì)上述134篇文獻(xiàn)進(jìn)行第2輪篩選，最終獲得91篇文獻(xiàn)作為本文調(diào)研的對(duì)象.圖1給出了這些文獻(xiàn)在軟件工程生命周期各項(xiàng)活動(dòng)上的分布，其中設(shè)計(jì)與實(shí)現(xiàn)是當(dāng)前研究最多的子領(lǐng)域.

Fig.1 Distribution of microservice research papers on software engineering activities圖1 研究論文在軟件工程問題上的分布

3 面向微服務(wù)的軟件需求分析

軟件需求包括功能需求和非功能需求，其中功能需求是軟件產(chǎn)品要實(shí)現(xiàn)的功能，用戶利用這些功能來完成特定的任務(wù)；非功能需求則刻畫了軟件在應(yīng)用時(shí)的相關(guān)約束和特性［18]，是軟件系統(tǒng)的重要質(zhì)量屬性［19].

表2給出了與微服務(wù)需求分析相關(guān)的6篇論文中所涉及的需求分析對(duì)象以及考慮的功能需求和非功能需求.我們發(fā)現(xiàn)在功能需求的獲取上，半數(shù)研究直接引用已有需求［20-21]或者分析類似應(yīng)用的需求［22]，而未涉及需求分析相關(guān)方法和流程的使用.我們同時(shí)也發(fā)現(xiàn)，由于微服務(wù)架構(gòu)的引入對(duì)應(yīng)用程序的非功能屬性帶來新的挑戰(zhàn)和要求，使得現(xiàn)有研究愈發(fā)重視應(yīng)用程序的非功能需求.在已有的6篇涉及需求分析的研究中，半數(shù)未考慮非功能需求［22-23]或者考慮了但沒有給出具體說明［21]，其余的研究均考慮且直接給出對(duì)應(yīng)非功能需求分析結(jié)果.

Table 2 Current Researches on Requirement Analysis of Microservices表2 微服務(wù)需求分析的已有研究

具體地，Richter等人［20]曾將電子座位預(yù)訂系統(tǒng)遷移到微服務(wù)，他們在一致性上考慮了避免為不同顧客提供相同的座位和多次預(yù)訂同一座位，在容錯(cuò)上考慮了容忍多個(gè)服務(wù)實(shí)例、虛擬機(jī)或基礎(chǔ)設(shè)施組件的故障并自動(dòng)從故障中恢復(fù)，在可擴(kuò)展性上考慮了服務(wù)、虛擬機(jī)和服務(wù)器的水平可伸縮性以及應(yīng)用程序的較高負(fù)荷上限等非功能性需求.Wizenty等人［24]開發(fā)了一個(gè)遠(yuǎn)程護(hù)理應(yīng)用程序，他們在可擴(kuò)展性方面要求能夠靈活地集成和提供新的功能以及能夠同時(shí)處理上千個(gè)應(yīng)用實(shí)例，在安全性方面考慮了對(duì)用戶個(gè)人數(shù)據(jù)的保護(hù)，同時(shí)在高可用性的基礎(chǔ)上增加彈性、健壯性和功能獨(dú)立性.Schneider等人［25]則研究了互聯(lián)汽車解決方案，在可擴(kuò)展性上要求能夠以有效的方式對(duì)使用頻繁或者資源緊張的組件進(jìn)行復(fù)制，在重用上要求劃分的服務(wù)將能在多個(gè)項(xiàng)目中使用，在持續(xù)部署上要求添加到服務(wù)中的特性必須立即可見以便能夠自動(dòng)測試與其他服務(wù)的兼容性.

4 面向微服務(wù)的軟件設(shè)計(jì)與實(shí)現(xiàn)

面向微服務(wù)的軟件設(shè)計(jì)與實(shí)現(xiàn)是微服務(wù)開發(fā)研究中的重點(diǎn).目前，在面向微服務(wù)的設(shè)計(jì)上已形成了一些架構(gòu)設(shè)計(jì)模式，如使用API網(wǎng)關(guān)來管理外部請(qǐng)求和進(jìn)行服務(wù)組合、每個(gè)服務(wù)配備一個(gè)數(shù)據(jù)庫來進(jìn)行數(shù)據(jù)存儲(chǔ)等［26]，但相關(guān)研究尚不成熟.與之相比，學(xué)術(shù)界關(guān)于SOA架構(gòu)設(shè)計(jì)模式已有很多研究，為了驗(yàn)證這些已有的設(shè)計(jì)模式能否用于面向微服務(wù)軟件的設(shè)計(jì)，Bogner等人［27]對(duì)3本SOA著作［28-30]中提及的118種設(shè)計(jì)模式進(jìn)行了定性分析.他們發(fā)現(xiàn)分別有63%,25%和12%的模式完全適用、部分適用和不適用于微服務(wù)，可見SOA與微服務(wù)在設(shè)計(jì)上具有許多共性.

但是，與SOA相比，微服務(wù)本身的特點(diǎn)也為軟件設(shè)計(jì)與實(shí)現(xiàn)帶來了諸多新的挑戰(zhàn).例如微服務(wù)的最優(yōu)劃分粒度難以把握，過細(xì)的粒度會(huì)導(dǎo)致微服務(wù)個(gè)數(shù)成倍增加，這大大增加了微服務(wù)之間相互調(diào)用和通信的復(fù)雜度.此外，每個(gè)微服務(wù)使用一個(gè)獨(dú)立的數(shù)據(jù)庫或者數(shù)據(jù)表，保證共享數(shù)據(jù)的一致性需要更多的操作和成本，而微服務(wù)所處的分布式環(huán)境也會(huì)對(duì)網(wǎng)絡(luò)延遲、分布式事務(wù)以及安全性等提出新的要求.

在本節(jié)中，我們參考Haselb?ck等人的一次訪談研究［31]，將微服務(wù)系統(tǒng)的設(shè)計(jì)空間劃分為2類主要的設(shè)計(jì)領(lǐng)域：系統(tǒng)設(shè)計(jì)以及組織結(jié)構(gòu)和流程.表3給出了這2類設(shè)計(jì)領(lǐng)域的詳細(xì)分類，以及每個(gè)子設(shè)計(jì)領(lǐng)域需要考慮的研究問題以及對(duì)應(yīng)的文獻(xiàn)統(tǒng)計(jì).值得一提的是，Haselb?ck等人［32-33]還對(duì)微服務(wù)接口、服務(wù)發(fā)現(xiàn)、容錯(cuò)、負(fù)載均衡4個(gè)子設(shè)計(jì)領(lǐng)域進(jìn)行了研究，提出了相應(yīng)的設(shè)計(jì)決策模型.

Table 3 Design Domain of Microservice Software表3 微服務(wù)軟件設(shè)計(jì)領(lǐng)域

4.1 系統(tǒng)設(shè)計(jì)

系統(tǒng)設(shè)計(jì)關(guān)注微服務(wù)架構(gòu)的設(shè)計(jì)，包括接口、數(shù)據(jù)管理、模塊化、服務(wù)發(fā)現(xiàn)、服務(wù)組合、容錯(cuò)、安全、負(fù)載均衡、監(jiān)控和日志等的設(shè)計(jì).

1) 接口

微服務(wù)接口設(shè)計(jì)需要考慮如何設(shè)計(jì)微服務(wù)之間進(jìn)行通信的接口，包括采用何種通信機(jī)制、提供什么樣的接口形式等.

就通信機(jī)制而言，微服務(wù)內(nèi)部通信具有交互頻繁、傳輸數(shù)據(jù)量不確定、接口數(shù)量多等特點(diǎn)，在實(shí)現(xiàn)上較為復(fù)雜.而微服務(wù)之間的通信主要有同步請(qǐng)求/響應(yīng)模式和異步消息通信模式2種方式：

① 同步請(qǐng)求/響應(yīng)模式無需中間件，具有較好的通用性，但是該模式會(huì)在一定程度上降低了系統(tǒng)可用性［75].目前主要實(shí)現(xiàn)有基于HTTP協(xié)議的Restful API，基于RPC和序列化支持多種消息格式的Thrift，以及二進(jìn)制格式的Protocol Buffer和Avro等，其中Restful API是當(dāng)前研究的主流［34-37].

② 異步消息通信模式無需等待請(qǐng)求響應(yīng)，并且支持發(fā)布/訂閱、發(fā)布/異步響應(yīng)和請(qǐng)求/異步響應(yīng)等多種通信機(jī)制，能夠提高系統(tǒng)的可用性.目前主要實(shí)現(xiàn)有AMQP的RabbitMQ以及Apache的Kafka.

此外，微服務(wù)接口設(shè)計(jì)還需要接口管理規(guī)范以表明接口如何被調(diào)用以及對(duì)關(guān)系復(fù)雜的接口進(jìn)行監(jiān)控和維護(hù).Swagger,API Blueprint和RAML是目前3種主流的Restful API接口管理規(guī)范.

2) 數(shù)據(jù)管理

數(shù)據(jù)管理旨在對(duì)服務(wù)完成特定功能所需的數(shù)據(jù)進(jìn)行管理，其關(guān)注如何設(shè)計(jì)微服務(wù)的數(shù)據(jù)庫、限制微服務(wù)對(duì)其他服務(wù)數(shù)據(jù)庫的訪問能力、保證共享數(shù)據(jù)在全局上的一致性等.

由于微服務(wù)之間采用的數(shù)據(jù)庫類型可能不同，要保證共享數(shù)據(jù)在全局上的一致性必須實(shí)現(xiàn)跨異構(gòu)數(shù)據(jù)庫的數(shù)據(jù)復(fù)制.針對(duì)這一問題，Viennot等人［38]提出了一個(gè)用于集成大規(guī)模、數(shù)據(jù)驅(qū)動(dòng)服務(wù)的Synapse框架，它支持多種SQL和NoSQL數(shù)據(jù)庫之間的數(shù)據(jù)復(fù)制，使得依賴于它的服務(wù)能以相互隔離、可伸縮的方式共享數(shù)據(jù)，確保不同服務(wù)中數(shù)據(jù)的一致性.

此外，微服務(wù)架構(gòu)在跨不同流程的服務(wù)組合時(shí)會(huì)面臨數(shù)據(jù)丟失的風(fēng)險(xiǎn).為此，Messina等人［39]提出了數(shù)據(jù)庫即服務(wù)的架構(gòu)模式，該模式將數(shù)據(jù)庫功能作為一個(gè)微服務(wù)，使得服務(wù)與數(shù)據(jù)之間嚴(yán)格耦合.每當(dāng)數(shù)據(jù)庫需要擴(kuò)展其功能時(shí)，可以直接在數(shù)據(jù)庫中嵌入實(shí)現(xiàn)該擴(kuò)展功能的業(yè)務(wù)邏輯，從而在降低架構(gòu)復(fù)雜性和相關(guān)風(fēng)險(xiǎn)的同時(shí)提高微服務(wù)應(yīng)用的可伸縮性.

3) 模塊化

模塊化的核心是如何劃分微服務(wù)，其中的一個(gè)重要問題是微服務(wù)粒度的確定.SOA中服務(wù)的規(guī)?？梢蕴幱谛⌒蛻?yīng)用程序到大型企業(yè)級(jí)系統(tǒng)之間［76]，而微服務(wù)則通常是小型、細(xì)粒度的服務(wù).

領(lǐng)域驅(qū)動(dòng)的設(shè)計(jì)(domain-driven design, DDD)［77]是目前進(jìn)行服務(wù)劃分的常用方法.DDD是一系列軟件設(shè)計(jì)實(shí)踐、技術(shù)和原則的集合，能夠?qū)㈩I(lǐng)域模型解耦成包含部分業(yè)務(wù)流程且相互區(qū)別的有界上下文(bounded context)并表達(dá)它們之間的關(guān)系.DDD中的每個(gè)有界上下文能自然地成為一個(gè)微服務(wù)的候選，但在使用DDD進(jìn)行微服務(wù)劃分時(shí)也需要有針對(duì)性地解決一些新的問題［40]：

① DDD中的有界上下文和領(lǐng)域模型缺乏對(duì)語義表達(dá)的支持，因此在微服務(wù)劃分時(shí)會(huì)產(chǎn)生語法、結(jié)構(gòu)和語義上的理解或轉(zhuǎn)換問題.針對(duì)這一問題，Diepenbrock等人［41]提出了基于DDD建模微服務(wù)的元模型，該模型能夠有效表達(dá)領(lǐng)域模型和共享模型的語義以及它們在有界上下文間的關(guān)系.

② DDD不是一個(gè)形式化的建模語言，這在一定程度上阻礙了模型的驗(yàn)證和轉(zhuǎn)換.針對(duì)這一問題，Rademacher等人［42]使用UML配置文件來輔助領(lǐng)域驅(qū)動(dòng)的微服務(wù)建模，其不僅為DDD提供原型和約束，還支持將結(jié)構(gòu)化領(lǐng)域模型表示為UML類圖，解決了模型的驗(yàn)證和轉(zhuǎn)換問題.

③ DDD缺乏對(duì)軟件開發(fā)過程的描述，其中的概念和任務(wù)不能直接擴(kuò)展到微服務(wù)開發(fā).針對(duì)這一問題，Steinegger等人［43-44]提出了一個(gè)DDD軟件開發(fā)過程來構(gòu)建微服務(wù).他們首先在軟件工程領(lǐng)域中對(duì)DDD活動(dòng)進(jìn)行分類，然后根據(jù)DDD的分類和要求研究構(gòu)建微服務(wù)應(yīng)用程序所需的各類軟件開發(fā)活動(dòng)，并將這些活動(dòng)應(yīng)用到案例研究中.

盡管目前已有針對(duì)微服務(wù)的劃分方法，但上述方法所產(chǎn)生的結(jié)果是否滿足高內(nèi)聚、低耦合等劃分的核心原則仍需進(jìn)一步的驗(yàn)證.為此，鐘陳星等人［45]提出了一個(gè)基于領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中有界上下文理論的微服務(wù)粒度評(píng)估模型，該模型能夠評(píng)估劃分后服務(wù)的內(nèi)聚性、耦合性、用例收斂性和實(shí)例收斂性，并給出對(duì)應(yīng)微服務(wù)劃分方案的綜合評(píng)分.

4) 服務(wù)發(fā)現(xiàn)

服務(wù)發(fā)現(xiàn)將服務(wù)注冊到服務(wù)注冊中心，并提供服務(wù)實(shí)例的具體網(wǎng)絡(luò)位置(IP地址和端口)供其他服務(wù)調(diào)用.SOA相關(guān)研究中已有很多服務(wù)發(fā)現(xiàn)方法(如基于服務(wù)質(zhì)量［78]、語義［79]、Petri網(wǎng)［80]的服務(wù)發(fā)現(xiàn))，這些方法理論上也可用于微服務(wù)架構(gòu).然而，由于微服務(wù)中服務(wù)數(shù)量龐大、且在開發(fā)技術(shù)體系與SOA存在很大差異，因此已有的服務(wù)發(fā)現(xiàn)方法未必都適用于微服務(wù).

針對(duì)容器中微服務(wù)的服務(wù)發(fā)現(xiàn)和通信問題，Stubbs等人［46]提出了一個(gè)可擴(kuò)展的開源解決方案Serfnode，其中新加入的容器能夠在Serfnode鏡像中廣播自己以供其他服務(wù)發(fā)現(xiàn).針對(duì)云平臺(tái)環(huán)境下微服務(wù)數(shù)目眾多、且在給定需求和優(yōu)先級(jí)條件下難以從中找到最合適服務(wù)的問題，F(xiàn)ranca等人［47]提出了一個(gè)從技術(shù)、社會(huì)(如使用信息和評(píng)論)和語義3個(gè)角度來挑選微服務(wù)的框架DIRECTOR，能夠在數(shù)百個(gè)候選對(duì)象中推薦出最符合需求和優(yōu)先級(jí)條件的微服務(wù).此外，針對(duì)傳統(tǒng)的單節(jié)點(diǎn)部署在容錯(cuò)能力上的缺陷，Tang等人［48]提出了一個(gè)分布式的服務(wù)發(fā)現(xiàn)機(jī)制，通過服務(wù)發(fā)現(xiàn)數(shù)據(jù)的特點(diǎn)改進(jìn)了用于解決分布式不一致性問題的Raft算法，從而確保集群中節(jié)點(diǎn)服務(wù)發(fā)現(xiàn)數(shù)據(jù)的一致性.

目前，在服務(wù)發(fā)現(xiàn)上已有很多開源軟件產(chǎn)品，例如Eureka,Etcd,Consul,Zookeeper和Redis等，其中Eureka是目前研究中最常用的服務(wù)發(fā)現(xiàn)系統(tǒng)［24,34,37,49].

5) 服務(wù)組合

服務(wù)組合關(guān)注如何將已有的多個(gè)功能獨(dú)立的服務(wù)組合成功能更為復(fù)雜和完善的整體應(yīng)用，以滿足一定的應(yīng)用需求.服務(wù)組合有編排(orchestration)和協(xié)同(choreography)兩種方式：服務(wù)編排通過一個(gè)中央?yún)f(xié)調(diào)器來協(xié)調(diào)對(duì)多個(gè)服務(wù)的調(diào)用，而服務(wù)協(xié)同是指在沒有中央?yún)f(xié)調(diào)器的情況下，所有服務(wù)以對(duì)等的方式相互協(xié)作［76].SOA通常使用WS-BPEL和WS-CDL語言來實(shí)現(xiàn)服務(wù)編排和協(xié)同；與之相比，微服務(wù)的去中心化和獨(dú)立性使其更傾向于服務(wù)協(xié)同的方式.

目前，在服務(wù)組合上已有很多系統(tǒng)和工具可供使用.其中，Spring Cloud通過輕量級(jí)的事件驅(qū)動(dòng)機(jī)制來實(shí)現(xiàn)服務(wù)組合，并利用RabbitMQ或Kafka等事件處理中介來協(xié)調(diào)組合服務(wù)的調(diào)用；而Netflix的服務(wù)組合開源框架Conductor將系統(tǒng)所需的微服務(wù)和系統(tǒng)服務(wù)結(jié)合在一起，形成一個(gè)完整的服務(wù)組合藍(lán)圖來實(shí)現(xiàn)某項(xiàng)功能［50].

此外，Yahia等人［51]開發(fā)了一個(gè)用于微服務(wù)組合的事件驅(qū)動(dòng)輕量級(jí)平臺(tái)Medley，可以在主流服務(wù)器和嵌入式設(shè)備上進(jìn)行擴(kuò)展，且僅消耗較少的資源.Camilli等人［52]提出了一種基于工作流的微服務(wù)組合建模形式化方法，并指定了一種基于Petri網(wǎng)的微服務(wù)形式化語義，以工作流組合的形式來驗(yàn)證微服務(wù)組合方案的可行性.Zhang等人［53]針對(duì)視頻云計(jì)算平臺(tái)的微服務(wù)提出了一種性能感知的服務(wù)路徑選擇方法，該方法首先建立一個(gè)性能評(píng)估模型來衡量視頻處理任務(wù)的特點(diǎn)以及微服務(wù)實(shí)例的處理能力和信息傳輸條件，然后基于該模型使用最短路徑算法搜索和更新最佳微服務(wù)組合路徑.

6) 容錯(cuò)

容錯(cuò)使得軟件系統(tǒng)在運(yùn)行時(shí)能夠檢測故障并從故障中恢復(fù)，防止故障對(duì)系統(tǒng)運(yùn)行造成影響.微服務(wù)涉及的故障通常包括由于服務(wù)崩潰或者網(wǎng)絡(luò)延遲等原因造成的無法訪問服務(wù)，以及服務(wù)過載等.

目前，Hystrix［49]是常用的微服務(wù)容錯(cuò)開源框架，其綜合考慮了服務(wù)超時(shí)、負(fù)載、錯(cuò)誤及服務(wù)隔離等因素.Hystrix能夠封裝服務(wù)調(diào)用邏輯，使每個(gè)服務(wù)在單獨(dú)線程中執(zhí)行，并提供了斷路器、調(diào)用超時(shí)設(shè)置和資源隔離3方面功能來保障微服務(wù)的可靠性.

7) 安全

目前與微服務(wù)安全相關(guān)的設(shè)計(jì)主要關(guān)注外部對(duì)于系統(tǒng)訪問的安全性以及系統(tǒng)內(nèi)部微服務(wù)之間相互調(diào)用的安全性.

在外部對(duì)于系統(tǒng)訪問的安全性上，目前研究主要通過API網(wǎng)關(guān)［24,35-37,54]來進(jìn)行身份驗(yàn)證和授權(quán).API網(wǎng)關(guān)不僅能夠封裝微服務(wù)系統(tǒng)內(nèi)部架構(gòu)，為客戶端提供統(tǒng)一接口，還能根據(jù)請(qǐng)求調(diào)用單個(gè)微服務(wù)或者通過服務(wù)編排調(diào)用多個(gè)微服務(wù)并返回結(jié)果(即起到服務(wù)發(fā)現(xiàn)和組合的作用).此外，通過API網(wǎng)關(guān)還能實(shí)現(xiàn)負(fù)載均衡、緩存、路由、訪問控制、服務(wù)代理、監(jiān)控和日志等功能.Zuul,Kong和gRPC等是目前微服務(wù)開發(fā)常用的開源網(wǎng)關(guān)，同時(shí)OAuth2標(biāo)準(zhǔn)(3)https://oauth.net/2/常被用于保障外部對(duì)于系統(tǒng)的訪問安全.此外，F(xiàn)u等人［55]還分析了傳統(tǒng)訪問控制技術(shù)在微服務(wù)環(huán)境中的局限性，并提出了一種基于角色的訪問控制模型以提高訪問策略的表達(dá)能力.

在系統(tǒng)內(nèi)部微服務(wù)之間相互調(diào)用的安全性上，網(wǎng)絡(luò)中錯(cuò)綜復(fù)雜的情況使得微服務(wù)之間不能完全彼此信任.針對(duì)這一問題，Yarygina等人［56]提出了一個(gè)結(jié)合MTLS(mutual transport layer security)、自托管PKI(public key infrastructure)和安全令牌機(jī)制的安全框架，以確保微服務(wù)之間通信的安全和可信.

8) 負(fù)載均衡

一個(gè)微服務(wù)通常具有多個(gè)實(shí)例，負(fù)載均衡將對(duì)同一微服務(wù)的多個(gè)請(qǐng)求分配到該微服務(wù)的特定實(shí)例進(jìn)行處理，從而保證同一微服務(wù)的每個(gè)實(shí)例所處理的請(qǐng)求在數(shù)目上大致保持一致.

負(fù)載均衡可分為客戶端負(fù)載均衡和服務(wù)端負(fù)載均衡，其中服務(wù)端負(fù)載均衡需要使用一個(gè)獨(dú)立的負(fù)載均衡服務(wù)［75].目前，Ribbon是實(shí)現(xiàn)客戶端負(fù)載均衡的常用工具，API網(wǎng)關(guān)的請(qǐng)求轉(zhuǎn)發(fā)和微服務(wù)間的調(diào)用等實(shí)際上都是通過Ribbon來協(xié)調(diào)實(shí)現(xiàn)的.與之相比，服務(wù)端負(fù)載均衡可以通過硬件或者軟件來實(shí)現(xiàn).硬件指的是在服務(wù)器節(jié)點(diǎn)間安裝專門用于負(fù)載均衡的設(shè)備如Array,F5等;而軟件指的是在服務(wù)器上使用一些具有均衡負(fù)載功能的軟件如LVS,Nginx等來完成請(qǐng)求分發(fā)工作.

此外，Niu等人［57]提出了基于消息隊(duì)列的面向微服務(wù)調(diào)用鏈的負(fù)載均衡算法，該算法通過減少網(wǎng)絡(luò)開銷和減少操作復(fù)雜度來降低微服務(wù)響應(yīng)時(shí)間；Rusek等人［58]則為運(yùn)行在OpenVZ容器中的微服務(wù)提供了一個(gè)非集中式的負(fù)載均衡系統(tǒng)，該系統(tǒng)相比于集中式的容器編排系統(tǒng)能夠提升一定的性能.

9) 監(jiān)控和日志

微服務(wù)監(jiān)控的主要目的是在系統(tǒng)運(yùn)行時(shí)對(duì)基礎(chǔ)設(shè)施、微服務(wù)等的性能進(jìn)行觀察，而日志則用于在微服務(wù)等發(fā)生故障后快速排除錯(cuò)誤.目前這一設(shè)計(jì)領(lǐng)域關(guān)注微服務(wù)監(jiān)控的整體設(shè)計(jì)，監(jiān)控指標(biāo)的設(shè)計(jì)以及對(duì)應(yīng)監(jiān)控?cái)?shù)據(jù)或日志的收集和分析.

在微服務(wù)監(jiān)控的整體設(shè)計(jì)上，Haselb?ck等人［59]提出一個(gè)指導(dǎo)監(jiān)控?cái)?shù)據(jù)生成、管理、處理和展示的決策指導(dǎo)模型.劉一田等人［60]提出了一個(gè)對(duì)微服務(wù)狀態(tài)和負(fù)載進(jìn)行監(jiān)控，并基于聚類分析算法對(duì)實(shí)時(shí)和歷史數(shù)據(jù)進(jìn)行統(tǒng)計(jì)分析的微服務(wù)監(jiān)控框架.

在監(jiān)控指標(biāo)的設(shè)計(jì)以及對(duì)應(yīng)監(jiān)控?cái)?shù)據(jù)或日志的收集和分析上，王子勇等人［61]以服務(wù)組件的請(qǐng)求處理流為監(jiān)控指標(biāo)，利用調(diào)用樹來刻畫請(qǐng)求處理的執(zhí)行軌跡并監(jiān)測使執(zhí)行軌跡發(fā)生偏離的系統(tǒng)故障，最后通過分析執(zhí)行軌跡差異來識(shí)別引起故障的關(guān)鍵方法調(diào)用.

此外，Sun等人［62]還提出了安全即服務(wù)模式，該模式通過為網(wǎng)絡(luò)虛擬機(jī)管理程序添加新的API原語以支持細(xì)粒度、靈活的虛擬網(wǎng)絡(luò)流量監(jiān)控，確保微服務(wù)應(yīng)用程序的安全.

4.2 組織架構(gòu)和流程

微服務(wù)組織架構(gòu)和流程關(guān)注微服務(wù)軟件開發(fā)團(tuán)隊(duì)的組織模式，以及開發(fā)和部署微服務(wù)的流程.

1) 開發(fā)團(tuán)隊(duì)組織

“康威定律”指出：開發(fā)團(tuán)隊(duì)組織的結(jié)構(gòu)在很大程度上會(huì)影響其在系統(tǒng)設(shè)計(jì)上的結(jié)果［81].微服務(wù)系統(tǒng)的結(jié)構(gòu)與傳統(tǒng)軟件的結(jié)構(gòu)并不相同，因此必須以不同于傳統(tǒng)軟件開發(fā)團(tuán)隊(duì)組織的方式來組織微服務(wù)開發(fā)團(tuán)隊(duì).Carrasco等人［63]認(rèn)為應(yīng)根據(jù)不同微服務(wù)組建跨職能團(tuán)隊(duì)，一個(gè)團(tuán)隊(duì)完全對(duì)自己的微服務(wù)負(fù)責(zé)，而不是多個(gè)團(tuán)隊(duì)共同開發(fā)一個(gè)微服務(wù)，即每個(gè)團(tuán)隊(duì)具有完全開發(fā)微服務(wù)所需的所有技能以確保團(tuán)隊(duì)和微服務(wù)的獨(dú)立性.

2) 部署

與傳統(tǒng)SOA使用整體式部署方式不同［82]，微服務(wù)采用獨(dú)立部署且主要有2種部署方式：1)將多個(gè)微服務(wù)實(shí)例部署在單個(gè)物理機(jī)或虛擬機(jī)上，優(yōu)點(diǎn)是部署速度快，資源的利用率高，缺點(diǎn)是服務(wù)實(shí)例之間隔離性較差，可能會(huì)出現(xiàn)某個(gè)實(shí)例占用過多內(nèi)存或CPU資源的情況;2)將單個(gè)微服務(wù)實(shí)例部署在單個(gè)物理機(jī)或虛擬機(jī)上(通常是輕量級(jí)的虛擬機(jī))，該方法在部署上更加輕量靈活，但可能面臨資源利用率不高、服務(wù)實(shí)例的維護(hù)效率低等問題［75].

其中，通過以Docker(4)https://www.docker.com/為代表的容器技術(shù)來部署微服務(wù)已成為微服務(wù)軟件部署的必然趨勢［24]，其還可與Kubemetes,Mesos和Docker Swarm等容器編排工具相結(jié)合實(shí)現(xiàn)容器分配和管理的自動(dòng)化和可視化［83].當(dāng)使用容器來部署微服務(wù)時(shí)，也存在一個(gè)容器部署一個(gè)微服務(wù)和一個(gè)容器部署多個(gè)微服務(wù)2種方式.Shadija等人［64]對(duì)這2種方式進(jìn)行了性能上的比較，發(fā)現(xiàn)在服務(wù)延遲上兩者并沒有明顯區(qū)別.

微服務(wù)在部署時(shí)還需要解決容器調(diào)度和資源分配等問題.例如，針對(duì)容器調(diào)度問題，Zhou等人［65]提出了一個(gè)云計(jì)算環(huán)境下對(duì)容器中微服務(wù)進(jìn)行離線和在線調(diào)度的框架，旨在最大限度地降低部署微服務(wù)的成本.針對(duì)容器資源的分配問題，Guerrero等人［66]使用多目標(biāo)遺傳算法對(duì)容器配置進(jìn)行優(yōu)化，該方法優(yōu)于Kubernetes中提供的容器管理策略.郝庭毅等人［67]為容器內(nèi)微服務(wù)提供了一種彈性資源供給方法，該方法基于應(yīng)用負(fù)載、資源消耗和響應(yīng)時(shí)間的關(guān)聯(lián)關(guān)系，利用卡爾曼濾波來預(yù)測不同資源配置下的服務(wù)響應(yīng)時(shí)間.Wan等人［68]則提出了一個(gè)優(yōu)化容器放置位置和任務(wù)分配的算法，能在保證應(yīng)用程序服務(wù)延遲要求的同時(shí)最小化應(yīng)用程序部署和運(yùn)營的成本.

此外，在與微服務(wù)部署相關(guān)的平臺(tái)和工具的支持上，李超等人［69]提出了微服務(wù)應(yīng)用部署引擎OpsFlow，通過組合多種自動(dòng)化部署技術(shù)以應(yīng)對(duì)不同的微服務(wù)部署環(huán)境.Zheng等人［70]提出了一個(gè)以微服務(wù)為中心且支持服務(wù)質(zhì)量標(biāo)準(zhǔn)的SmartVM服務(wù)部署框架，該框架能夠簡化構(gòu)建和部署微服務(wù)的流程，在部署成本、資源利用和服務(wù)質(zhì)量上均優(yōu)于傳統(tǒng)的微服務(wù)部署方法.Gabbrielli等人［71]提出了一個(gè)以面向服務(wù)編程語言Jolie編寫的服務(wù)部署工具JRO，用于實(shí)現(xiàn)微服務(wù)的自動(dòng)和優(yōu)化部署.Guo等人［72]提出了一個(gè)基于微服務(wù)和容器技術(shù)的部署平臺(tái).

3) DevOps

DevOps是一組集成自動(dòng)化軟件開發(fā)、部署和維護(hù)的技術(shù)，旨在提高開發(fā)團(tuán)隊(duì)持續(xù)交付的能力以適應(yīng)客戶需求的變化，同時(shí)保證軟件產(chǎn)品的質(zhì)量［73].

Chen［73]在4年的實(shí)踐研究中發(fā)現(xiàn)，DevOps對(duì)于軟件可部署性和可修改性的要求很高，單體架構(gòu)難以滿足這一要求，而微服務(wù)架構(gòu)在這點(diǎn)上十分契合.同時(shí)，對(duì)于微服務(wù)軟件而言，每個(gè)微服務(wù)都是一個(gè)可部署單元，需求的快速變化要求微服務(wù)能夠被快速自動(dòng)地部署.因此，DevOps和微服務(wù)的結(jié)合勢在必行.

在微服務(wù)開發(fā)中應(yīng)用DevOps的一個(gè)關(guān)鍵要素是DevOps工具鏈.Ebert等人［74]研究了一系列適用于微服務(wù)開發(fā)的自動(dòng)化工具，包括有助于實(shí)現(xiàn)快速迭代的Apache Ant,Maven,Rake和Gradle自動(dòng)化構(gòu)建工具；盡早將開發(fā)者工作集成起來的Jenkins,TeamCity和Bamboo持續(xù)集成工具；實(shí)現(xiàn)基礎(chǔ)設(shè)施管理自動(dòng)化的Puppet,Chef和Ansible配置管理工具；以及保持基礎(chǔ)設(shè)施穩(wěn)定性和性能的Graylog2日志工具和Nagios,New Relic監(jiān)控工具.

除了針對(duì)上述單個(gè)設(shè)計(jì)領(lǐng)域的具體研究外，微服務(wù)框架和服務(wù)網(wǎng)格技術(shù)還能為多個(gè)設(shè)計(jì)領(lǐng)域的實(shí)現(xiàn)提供統(tǒng)一的解決方案，方便開發(fā)者快速構(gòu)建微服務(wù).其中，微服務(wù)框架是微服務(wù)體系結(jié)構(gòu)的具體實(shí)現(xiàn)及解決方案，是企業(yè)、研究者在構(gòu)建微服務(wù)時(shí)將眾多關(guān)鍵技術(shù)如服務(wù)部署、服務(wù)通信和服務(wù)發(fā)現(xiàn)等集成為一個(gè)整體，從而形成的一種框架或方案.目前研究主要使用Spring Cloud(5)https://spring.io/projects/spring-cloud/這一微服務(wù)框架［37,49]，其為微服務(wù)架構(gòu)中涉及的配置管理、服務(wù)治理、斷路器、智能路由、控制總線、分布式會(huì)話和集群狀態(tài)管理等操作提供了一種簡單的開發(fā)方式.

另一方面，服務(wù)網(wǎng)格被稱為“下一代微服務(wù)”，其通過統(tǒng)一的控制平面來定義服務(wù)發(fā)現(xiàn)、熔斷、限流、降級(jí)、分布式跟蹤等策略，并為每一個(gè)微服務(wù)實(shí)例部署一個(gè)稱為隨行(sidecar)的代理.微服務(wù)之間通過該代理進(jìn)行通信，該代理負(fù)責(zé)在服務(wù)通信時(shí)應(yīng)用和執(zhí)行預(yù)先定義的治理策略，從而為所有微服務(wù)提供完全集成的服務(wù)治理環(huán)境.目前較為成熟的服務(wù)網(wǎng)格有Istio(6)https://istio.io/,Linkerd(7)https://linkerd.io/和Consul(8)https://www.consul.io/等.

5 面向微服務(wù)的軟件測試

與傳統(tǒng)軟件測試方法類似，對(duì)微服務(wù)的測試通常包括單元測試、集成測試、組件測試和端到端測試這4個(gè)層次［84].其中，單元測試關(guān)注對(duì)微服務(wù)內(nèi)部的模塊進(jìn)行測試；集成測試驗(yàn)證微服務(wù)內(nèi)部模塊之間、以及內(nèi)部模塊與外部組件之間的交互；組件測試用于驗(yàn)證每個(gè)微服務(wù)本身能否滿足相應(yīng)需求；而端到端測試則是測試微服務(wù)應(yīng)用程序的整體行為，以最終軟件產(chǎn)品的視角來驗(yàn)證應(yīng)用程序是否滿足業(yè)務(wù)目標(biāo).然而，微服務(wù)系統(tǒng)通常由眾多服務(wù)組成，這些服務(wù)同時(shí)運(yùn)行、互相調(diào)用、并且容易發(fā)生變化，這些特性會(huì)為面向微服務(wù)的軟件測試帶來了一些新的挑戰(zhàn).

我們共收集到16篇與微服務(wù)測試相關(guān)的文獻(xiàn)，按研究內(nèi)容可分為組件測試、端到端測試、回歸測試、驗(yàn)收測試、變異測試和微服務(wù)調(diào)試.

在組件測試上，Wu等人［85]提出了一個(gè)基于故障注入的微服務(wù)應(yīng)用容錯(cuò)性能測試框架，以驗(yàn)證目標(biāo)服務(wù)的容錯(cuò)能力.Heorhiadi等人［86]提出了一個(gè)對(duì)微服務(wù)故障處理能力進(jìn)行測試的框架，該框架允許操作員通過操縱服務(wù)間通信來執(zhí)行自動(dòng)化測試.Camargo等人［87]提出了一個(gè)對(duì)微服務(wù)進(jìn)行性能測試的方法，該方法將包含測試參數(shù)的規(guī)范附加到每個(gè)服務(wù)，從而對(duì)這些參數(shù)進(jìn)行自動(dòng)化測試.Rahman等人［88]研究了微服務(wù)的并行測試，他們利用Docker容器的操作系統(tǒng)級(jí)虛擬化特點(diǎn)來為微服務(wù)的并行執(zhí)行提供沙箱機(jī)制.此外，還有研究者利用組件測試來幫助確定微服務(wù)部署方案，例如Avritzer等人［89]通過分析部署完成后的微服務(wù)負(fù)載來定量評(píng)估不同內(nèi)存、CPU分配條件下的微服務(wù)部署方案，從而幫助確定最優(yōu)部署配置.

在端到端測試上，Ma等人［90]提出了一個(gè)能夠自動(dòng)生成微服務(wù)系統(tǒng)對(duì)應(yīng)的服務(wù)依賴圖的方法.該方法能夠在開發(fā)的早期階段對(duì)存在風(fēng)險(xiǎn)的調(diào)用鏈進(jìn)行分析和測試，并在開發(fā)新版本系統(tǒng)時(shí)追蹤不同服務(wù)間的聯(lián)系.Meinke等人［91]則使用基于學(xué)習(xí)的測試來評(píng)估微服務(wù)系統(tǒng)功能的正確性和魯棒性.

在回歸測試上，Kargar等人［92]提出了一個(gè)將回歸測試結(jié)合到微服務(wù)系統(tǒng)開發(fā)持續(xù)交付過程的自動(dòng)化測試方法.在新版本交付時(shí)，該方法能根據(jù)資源使用率、系統(tǒng)故障率、系統(tǒng)性能等指標(biāo)將現(xiàn)版本系統(tǒng)與之前版本進(jìn)行比較，并在需要時(shí)阻止發(fā)布最新版本.

在驗(yàn)收測試上，Rahman等人［93]提出了一個(gè)可重用的自動(dòng)測試框架，該框架能夠檢驗(yàn)微服務(wù)倉庫在可重用性、可審計(jì)性和可維護(hù)性上是否滿足預(yù)期和驗(yàn)收標(biāo)準(zhǔn)，同時(shí)還能減少開發(fā)人員和測試人員之間的沖突，允許他們在實(shí)現(xiàn)相同應(yīng)用程序目標(biāo)的同時(shí)能夠獨(dú)立地對(duì)微服務(wù)倉庫進(jìn)行迭代檢驗(yàn).

在變異測試上，Winzinger［94]提出了一個(gè)針對(duì)微服務(wù)測試創(chuàng)建變異算子的初步設(shè)想，使用該算子能夠有效評(píng)估微服務(wù)測試用例的質(zhì)量.

在微服務(wù)調(diào)試上，Zhou等人［95]對(duì)工業(yè)界中微服務(wù)系統(tǒng)的典型故障、調(diào)試實(shí)踐以及開發(fā)人員所面臨的挑戰(zhàn)進(jìn)行了調(diào)研，并開發(fā)了一個(gè)基準(zhǔn)微服務(wù)系統(tǒng)來驗(yàn)證這些實(shí)踐的有效性，其發(fā)現(xiàn)最新的跟蹤和可視化技術(shù)能夠提升這些現(xiàn)有實(shí)踐.此外，他們還針對(duì)微服務(wù)的高度復(fù)雜性和動(dòng)態(tài)性，提出了一種增量式的調(diào)試方法［96]，以及一種基于系統(tǒng)跟蹤日志學(xué)習(xí)的故障預(yù)測和定位方法［97].李文海等人［98]提出了一個(gè)基于日志可視化分析的微服務(wù)軟件調(diào)試方法，該方法通過日志、調(diào)用鏈、節(jié)點(diǎn)與服務(wù)信息構(gòu)建日志模型，并針對(duì)典型微服務(wù)故障提出具體的可視化調(diào)試策略.Rajagopalan等人［99]則開發(fā)了一個(gè)對(duì)微服務(wù)性能故障進(jìn)行定位和修復(fù)的自動(dòng)化工具，該工具能夠?qū)⒉煌姹镜奈⒎?wù)進(jìn)行統(tǒng)一測試和部署，并能通過部分回滾來修復(fù)當(dāng)前版本的性能問題，直到找到一個(gè)不存在性能故障的組合.

6 面向微服務(wù)的重構(gòu)

面向微服務(wù)的軟件重構(gòu)旨在將傳統(tǒng)上難于維護(hù)和擴(kuò)展的單體應(yīng)用程序重構(gòu)為微服務(wù)應(yīng)用程序(即將單體應(yīng)用程序遷移到微服務(wù)).由于微服務(wù)自身的特點(diǎn)，面向微服務(wù)的重構(gòu)主要具有3項(xiàng)挑戰(zhàn)：

1) 現(xiàn)有應(yīng)用的模塊數(shù)目通常十分龐大，在確定接口和通信方式、構(gòu)建支持微服務(wù)運(yùn)行的穩(wěn)定分布式環(huán)境、以及構(gòu)建自動(dòng)化基礎(chǔ)設(shè)施等方面都需要巨大的工作量；

2) 將數(shù)據(jù)庫有效拆分和分配給對(duì)應(yīng)的微服務(wù)，同時(shí)保持?jǐn)?shù)據(jù)一致性的復(fù)雜性；

3) 微服務(wù)是無狀態(tài)的，但是單一的遺留代碼通常是有狀態(tài)的［100]，需要處理這種從有狀態(tài)到無狀態(tài)的轉(zhuǎn)換.

目前，與面向微服務(wù)重構(gòu)相關(guān)的研究主要集中在重構(gòu)的流程、方法和決策，微服務(wù)的提取，以及相關(guān)的實(shí)證和經(jīng)驗(yàn)研究.

在重構(gòu)流程上，F(xiàn)rancesco等人［101]認(rèn)為微服務(wù)的重構(gòu)過程與將已有系統(tǒng)遷移到面向服務(wù)架構(gòu)的過程一致，包括逆向工程(分析已有系統(tǒng)并且識(shí)別出能夠作為服務(wù)的候選元素)、架構(gòu)轉(zhuǎn)換(將已有系統(tǒng)體系結(jié)構(gòu)重構(gòu)為面向微服務(wù)的體系結(jié)構(gòu))和前向工程(最終確定、實(shí)施和部署新系統(tǒng)的設(shè)計(jì))這3個(gè)步驟.Taibi等人［102]給出了一個(gè)由3個(gè)流程組成的遷移過程框架，其中前2個(gè)流程用于從頭開始重新開發(fā)整個(gè)系統(tǒng)，另一個(gè)用于在現(xiàn)有系統(tǒng)之上以微服務(wù)架構(gòu)創(chuàng)建新功能.Fan等人［103]則從軟件生命周期的角度考慮遷移流程，并總結(jié)了每個(gè)階段的方法和工具.

在重構(gòu)方法上，F(xiàn)ritzsch等人［104]將已有的重構(gòu)方法分為靜態(tài)代碼分析輔助方法、元數(shù)據(jù)輔助方法、工作負(fù)載-數(shù)據(jù)輔助方法以及動(dòng)態(tài)微服務(wù)組合方法.靜態(tài)代碼分析輔助方法從應(yīng)用程序的源代碼中派生出分解方案；元數(shù)據(jù)輔助方法［105]使用更抽象的輸入數(shù)據(jù)(例如UML圖)描述用例和接口；工作負(fù)載-數(shù)據(jù)輔助［106]方法通過度量應(yīng)用程序上模塊或功能級(jí)別的操作數(shù)據(jù)(例如通信、性能等)來確定合適的服務(wù)分解粒度；動(dòng)態(tài)微服務(wù)組合方法［107-109]通過描述微服務(wù)運(yùn)行時(shí)環(huán)境來解決服務(wù)分解問題.

在重構(gòu)決策上，Christoforou等人［110]給出了與微服務(wù)重構(gòu)相關(guān)的關(guān)鍵概念和驅(qū)動(dòng)因素，并提出一個(gè)決策支持系統(tǒng)以支持微服務(wù)重構(gòu)過程中的決策制定.

微服務(wù)的提取主要關(guān)注如何從單體應(yīng)用中提取出候選的微服務(wù).目前提出的方法大致可劃分為基于有向圖的方法、基于無向圖的方法以及基于機(jī)器學(xué)習(xí)的方法：

1) 在基于有向圖方法提取微服務(wù)上，Levcovitz等人［111]根據(jù)單體應(yīng)用中業(yè)務(wù)功能入口、業(yè)務(wù)功能和數(shù)據(jù)庫表構(gòu)建依賴關(guān)系圖，并根據(jù)圖中的依賴關(guān)系識(shí)別出候選微服務(wù).Chen等人［112]根據(jù)業(yè)務(wù)邏輯構(gòu)建并優(yōu)化數(shù)據(jù)流圖，并根據(jù)“操作+輸出數(shù)據(jù)”的描述風(fēng)格提取出候選微服務(wù).Ren等人［113]結(jié)合靜態(tài)和動(dòng)態(tài)分析來構(gòu)建單體應(yīng)用程序的功能調(diào)用圖，并利用功能之間的耦合程度以及功能聚類識(shí)別出候選微服務(wù).

2) 在基于無向圖方法提取微服務(wù)上，Gysel等人［114]提出了Service Cutter方法，旨在從域模型、用例等軟件工程構(gòu)件中提取出系統(tǒng)的耦合信息并表示為無向加權(quán)圖，并通過圖形聚類算法識(shí)別出微服務(wù).Mazlami等人［115]同樣使用了圖聚類算法來提取微服務(wù)，他們首先將3種形式化耦合策略嵌入到圖聚類算法中，隨后利用微服務(wù)提取模型和上述圖聚類算法對(duì)從系統(tǒng)代碼庫中構(gòu)造出的無向加權(quán)圖進(jìn)行處理，從而推薦候選微服務(wù).

3) 在基于機(jī)器學(xué)習(xí)方法提微服務(wù)上，Abdullah等人［116]提出了一種基于應(yīng)用程序訪問日志和非監(jiān)督機(jī)器學(xué)習(xí)的微服務(wù)分解方法，他們還提出了一種動(dòng)態(tài)選擇合適資源類型的方法，以提高重構(gòu)后微服務(wù)應(yīng)用程序的可擴(kuò)展性和整體性能.

此外，Escobar等人［117]評(píng)估了Enterprise Java Bean(EJB)之間的耦合性，從而對(duì)不同EJB進(jìn)行分離和分組，并將一個(gè)或若干個(gè)EJB映射為一個(gè)微服務(wù).Baresi等人［118]提出了一種基于OpenAPI接口規(guī)范的微服務(wù)劃分方案，能通過對(duì)單體應(yīng)用的接口進(jìn)行分析從而自動(dòng)識(shí)別出候選微服務(wù).Kecskemeti等人［119]還基于ENTICE項(xiàng)目的成果提出將單體應(yīng)用解耦成微服務(wù)的方法，并討論了相關(guān)技術(shù)的優(yōu)勢.

在與微服務(wù)重構(gòu)相關(guān)的實(shí)證和經(jīng)驗(yàn)研究上，已有研究致力于從工業(yè)界實(shí)踐中進(jìn)行學(xué)習(xí)、或者分享自身重構(gòu)經(jīng)驗(yàn).對(duì)于前者，Carrasco等人［63]通過對(duì)34篇學(xué)術(shù)論文以及24篇傳統(tǒng)學(xué)術(shù)出版發(fā)行渠道之外的灰色文獻(xiàn)進(jìn)行調(diào)研，總結(jié)了在微服務(wù)重構(gòu)過程中常見的9個(gè)陷阱.Francesco等人［101]進(jìn)行了一項(xiàng)微服務(wù)遷移實(shí)踐的實(shí)證研究，他們通過調(diào)查問卷總結(jié)了來自16家IT公司的18名從業(yè)者在逆向工程、架構(gòu)轉(zhuǎn)換和前向工程階段進(jìn)行的各項(xiàng)活動(dòng)(如對(duì)已有系統(tǒng)信息的研究、設(shè)計(jì)新架構(gòu)執(zhí)行的任務(wù)和如何開始遷移等)和遇到的各種挑戰(zhàn)(如原系統(tǒng)的高度耦合、服務(wù)界限的識(shí)別和基礎(chǔ)設(shè)施的設(shè)置).Taibi等人［102]調(diào)查了21名從業(yè)者并分析了他們遷移到微服務(wù)的動(dòng)機(jī)和遇到的困難，他們發(fā)現(xiàn)微服務(wù)的可擴(kuò)展性和可維護(hù)性是主要的動(dòng)機(jī)，而主要困難則在于將單體系統(tǒng)解耦成微服務(wù)、將遺留數(shù)據(jù)庫中的數(shù)據(jù)進(jìn)行遷移以及分割給各個(gè)服務(wù)等.Kalske等人［120]則對(duì)微服務(wù)軟件重構(gòu)相關(guān)的出版物和案例研究進(jìn)行了調(diào)研，以獲取公司進(jìn)行重構(gòu)的原因和這一過程中可能面臨的各類挑戰(zhàn).

而在分享自身重構(gòu)經(jīng)驗(yàn)上，F(xiàn)urda等人［100]研究并報(bào)告了將單體應(yīng)用程序遷移到微服務(wù)時(shí)在多租戶、有狀態(tài)和一致性這3個(gè)方面面臨的挑戰(zhàn).Balalaie等人［121]報(bào)告了將單體架構(gòu)遷移到微服務(wù)架構(gòu)的經(jīng)驗(yàn)，他們發(fā)現(xiàn)微服務(wù)架構(gòu)在提高可伸縮性和可用性的同時(shí)也引入了新的復(fù)雜性和困難.他們同時(shí)還研究了一些工業(yè)規(guī)模的軟件遷移項(xiàng)目，從中識(shí)別和收集了一組微服務(wù)重構(gòu)的設(shè)計(jì)模式［122]，并在一個(gè)現(xiàn)實(shí)案例中探討了如何使用DevOps來實(shí)現(xiàn)平穩(wěn)遷移［123].

此外，Zdun等人［124]還提出了一種對(duì)微服務(wù)重構(gòu)質(zhì)量進(jìn)行檢驗(yàn)的方法.該方法首先對(duì)重構(gòu)進(jìn)行建模，然后根據(jù)若干約束和度量來檢驗(yàn)微服務(wù)之間的依賴性，以及重構(gòu)后的微服務(wù)是否可以獨(dú)立部署、或者可以獨(dú)立部署到什么程度.

7 未來研究方向

面向微服務(wù)軟件開發(fā)作為一個(gè)新的技術(shù)發(fā)展趨勢，早已在注重實(shí)踐的工業(yè)界得到了廣泛的運(yùn)用，并派生出一系列成熟的開源工具和平臺(tái).但通過本文調(diào)研，我們發(fā)現(xiàn)目前學(xué)術(shù)界對(duì)于微服務(wù)開發(fā)的研究尚處于早期階段，尤其缺少在一流會(huì)議和期刊上發(fā)表的相關(guān)研究(例如CCF-A類).此外，我們也發(fā)現(xiàn)在面向微服務(wù)軟件開發(fā)方法的整體研究趨勢上，國內(nèi)相關(guān)研究的水平與國際前沿相比仍存在一定的差距.

在微服務(wù)軟件需求分析方面，目前相關(guān)研究通常是作為開發(fā)或者遷移特定應(yīng)用程序研究的一部分，并主要沿用傳統(tǒng)的軟件工程需求分析方法［20-22,24]；而不同微服務(wù)軟件在非功能需求上往往會(huì)存在很多共性特征［20,24-25].因此，在微服務(wù)軟件需求分析上，一方面我們需要針對(duì)微服務(wù)的特點(diǎn)來研究更加快速、靈活和精確的需求分析方法，并開發(fā)相應(yīng)的需求分析工具，提高需求分析的效率、可伸縮性和正確性；同時(shí)還需要綜合考慮微服務(wù)設(shè)計(jì)、測試等若干后續(xù)開發(fā)階段，使得需求的變化能夠快速反饋到其他階段，而其他階段的結(jié)果也能夠在需求上及時(shí)驗(yàn)證.另一方面，在非功能需求分析上也需要對(duì)不同領(lǐng)域、特征的微服務(wù)軟件進(jìn)行更加系統(tǒng)全面的總結(jié)，制定相應(yīng)的實(shí)踐標(biāo)準(zhǔn)，為研究者提供規(guī)范的參考.

在微服務(wù)軟件設(shè)計(jì)與實(shí)現(xiàn)方面，在工業(yè)界人們已開發(fā)了很多微服務(wù)框架(如Spring Cloud等)和開源解決方案(如Netflix開源組件、服務(wù)網(wǎng)格Istio、Docker等)，并得到了廣泛的應(yīng)用.雖然學(xué)術(shù)界也提出了很多面向微服務(wù)設(shè)計(jì)與實(shí)現(xiàn)的工具，但這些工具在功能和性能上能否滿足實(shí)踐中大規(guī)模系統(tǒng)開發(fā)的需求仍需要進(jìn)一步的驗(yàn)證.此外，微服務(wù)軟件設(shè)計(jì)過程中存在的眾多影響因素也為整體設(shè)計(jì)質(zhì)量的控制帶來了困難［32].因此，在微服務(wù)軟件設(shè)計(jì)與實(shí)現(xiàn)上，一方面我們需要全面了解已有的工業(yè)界實(shí)踐方式，在此基礎(chǔ)上分析當(dāng)前仍存在的問題和挑戰(zhàn)；同時(shí)，進(jìn)一步推廣學(xué)術(shù)界的最新研究成果，使這些研究成果的有效性能得到充分的驗(yàn)證.另一方面，我們還需要研究微服務(wù)軟件設(shè)計(jì)的質(zhì)量評(píng)估方法，從而對(duì)相應(yīng)設(shè)計(jì)結(jié)果的整體質(zhì)量進(jìn)行評(píng)估，更好地協(xié)助開發(fā)人員解決設(shè)計(jì)與實(shí)現(xiàn)上的決策問題.

在微服務(wù)測試方面，目前研究在組件測試、端到端測試、回歸測試、驗(yàn)收測試、變異測試和軟件調(diào)試等方面進(jìn)行了一定程度的探索，但仍缺乏專門針對(duì)微服務(wù)內(nèi)部邏輯進(jìn)行測試的方法.此外，現(xiàn)有研究主要關(guān)注自動(dòng)化測試框架的構(gòu)建，缺乏對(duì)于面向微服務(wù)的測試建模、測試用例生成、測試預(yù)期輸出判定以及故障定位等各個(gè)階段的深入研究.因此，在微服務(wù)測試上，一方面我們需要持續(xù)研究如何將傳統(tǒng)測試技術(shù)引入到微服務(wù)測試中，通過對(duì)已有測試技術(shù)的改進(jìn)和優(yōu)化來進(jìn)一步提高微服務(wù)測試的有效性，并研究新的測試覆蓋標(biāo)準(zhǔn)，確保測試的準(zhǔn)確、快速和全面.另一方面我們也需要在微服務(wù)測試的測試建模、測試用例生成、測試預(yù)期輸出判定以及故障定位等各個(gè)階段開發(fā)相應(yīng)的自動(dòng)化測試方法和工具，形成系統(tǒng)的微服務(wù)測試方法體系.

在微服務(wù)重構(gòu)方面，目前研究數(shù)量相對(duì)較多，其中研究者不僅在重構(gòu)流程和方法上進(jìn)行了探索，還提出了很多將單體應(yīng)用遷移為微服務(wù)的方法，并開展了一批實(shí)證研究.但是，已有的重構(gòu)方法是否適用于現(xiàn)實(shí)中的大規(guī)模系統(tǒng)也仍需進(jìn)一步的驗(yàn)證.同時(shí)，在不同重構(gòu)方法的比較和評(píng)估上也需要開展更多的經(jīng)驗(yàn)研究，并在此基礎(chǔ)上提取出適用于不同重構(gòu)場景的標(biāo)準(zhǔn)化、規(guī)范化方法.

8 總 結(jié)

面向微服務(wù)軟件開發(fā)是近年來軟件工程領(lǐng)域研究的前沿和熱點(diǎn)話題.為了了解該領(lǐng)域的當(dāng)前研究進(jìn)展，本文首先收集了目前與微服務(wù)軟件開發(fā)相關(guān)的91篇研究論文，隨后從需求分析、設(shè)計(jì)與實(shí)現(xiàn)、測試以及重構(gòu)的角度對(duì)已有的方法、工具和實(shí)踐進(jìn)行了分析和總結(jié)，并對(duì)微服務(wù)軟件開發(fā)可能的一些研究方向進(jìn)行了討論.

經(jīng)過不足10年的發(fā)展，微服務(wù)在工業(yè)實(shí)踐中已經(jīng)取得了廣泛且豐富的應(yīng)用，但學(xué)術(shù)界對(duì)于微服務(wù)開發(fā)的研究尚處于早期階段，與實(shí)踐應(yīng)用之間仍存在著很大鴻溝.作為面向服務(wù)體系結(jié)構(gòu)的最新研究和發(fā)展趨勢，微服務(wù)在未來具有良好的研究和應(yīng)用前景.本文希望能為相關(guān)研究者和開發(fā)團(tuán)隊(duì)提供參考和借鑒，以進(jìn)一步提高微服務(wù)軟件開發(fā)的效率和質(zhì)量.