吳化堯 鄧文俊

(計算機軟件新技術國家重點實驗室(南京大學) 南京 210023)(hywu@nju.edu.cn)

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

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

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

1 背 景

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

1.1 面向服務架構

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

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

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

1.2 微服務架構

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

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

1.3 微服務架構與SOA的主要區(qū)別

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

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

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

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

2 文獻收集和匯總

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

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

Table 1 Keywords of Literature Search表1 論文檢索關鍵詞

對于檢索到的文獻，我們首先閱讀標題、摘要和結論，并應用下述包含和排除標準來進行第1輪篩選.具體地，我們將符合全部3個條件的文獻考慮在內(包含標準)：

1) 關注微服務軟件開發(fā)周期(需求分析、設計與實現(xiàn)、測試、重構)的一個或多個階段.

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

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

并將符合2個條件中的任一條件的文獻排除在外(排除標準)：

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

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

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

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

3 面向微服務的軟件需求分析

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

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

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

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

4 面向微服務的軟件設計與實現(xiàn)

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

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

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

Table 3 Design Domain of Microservice Software表3 微服務軟件設計領域

4.1 系統(tǒng)設計

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

1) 接口

微服務接口設計需要考慮如何設計微服務之間進行通信的接口，包括采用何種通信機制、提供什么樣的接口形式等.

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

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

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

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

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

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

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

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

3) 模塊化

模塊化的核心是如何劃分微服務，其中的一個重要問題是微服務粒度的確定.SOA中服務的規(guī)?？梢蕴幱谛⌒蛻贸绦虻酱笮推髽I(yè)級系統(tǒng)之間［76]，而微服務則通常是小型、細粒度的服務.

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

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

② DDD不是一個形式化的建模語言，這在一定程度上阻礙了模型的驗證和轉換.針對這一問題，Rademacher等人［42]使用UML配置文件來輔助領域驅動的微服務建模，其不僅為DDD提供原型和約束，還支持將結構化領域模型表示為UML類圖，解決了模型的驗證和轉換問題.

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

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

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

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

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

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

5) 服務組合

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

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

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

6) 容錯

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

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

7) 安全

目前與微服務安全相關的設計主要關注外部對于系統(tǒng)訪問的安全性以及系統(tǒng)內部微服務之間相互調用的安全性.

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

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

8) 負載均衡

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

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

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

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

微服務監(jiān)控的主要目的是在系統(tǒng)運行時對基礎設施、微服務等的性能進行觀察，而日志則用于在微服務等發(fā)生故障后快速排除錯誤.目前這一設計領域關注微服務監(jiān)控的整體設計，監(jiān)控指標的設計以及對應監(jiān)控數(shù)據(jù)或日志的收集和分析.

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

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

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

4.2 組織架構和流程

微服務組織架構和流程關注微服務軟件開發(fā)團隊的組織模式，以及開發(fā)和部署微服務的流程.

1) 開發(fā)團隊組織

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

2) 部署

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

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

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

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

3) DevOps

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

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

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

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

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

5 面向微服務的軟件測試

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

我們共收集到16篇與微服務測試相關的文獻，按研究內容可分為組件測試、端到端測試、回歸測試、驗收測試、變異測試和微服務調試.

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

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

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

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

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

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

6 面向微服務的重構

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

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

2) 將數(shù)據(jù)庫有效拆分和分配給對應的微服務，同時保持數(shù)據(jù)一致性的復雜性；

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

目前，與面向微服務重構相關的研究主要集中在重構的流程、方法和決策，微服務的提取，以及相關的實證和經(jīng)驗研究.

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

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

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

微服務的提取主要關注如何從單體應用中提取出候選的微服務.目前提出的方法大致可劃分為基于有向圖的方法、基于無向圖的方法以及基于機器學習的方法：

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

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

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

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

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

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

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

7 未來研究方向

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

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

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

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

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

8 總 結

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

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