代 飛，劉國志，李 章，莫 啟，李 彤

1.西南林業(yè)大學(xué)大數(shù)據(jù)與智能工程學(xué)院，昆明650224

2.云南林業(yè)職業(yè)技術(shù)學(xué)院繼續(xù)教育與國際交流學(xué)院，昆明650224

3.云南大學(xué)軟件學(xué)院，昆明650091

4.云南農(nóng)業(yè)大學(xué)大數(shù)據(jù)學(xué)院，昆明650201

2014年，F(xiàn)owler 和Lewis 正式提出了微服務(wù)的概念[1].微服務(wù)是一種新型的架構(gòu)風(fēng)格，它提倡將應(yīng)用程序劃分為一組細(xì)粒度的服務(wù)，服務(wù)間采用輕量級(jí)的通信機(jī)制進(jìn)行交互，從而為用戶提供最終價(jià)值[2].通常，這些細(xì)粒度的微服務(wù)是具有單一職責(zé)的小程序，能夠被獨(dú)立地部署、擴(kuò)展和測(cè)試[3-4].

與傳統(tǒng)單體架構(gòu)（monolithic architecture）相比，微服務(wù)架構(gòu)（microservice architecture）具有高維護(hù)性、高擴(kuò)展性、高適應(yīng)性、去中心化管理、容器化的運(yùn)行環(huán)境等特征，受到了工業(yè)界和學(xué)術(shù)界的大量關(guān)注[5-8]并將微服務(wù)技術(shù)視為云計(jì)算的有效補(bǔ)充[9].

由于微服務(wù)架構(gòu)能滿足大規(guī)模分布式應(yīng)用期望的可擴(kuò)展性、可演化性和可維護(hù)性等需求，近年來越來越多的云應(yīng)用向微服務(wù)架構(gòu)遷移[5,10].在國外，Amazon、Netflix、The Guardian、Twitter、PayPal、SoundCloud 等最早開始嘗試將云上的軟件系統(tǒng)微服務(wù)化.在國內(nèi)，騰訊、百度、京東、淘寶、360 搜索等也陸續(xù)開始將軟件系統(tǒng)向微服務(wù)架構(gòu)遷移.例如，騰訊的微信系統(tǒng)[6]包含3 000 多個(gè)微服務(wù)，分布式地運(yùn)行20 000 多個(gè)機(jī)器上[11].Netflix 的在線服務(wù)系統(tǒng)使用了大約500 個(gè)微服務(wù)，每天涉及50 億個(gè)服務(wù)交互[12].Amazon 每個(gè)頁面涉及100～150 個(gè)微服務(wù)的調(diào)用[13].根據(jù)國際數(shù)據(jù)公司預(yù)測(cè)：到2021年，云平臺(tái)上80%的應(yīng)用程序?qū)⑹褂梦⒎?wù)技術(shù)開發(fā)[14].

本質(zhì)上，微服務(wù)的服務(wù)化思想源于面向服務(wù)架構(gòu)（service oriented architecture,SOA）[14]，但與SOA 相比，微服務(wù)存在以下顯著不同的3 個(gè)方面：

1）從設(shè)計(jì)哲學(xué)的角度，SOA 的設(shè)計(jì)哲學(xué)是share-as-much-as-you-can，目的是促進(jìn)松散耦合服務(wù)的高度復(fù)用[15]；而微服務(wù)是share-nothing驅(qū)動(dòng)的，目的是促進(jìn)緊耦合代碼的進(jìn)一步分離和自治，支持敏捷方法或DevOps 方法[2,16-17].

2）從通信方式的角度，SOA 架構(gòu)下服務(wù)間通過企業(yè)服務(wù)總線（ESB）進(jìn)行通信[15]；而服務(wù)架構(gòu)下微服務(wù)間通過RESTful 或基于RPC 的API 等輕量級(jí)協(xié)議進(jìn)行通信[2,18].

3）從數(shù)據(jù)共享的角度，SOA 架構(gòu)下服務(wù)間共享同一數(shù)據(jù)庫；而微服務(wù)架構(gòu)下每個(gè)微服務(wù)可以擁有自己私有的數(shù)據(jù)庫[2,19].

目前，許多學(xué)者已發(fā)表了微服務(wù)相關(guān)的研究成果.文獻(xiàn)[20]從論文發(fā)表趨勢(shì)、研究重點(diǎn)和產(chǎn)業(yè)應(yīng)用潛力三個(gè)角度，對(duì)微服務(wù)體系結(jié)構(gòu)的研究現(xiàn)狀進(jìn)行了識(shí)別、分類和評(píng)價(jià).文獻(xiàn)[9]基于2014年和2015年的研究成果，對(duì)微服務(wù)研究進(jìn)行了系統(tǒng)地分類和比較.文獻(xiàn)[21]對(duì)微服務(wù)系統(tǒng)中使用的安全機(jī)制進(jìn)行了系統(tǒng)地識(shí)別、分類和評(píng)價(jià).文獻(xiàn)[22]總結(jié)了物聯(lián)網(wǎng)應(yīng)用開發(fā)中采用微服務(wù)的現(xiàn)狀和未來研究趨勢(shì).與這些文獻(xiàn)相比，本文采用系統(tǒng)評(píng)價(jià)（systematic review）的方法，對(duì)微服務(wù)技術(shù)最近五年的主要研究進(jìn)行了搜集、分析和概況，以期系統(tǒng)了解微服務(wù)在體系結(jié)構(gòu)、通信和挑戰(zhàn)三個(gè)方面的研究現(xiàn)狀和最新進(jìn)展.

1 研究方法

本文采用系統(tǒng)評(píng)價(jià)方法對(duì)微服務(wù)的體系結(jié)構(gòu)、通信和挑戰(zhàn)進(jìn)行綜述，具體步驟如下：

步驟1研究問題.通過系統(tǒng)評(píng)價(jià)，本文嘗試回答下述3 個(gè)問題：

1）單體架構(gòu)、SOA 架構(gòu)和微服務(wù)結(jié)構(gòu)的主要區(qū)別；

2）微服務(wù)間的通信研究主要集中在什么方面；

3）微服務(wù)技術(shù)面臨的挑戰(zhàn).

步驟2文獻(xiàn)搜索.本文使用關(guān)鍵詞"microservices" AND ("architecture" OR "communication" OR "challenges")在IEEE Xplore 搜索發(fā)表時(shí)間為2015年及以后的論文，共有745項(xiàng)記錄.

步驟3選取標(biāo)準(zhǔn).對(duì)于745 項(xiàng)記錄，本文的選取標(biāo)準(zhǔn)是查看論文的題目、摘要和正文是否與系統(tǒng)評(píng)價(jià)的三個(gè)問題相關(guān).首先，根據(jù)題目和摘要，檢測(cè)每項(xiàng)記錄是否與問題相關(guān)，但這種方式會(huì)選取大量不相關(guān)的記錄.其次，對(duì)選取的記錄采用人工方式進(jìn)一步查看其正文是否與問題相關(guān).最后，本文用“滾雪球”過程審查每個(gè)選取研究的參考文獻(xiàn)，并將這一過程中獲得的文獻(xiàn)與前一步選擇的文獻(xiàn)相結(jié)合.

最終選取了49 篇論文，其中會(huì)議論文26 篇，期刊論文23 篇，分別如表1和2 所示.圖1給出了選取會(huì)議論文2015–2019年的年份分布情況.圖2為選取期刊論文2015–2020年的年份分布情況.

步驟4數(shù)據(jù)提取和分析.針對(duì)第一步提出的三個(gè)問題，本文對(duì)入選的49 篇論文進(jìn)行了分類、分析和歸納總結(jié).

步驟5完成報(bào)告.圍繞三個(gè)問題，本文第2～4 節(jié)將分別給出系統(tǒng)評(píng)價(jià)的分析結(jié)果.

表1 會(huì)議論文列表Table 1 List of conference papers

表2 期刊論文列表Table 2 List of journal papers

圖1 歷年會(huì)議論文分布情況Figure 1 Distribution of conference papers over the years

圖2 歷年期刊論文分布情況Figure 2 Distribution of journal papers over the years

2 體系結(jié)構(gòu)

近年來，行業(yè)需求推動(dòng)了軟件體系架構(gòu)的不斷發(fā)展.軟件領(lǐng)域出現(xiàn)了公共對(duì)象請(qǐng)求代理體系結(jié)構(gòu)（CORBA）[23]、基于構(gòu)件的軟件工程（CBSE）[24]、單體架構(gòu)[25]等體系結(jié)構(gòu).為了解耦服務(wù)端應(yīng)用并提高組件的復(fù)用，20世紀(jì)90年代提出的SOA 作為一項(xiàng)革命性的創(chuàng)新成果，已成為大型企業(yè)實(shí)現(xiàn)跨行業(yè)需求的解決方案[15,26].隨后，SOA 在21世紀(jì)初得到了廣泛應(yīng)用[27].近年來，微服務(wù)架構(gòu)呈取代單體架構(gòu)和SOA 之勢(shì)，逐步成為主流的體系結(jié)構(gòu)[28].

圖3直觀描述了體系結(jié)構(gòu)的演化，從最初傳統(tǒng)的單體架構(gòu)到SOA，再到微服務(wù)架構(gòu).

在圖3(a)中，單體架構(gòu)將服務(wù)端應(yīng)用視為一個(gè)整體應(yīng)用層[29].其處理流程是前端用戶接口將用戶發(fā)送的請(qǐng)求重定向到服務(wù)端應(yīng)用，而服務(wù)端應(yīng)用通過與數(shù)據(jù)庫的交互處理請(qǐng)求.

在圖3(b)中，SOA 將服務(wù)端應(yīng)用視為多個(gè)粗粒度服務(wù)的組合，每個(gè)服務(wù)可托管在地理位置不同的容器中運(yùn)行[15].服務(wù)間通過企業(yè)服務(wù)總線進(jìn)行通信組合并共享同一個(gè)數(shù)據(jù)庫.

圖3 軟件架構(gòu)的演化Figure 3 Evolution of software architectures

在圖3(c)中，微服務(wù)架構(gòu)將服務(wù)端應(yīng)用視為多個(gè)細(xì)粒度微服務(wù)的組合，微服務(wù)間通過輕量級(jí)協(xié)議進(jìn)行通信[2,18].每個(gè)微服務(wù)是高內(nèi)聚的小程序，可擁有自己私有的數(shù)據(jù)庫并在其獨(dú)立的容器中運(yùn)行[30].

由于微服務(wù)架構(gòu)還沒有正式的形式定義[1]，本文以代碼為核心，從組件化、部署和擴(kuò)展、數(shù)據(jù)存儲(chǔ)、開發(fā)等4 個(gè)方面，對(duì)單體架構(gòu)、SOA 和微服務(wù)架構(gòu)進(jìn)行系統(tǒng)對(duì)比.首先從代碼解耦的角度，對(duì)比3 種架構(gòu)的組件化；接著從代碼運(yùn)行的角度，對(duì)比3 種架構(gòu)的部署和擴(kuò)展；然后從數(shù)據(jù)管理的角度，對(duì)比與代碼交互的數(shù)據(jù)存儲(chǔ)方式；最后從代碼開發(fā)的角度，對(duì)比3 種架構(gòu)的優(yōu)缺點(diǎn).

2.1 組件化

組件化是構(gòu)建現(xiàn)代Web 和云應(yīng)用的關(guān)鍵基礎(chǔ)之一[10].圖4直觀地描述了組件化的演化，從單體架構(gòu)的模塊到SOA 的服務(wù)，再到微服務(wù)架構(gòu)的微服務(wù).

單體架構(gòu)的組件化是通過模塊來實(shí)現(xiàn)的.單體架構(gòu)將軟件系統(tǒng)劃分為不同的模塊，如前端UI（用戶界面）、服務(wù)端邏輯組件和數(shù)據(jù)庫[31]，但各模塊無法單獨(dú)執(zhí)行[18].前端UI 在用戶設(shè)備上運(yùn)行，服務(wù)器端邏輯組件在服務(wù)器上或云中運(yùn)行，后端數(shù)據(jù)庫存儲(chǔ)應(yīng)用程序的數(shù)據(jù).

SOA 的組件化是通過粗粒度的服務(wù)來實(shí)現(xiàn)的.SOA 是一種實(shí)現(xiàn)關(guān)注點(diǎn)分離的體系結(jié)構(gòu)，由不同的服務(wù)提供軟件系統(tǒng)的功能，在企業(yè)服務(wù)總線的集中化管理下，服務(wù)間通過響應(yīng)事件進(jìn)行集成[32].相比單體架構(gòu)下的模塊，這些服務(wù)粒度可以單獨(dú)運(yùn)行，具有自治、自描述、可重用和高度可移植等特征[33].此外，SOA 還關(guān)注簡單服務(wù)和智能路由機(jī)制[25]，這種智能路由機(jī)制的核心是中心化的管理.

微服務(wù)架構(gòu)的組件化是通過高度解耦的細(xì)粒度微服務(wù)來實(shí)現(xiàn)的.為了進(jìn)一步解耦服務(wù)端應(yīng)用，微服務(wù)架構(gòu)將軟件系統(tǒng)高度解耦為微服務(wù)，微服務(wù)間通過輕量級(jí)的協(xié)議進(jìn)行通信[10].與SOA 的服務(wù)相比，這些微服務(wù)粒度更小且專注于完成一個(gè)小任務(wù)[2,4].此外，微服務(wù)架構(gòu)還關(guān)注智能服務(wù)和簡單路由機(jī)制，反對(duì)SOA 中的集中化管理[2].

圖4 組件化的演化Figure 4 Evolution of componentization

2.2 部署和擴(kuò)展

圖5直觀地展示了單體系統(tǒng)和微服務(wù)系統(tǒng)的部署和擴(kuò)展區(qū)別.單體架構(gòu)要求對(duì)軟件系統(tǒng)進(jìn)行整體部署和擴(kuò)展，如圖5(a)所示.隨著越來越多的單體系統(tǒng)部署到云端，這種整體部署和擴(kuò)展的方式嚴(yán)重制約了單體系統(tǒng)的應(yīng)用.從部署角度來看，對(duì)單體系統(tǒng)的任意修改都需要對(duì)系統(tǒng)進(jìn)行整體重建和部署；從擴(kuò)展角度來看，對(duì)單體系統(tǒng)只能進(jìn)行整體擴(kuò)展，無法實(shí)現(xiàn)部分?jǐn)U展.

與單體架構(gòu)相比，微服務(wù)架構(gòu)支持每個(gè)微服務(wù)進(jìn)行獨(dú)立部署和擴(kuò)展，因此對(duì)微服務(wù)系統(tǒng)的部署和擴(kuò)展是以單個(gè)微服務(wù)為單位的，如圖5(b)所示.從部署角度，對(duì)單個(gè)微服務(wù)的修改只涉及該服務(wù)的部署；從擴(kuò)展角度，可根據(jù)實(shí)際需求動(dòng)態(tài)擴(kuò)展某個(gè)微服務(wù)的實(shí)例.

圖5 單體系統(tǒng)和微服務(wù)系統(tǒng)的部署和擴(kuò)展Figure 5 Deployment and scalability of monoliths and microservices

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

單體架構(gòu)和SOA 中都采用中心化的數(shù)據(jù)管理，即數(shù)據(jù)統(tǒng)一存儲(chǔ)在一個(gè)中心數(shù)據(jù)庫.這種集中式數(shù)據(jù)管理將使得技術(shù)平臺(tái)趨于標(biāo)準(zhǔn)化和趨勢(shì)化[1].

與單體架構(gòu)和SOA 相比，微服務(wù)架構(gòu)采用分布式數(shù)據(jù)管理，其概念模型和存儲(chǔ)后端都是分布式的.具體而言，分布式的概念模型是指不同的微服務(wù)對(duì)同一世界有不同概念模型，如通過對(duì)相同實(shí)體的不同屬性進(jìn)行操作；分布式的存儲(chǔ)后端是指每個(gè)服務(wù)都有自己獨(dú)立的存儲(chǔ)數(shù)據(jù)庫，該數(shù)據(jù)庫與其他服務(wù)的數(shù)據(jù)庫是隔離的[10].與中心化的數(shù)據(jù)管理相比，這種分布式（去中心化）的數(shù)據(jù)管理有利于清晰定義每個(gè)微服務(wù)的限界上下文（bounded context），從而進(jìn)一步降低微服務(wù)間的耦合度.

由于微服務(wù)系統(tǒng)中事務(wù)可以跨越多個(gè)微服務(wù)的數(shù)據(jù)庫，因此傳統(tǒng)解決單個(gè)數(shù)據(jù)庫中事務(wù)一致性的ACID 方法不再適用于微服務(wù)系統(tǒng).在這種情況下，當(dāng)微服務(wù)系統(tǒng)出現(xiàn)失敗事務(wù)時(shí)，如何補(bǔ)償已經(jīng)執(zhí)行事務(wù)以確保數(shù)據(jù)的一致性是具有挑戰(zhàn)性的.

2.4 開發(fā)

2.4.1 單體架構(gòu)的優(yōu)點(diǎn)和不足

單體架構(gòu)具有如下優(yōu)點(diǎn)：

1）開發(fā)與部署簡單

單體系統(tǒng)的開發(fā)不僅集成工具較多且在同一個(gè)目錄下執(zhí)行.這種方式有利于簡化開發(fā)和部署.

2）減少交叉關(guān)注

多數(shù)應(yīng)用程序都依賴于大量交叉關(guān)注點(diǎn)，如審計(jì)跟蹤、日志記錄等.由于單體系統(tǒng)的代碼基礎(chǔ)單一且作為一個(gè)整體在容器中運(yùn)行，因此系統(tǒng)交叉關(guān)注將大量減少.

3）性能更好

相比SOA 架構(gòu)和微服務(wù)架構(gòu)，單體架構(gòu)因基于內(nèi)存共享代碼和數(shù)據(jù)而具有更好的性能.

然而，當(dāng)外部環(huán)境或業(yè)務(wù)需求發(fā)生變化時(shí)，單體架構(gòu)將不可避免地面臨以下不足：

1）依賴地獄[34]

單體系統(tǒng)常常遭受“依賴地獄”的困擾.在單體系統(tǒng)中，添加或更新庫會(huì)導(dǎo)致系統(tǒng)無法編譯、運(yùn)行，甚至出現(xiàn)不一致的行為.這種高度的依賴性使單體系統(tǒng)的維護(hù)和演化很難實(shí)施.

2）局部修改、整體重啟

對(duì)單體系統(tǒng)中任何模塊的任何更改都需要重新啟動(dòng)整個(gè)軟件系統(tǒng).對(duì)于大型項(xiàng)目，重啟所需的停機(jī)時(shí)間較長.因此這種局部修改、整體重啟的方式往往阻礙項(xiàng)目的開發(fā)、測(cè)試和維護(hù).

3）技術(shù)鎖定

單體架構(gòu)要求開發(fā)人員使用開發(fā)原系統(tǒng)的語言和框架即技術(shù)鎖定，難以使用新的技術(shù).

4）持續(xù)交付差

技術(shù)限制和可擴(kuò)展性問題導(dǎo)致單體系統(tǒng)難以持續(xù)交付，因此單體系統(tǒng)往往無法滿足快速涌現(xiàn)的業(yè)務(wù)需求[32].

2.4.2 SOA 的優(yōu)點(diǎn)和不足

SOA 是一種將孤立的軟件應(yīng)用程序和基礎(chǔ)設(shè)施重組為一組相互連接的服務(wù)集的方式，服務(wù)間通過標(biāo)準(zhǔn)接口和消息傳遞進(jìn)行通信[27].通常，SOA 具有下述優(yōu)點(diǎn)：

1）模塊化和重用[18]

復(fù)雜服務(wù)由簡單服務(wù)組合而成；同一服務(wù)可以被不同的軟件系統(tǒng)復(fù)用.

2）支持分布式開發(fā)[18]

通過遵循共同的接口標(biāo)準(zhǔn)，不同的開發(fā)團(tuán)隊(duì)可以并行地開發(fā)軟件系統(tǒng)的不同部分.

3）集成異構(gòu)和遺留系統(tǒng)[18]

SOA 使用開放的互聯(lián)網(wǎng)標(biāo)準(zhǔn)，如簡單對(duì)象訪問協(xié)議（SOAP）、Web 服務(wù)描述語言（WSDL）、Web 服務(wù)業(yè)務(wù)流程執(zhí)行語言（BPEL4WS）.在企業(yè)服務(wù)總線的支持下，SOA 采用標(biāo)準(zhǔn)化的方式對(duì)異構(gòu)和遺留系統(tǒng)進(jìn)行服務(wù)化的集成.

SOA 具有下述不足：

1）整體部署[32]

SOA 支持在業(yè)務(wù)流程級(jí)別上集成各種服務(wù).這種方式雖然帶來了集成的靈活性，但同時(shí)也將所有服務(wù)綁定到單個(gè)流程上下文中，進(jìn)而導(dǎo)致整體部署[35].

2）受限的獨(dú)立性[32]

SOA 主張代碼間的解耦，但在實(shí)際應(yīng)用中SOA 中的服務(wù)大多依賴于某些中間件或框架，這在一定程度上損害了服務(wù)的獨(dú)立性.

2.4.3 微服務(wù)架構(gòu)的優(yōu)點(diǎn)和不足

微服務(wù)架構(gòu)是SOA 的第二次迭代，其目的是去除SOA 中不必要的復(fù)雜程度，以便專注于實(shí)現(xiàn)單一功能的細(xì)粒度服務(wù)[15,18].通常，微服務(wù)架構(gòu)具有下述優(yōu)點(diǎn)：

1）高擴(kuò)展性[32].

每個(gè)微服務(wù)獨(dú)立開發(fā)、部署、維護(hù)，因而微服務(wù)系統(tǒng)具有高擴(kuò)展性.高擴(kuò)展性是指可根據(jù)負(fù)載需求，靈活擴(kuò)展某個(gè)微服務(wù)的實(shí)例，而非整個(gè)微服務(wù)系統(tǒng)[18,36].同時(shí)，高擴(kuò)展性能更好地支持資源動(dòng)態(tài)分配[37].

2）高維護(hù)性[4]

微服務(wù)的小規(guī)模有助于提高代碼的可理解性和可維護(hù)性[30].更改某個(gè)微服務(wù)只需重啟運(yùn)行該微服務(wù)的容器，而非重啟整個(gè)微服務(wù)系統(tǒng).因此微服務(wù)系統(tǒng)易于維護(hù)和升級(jí).

3）高彈性[4]

微服務(wù)系統(tǒng)的某個(gè)微服務(wù)出現(xiàn)故障，不會(huì)影響整個(gè)系統(tǒng).

4）低依賴性[9]

由于每個(gè)微服務(wù)具有限界的上下文且獨(dú)立地實(shí)現(xiàn)和部署，微服務(wù)系統(tǒng)能消除各種依賴性問題，減少錯(cuò)誤級(jí)聯(lián).

5）有效支撐DevOps[2]

每個(gè)微服務(wù)可以由不同的小團(tuán)隊(duì)開發(fā)，這有利于DevOps 方法的有效實(shí)施[38].

6）技術(shù)異構(gòu)性[18]

每個(gè)微服務(wù)使用不同的編程語言和數(shù)據(jù)存儲(chǔ)，允許技術(shù)異構(gòu)性.

與此同時(shí)，微服務(wù)架構(gòu)也帶來了很多復(fù)雜性：

1）復(fù)雜的開發(fā)

微服務(wù)系統(tǒng)本質(zhì)上是并發(fā)分布式系統(tǒng)，而開發(fā)并發(fā)分布式系統(tǒng)本身就是很復(fù)雜的.

2）復(fù)雜的通信拓?fù)鋄39]

微服務(wù)系統(tǒng)通常包含成百上千個(gè)微服務(wù)，微服務(wù)間的交互所形成的拓?fù)浣Y(jié)構(gòu)是非常復(fù)雜的.

3）復(fù)雜的故障診斷

有效檢測(cè)微服務(wù)的故障是確保微服務(wù)系統(tǒng)正常運(yùn)行的關(guān)鍵.但準(zhǔn)確定位微服務(wù)的故障是困難的：一是微服務(wù)通常會(huì)有多個(gè)運(yùn)行實(shí)例，難以準(zhǔn)確定位是哪個(gè)運(yùn)行實(shí)例出現(xiàn)了故障；二是一個(gè)請(qǐng)求通常涉及多個(gè)微服務(wù)間的交互和通信，難以準(zhǔn)確定位哪個(gè)交互出現(xiàn)了故障[40].

基于上述分析和概括，對(duì)單體架構(gòu)、SOA 和微服務(wù)架構(gòu)進(jìn)行比較如表3所示.

表3 單體架構(gòu)、SOA 和微服務(wù)架構(gòu)的比較Table 3 Comparison of monoliths,SOA and microservices

3 通 信

軟件系統(tǒng)從單體架構(gòu)演化到微服務(wù)架構(gòu)，最大的改變?cè)谟谕ㄐ欧绞?在單體架構(gòu)中，軟件系統(tǒng)運(yùn)行在單個(gè)進(jìn)程上.在單機(jī)環(huán)境下，組件間使用內(nèi)存函數(shù)調(diào)用的方式進(jìn)行交互和通信.在微服務(wù)架構(gòu)中，軟件系統(tǒng)的運(yùn)行環(huán)境由單機(jī)環(huán)境改變?yōu)榉植际江h(huán)境.在分布式環(huán)境下，微服務(wù)間通過服務(wù)接口進(jìn)行交互和通信[41].與基于內(nèi)存函數(shù)調(diào)用的交互相比，這種交互本質(zhì)上是進(jìn)程間的通信[42].

根據(jù)交互模式，微服務(wù)間的通信可分為同步通信和異步通信[41].同步通信是一種阻塞通信模式：一個(gè)微服務(wù)發(fā)送者向另一個(gè)微服務(wù)接收者發(fā)送請(qǐng)求，并等待該接收者響應(yīng)[43].異步通信是一種非阻塞通信模式：一個(gè)微服務(wù)發(fā)送者向另一個(gè)微服務(wù)接收者發(fā)送請(qǐng)求，并不等待該接收者的響應(yīng)[44].

在微服務(wù)系統(tǒng)中，由于同步通信容易引起停機(jī)倍增效應(yīng)，所以微服務(wù)間的交互大多以異步通信為主[39].因此本節(jié)重點(diǎn)關(guān)注異步通信.

3.1 異步通信模型

盡管同步通信能為用戶提供及時(shí)響應(yīng)，但異步通信能為微服務(wù)系統(tǒng)提供最大的彈性和可擴(kuò)展性.具體而言，異步通信模型可分為基于消息隊(duì)列（message queuing）的異步通信模型和發(fā)布訂閱（publish subscribe）式異步通信模型[45].

3.1.1 基于消息隊(duì)列的異步通信模型

消息隊(duì)列在異步通信中起著重要的通信通道作用，通常被稱為面向消息的中間件[46].在基于消息隊(duì)列的異步通信模型中，消息被持久化在隊(duì)列中.一個(gè)或多個(gè)消息接收者可以消耗隊(duì)列中的消息，但特定消息最多只能被一個(gè)消息接收者所消耗.消息按先進(jìn)先出的方式進(jìn)出隊(duì)列.一旦消息接收者從隊(duì)列中消耗了消息，則該消息就從隊(duì)列中消失.

基于消息隊(duì)列的異步通信模型可進(jìn)一步劃分為郵箱式異步通信模型[47]和點(diǎn)對(duì)點(diǎn)式異步通信模型[48]，如圖6所示.

在圖6(a)中，郵箱式異步通信模型要求所有發(fā)送給微服務(wù)3的消息（微服務(wù)1和微服務(wù)2生成的消息）存儲(chǔ)在隊(duì)列3中的末尾，而微服務(wù)3從隊(duì)列3 的頭部取出需要消耗的消息.這種通過隊(duì)列緩存消息的方式稱為先進(jìn)先出式[47-48].

在圖6(b)中，點(diǎn)對(duì)點(diǎn)式異步通信模型要求從微服務(wù)1 發(fā)送給微服務(wù)2 的每條消息以先進(jìn)先出方式存儲(chǔ)在隊(duì)列12 中，且隊(duì)列12 只用于存儲(chǔ)微服務(wù)1 發(fā)送給微服務(wù)2 的消息.換言之，每個(gè)微服務(wù)需要為來自其他微服務(wù)的發(fā)送消息配備不同的隊(duì)列.

圖6 基于消息隊(duì)列的異步通信模型Figure 6 Message queuing asynchronous communication model

3.1.2 基于發(fā)布訂閱的異步通信模型

在基于發(fā)布訂閱的異步通信模型中，消息被持久化在主題中.消息接收者可以訂閱一個(gè)或多個(gè)主題并使用該主題中的所有消息，如圖7所示.通常消息發(fā)送者稱為發(fā)布者，消息接收者稱為訂閱者.在圖7中，微服務(wù)1 稱為發(fā)布者，微服務(wù)2～4稱為訂閱者.

圖7 基于發(fā)布訂閱的異步通信模型Figure 7 Publish-subscribe asynchronous communication model

3.2 協(xié)議

3.2.1 REST

REST 本質(zhì)上是一種架構(gòu)風(fēng)格，其中表現(xiàn)層狀態(tài)轉(zhuǎn)化是一組架構(gòu)約束和原則[36,49].而滿足這種架構(gòu)風(fēng)格的軟件系統(tǒng)體系結(jié)構(gòu)被認(rèn)為是RESTful 的.RESTful 體系結(jié)構(gòu)強(qiáng)調(diào)：1）使用URI 來定位資源；2）通過表現(xiàn)層進(jìn)行資源操作，資源可以是XML、JSON、二進(jìn)制文件等；3）客戶端通過使用4 種HTTP 動(dòng)詞（GET、POST、PUT、DELETE）使服務(wù)器端發(fā)生表現(xiàn)層狀態(tài)轉(zhuǎn)化[50].RESTful API是指一種API，它使調(diào)用資源非常方便和直觀，同時(shí)也降低了服務(wù)的復(fù)雜性[51].

當(dāng)前存在許多支持同步消息傳遞的中間件標(biāo)準(zhǔn)，例如Corba 的IIOP 協(xié)議、Java 遠(yuǎn)程方法調(diào)用（RMI）和簡單對(duì)象訪問協(xié)議（SOAP）.相比這些標(biāo)準(zhǔn)，REST 具有簡單性、高性能和無狀態(tài)性等優(yōu)點(diǎn).因此，微服務(wù)系統(tǒng)中的同步通信更多采用REST協(xié)議[52]，并具有更少的計(jì)算開銷[53-54]和更好的移動(dòng)性[55].

3.2.2 AMQP（advanced message queuing protocol）

Java 消息服務(wù)（JMS）僅僅是一個(gè)接口或API 標(biāo)準(zhǔn)，而非指定的標(biāo)準(zhǔn)協(xié)議[56].為了創(chuàng)建可互操作的企業(yè)級(jí)異步消息傳遞的開放標(biāo)準(zhǔn)，2014年，結(jié)構(gòu)化信息標(biāo)準(zhǔn)促進(jìn)組織（organization for advanced structured information systems,OASIS）將AMQP 作為一套標(biāo)準(zhǔn)發(fā)布，并被國際標(biāo)準(zhǔn)化組織/國際電工委員會(huì)（ISO/IEC）所采納.

AMQP是一個(gè)分層的體系結(jié)構(gòu)本質(zhì)上，AMQP是基于二進(jìn)制的協(xié)議，并具有以下兩個(gè)顯著的特點(diǎn)：

1）責(zé)任鏈模式[56]

在這個(gè)模式中，從發(fā)送者流向接收者的消息實(shí)際上是通過位于兩者之間的一組消息處理器來傳遞的.消息傳遞過程中，每個(gè)消息處理器對(duì)消息進(jìn)行操作（添加操作、修改操作、拒絕操作），并將處理后的消息傳遞給下一個(gè)消息處理器.

2）協(xié)議模型[56]

與典型的消息傳遞系統(tǒng)相比，該協(xié)議模型最大的不同在于使代理能夠有效地做出路由決策.在典型的消息傳遞系統(tǒng)中，決定從哪個(gè)隊(duì)列生成或消耗消息的邏輯是嵌入到使用該隊(duì)列的應(yīng)用程序中的.

目前，AMQP 協(xié)議可用于支持基于消息隊(duì)列的異步通信模型和基于發(fā)布訂閱的異步通信模型.

3.2.3 其他協(xié)議

可擴(kuò)展消息出席協(xié)議（extensible messaging and presence protocol,XMPP）是一種基于XML 的通信標(biāo)準(zhǔn)，用于面向消息的中間件通信.其核心規(guī)范包括RFC 6120[57]RFC 6121[58]、RFC 7622[59].

消息隊(duì)列遙測(cè)傳輸協(xié)議（message queuing telemetry transport,MQTT）由IBM 開發(fā)后貢獻(xiàn)給結(jié)構(gòu)化信息標(biāo)準(zhǔn)促進(jìn)組織（OASIS）.目前，該協(xié)議已成功應(yīng)用于物理網(wǎng)領(lǐng)域的各種嵌入式系統(tǒng)中.

3.3 消息格式

目前存在兩種流行的消息格式：文本型的消息格式和二進(jìn)制的消息格式.

文本型消息格式包括JSON（JavaScript Object Notation）和XML（Extensible Markup Language）.其中，JSON 的標(biāo)準(zhǔn)定義包括標(biāo)準(zhǔn)化組織（ECMA International）發(fā)布的Ecma-404[60]和互聯(lián)網(wǎng)工程任務(wù)組（IETF）發(fā)布的RFC 7159[61].XML是W3C標(biāo)準(zhǔn)支持的消息格式，它是從SGML（ISO 8879）派生的一種簡單和靈活的文本格式.文本型消息格式的優(yōu)點(diǎn)是自描述的和可讀性強(qiáng)，而缺點(diǎn)是消息會(huì)變得冗長使文本序列化/反序列化將影響內(nèi)存和帶寬[62].

二進(jìn)制的消息格式包括Thrift[62]和Protocol Buffers[63].Thrift 是Apache 的開源軟件框架，用于開發(fā)跨語言和跨平臺(tái)的低開銷服務(wù)，現(xiàn)有超過15 種語言支持[64].Protocol Buffers 是Google 公司內(nèi)部使用的一種與平臺(tái)和語言無關(guān)的消息格式，提供了C++、Java、Python 三種語言的API.相比JSON 和XML，二進(jìn)制表示的消息需要更少的內(nèi)存、帶寬和處理，在移動(dòng)服務(wù)消耗方面也優(yōu)于文本表示的消息[65].

3.4 實(shí)現(xiàn)框架

當(dāng)前，微服務(wù)系統(tǒng)中大量使用的異步通信框架包括：Kafka、RabbitMQ、Google Pub/Sub、Amazon Services、ActiveMQ.

Kafka 是目前最流行的開源分布式發(fā)布訂閱流平臺(tái)，每分鐘可以處理數(shù)百萬條消息.

RabbitMQ 消息傳遞模型的核心思想是：生產(chǎn)者將消息發(fā)送到消息交換機(jī)（exchanges），而非將消息發(fā)送到隊(duì)列.

Google cloud Pub/Sub 是谷歌公司發(fā)布的開放實(shí)時(shí)消息API，用于支持在不同的應(yīng)用之間發(fā)送和接收消息.通過發(fā)布/訂閱模型將消息的發(fā)送者和消息的接收者進(jìn)行分離.

Amazon Simple Queue Service (Amazon SQS)是亞馬遜公司提供的一個(gè)分布式的消息隊(duì)列服務(wù)，支持標(biāo)準(zhǔn)隊(duì)列和FIFO 隊(duì)列；Amazon Simple Notification Service (Amazon SNS) 是亞馬遜公司提供一項(xiàng)消息推送服務(wù)，遵循發(fā)布/訂閱模式.

ActiveMQ 是Apache 發(fā)布的一款開源消息中間件，用于支持企業(yè)級(jí)消息通信.

表4從消息隊(duì)列、發(fā)布定義、是否開源、支持的編程語言和支持的主要協(xié)議5 個(gè)方面對(duì)上述框架進(jìn)行了比較.

表4 不同框架的比較Table 4 Comparison of different frameworks

4 挑 戰(zhàn)

4.1 數(shù)據(jù)一致性

盡管微服務(wù)系統(tǒng)具有靈活性和高擴(kuò)展性，但如何確保系統(tǒng)中數(shù)據(jù)的一致性是具有挑戰(zhàn)性的[66].在單體系統(tǒng)中，數(shù)據(jù)集中存儲(chǔ)于同一數(shù)據(jù)庫；而在微服務(wù)架構(gòu)中，數(shù)據(jù)分布在不同微服務(wù)的數(shù)據(jù)庫中，如何跨多個(gè)數(shù)據(jù)庫確保事務(wù)的一致性是急需解決的關(guān)鍵問題[19,32].

顯然，傳統(tǒng)解決單一數(shù)據(jù)庫中數(shù)據(jù)一致性的方法并不適用于微服務(wù)系統(tǒng)[67-68].目前在微服務(wù)的上下文中有兩種解決數(shù)據(jù)一致性的方法：

1）基于克隆的方法

每個(gè)微服務(wù)均創(chuàng)建一個(gè)原數(shù)據(jù)庫的克隆，以獨(dú)立的方式與自己私有的數(shù)據(jù)庫進(jìn)行交互[69].私有數(shù)據(jù)庫的每個(gè)更新將通過廣播的方式通知其他克隆數(shù)據(jù)庫，以確保各數(shù)據(jù)庫間數(shù)據(jù)的一致性.該方法的缺點(diǎn)是需要占用更多的資源來存儲(chǔ)數(shù)據(jù)[19].

2）基于私有數(shù)據(jù)庫的方法

每個(gè)微服務(wù)擁有自己私有的數(shù)據(jù)庫[3].如文獻(xiàn)[70]提出了切片模式，根據(jù)每個(gè)微服務(wù)的業(yè)務(wù)邊界，將統(tǒng)一的中心數(shù)據(jù)存儲(chǔ)劃分為一組水平切片.但該方法面臨的主要挑戰(zhàn)在于對(duì)不同數(shù)據(jù)庫中的數(shù)據(jù)進(jìn)行連接操作時(shí)，如何確保數(shù)據(jù)間的一致性[19].

4.2 調(diào)試

微服務(wù)系統(tǒng)本質(zhì)上是并發(fā)分布式系統(tǒng).通常，調(diào)試并發(fā)分布式系統(tǒng)的有效方法是跟蹤和可視化系統(tǒng)的執(zhí)行[73].與傳統(tǒng)的并發(fā)分布式系統(tǒng)相比，微服務(wù)系統(tǒng)更具復(fù)雜性和動(dòng)態(tài)性[74]，具體如下：

1）在大量的節(jié)點(diǎn)上（如物理機(jī)或虛擬機(jī)）運(yùn)行大量的微服務(wù)實(shí)例，且微服務(wù)實(shí)例的分布也在不斷變化，給微服務(wù)間的通信帶來很大的不確定性[75].

2）微服務(wù)系統(tǒng)涉及復(fù)雜的環(huán)境配置，不正確或不一致的環(huán)境配置將導(dǎo)致運(yùn)行時(shí)的故障[39].

3）微服務(wù)間涉及大量復(fù)雜的異步交互.這些異步交互涉及復(fù)雜的調(diào)用鏈，容易導(dǎo)致不恰當(dāng)?shù)膮f(xié)作，進(jìn)而導(dǎo)致運(yùn)行時(shí)的故障[74].

4）由于微服務(wù)實(shí)例可以動(dòng)態(tài)創(chuàng)建和銷毀，因此在微服務(wù)系統(tǒng)中微服務(wù)和系統(tǒng)節(jié)點(diǎn)之間缺乏對(duì)應(yīng)關(guān)系[75].

這些高復(fù)雜性和動(dòng)態(tài)性給調(diào)試微服務(wù)系統(tǒng)帶來了眾多挑戰(zhàn)[71,75].文獻(xiàn)[74]指出當(dāng)前調(diào)試微服務(wù)系統(tǒng)在很大程度上取決于開發(fā)人員對(duì)系統(tǒng)和類似故障案例的經(jīng)驗(yàn)，并主要依靠手動(dòng)方式檢查日志.

4.3 監(jiān)控

對(duì)微服務(wù)系統(tǒng)進(jìn)行性能監(jiān)控和分析是具有挑戰(zhàn)的[76].在微服務(wù)架構(gòu)中，影響性能的主要因素是網(wǎng)絡(luò)通信.通常，執(zhí)行微服務(wù)系統(tǒng)的某個(gè)業(yè)務(wù)功能需要涉及大量微服務(wù)間的交互和協(xié)作.在這些交互中，任何一個(gè)微服務(wù)的響應(yīng)延遲或慢響應(yīng)都可能導(dǎo)致整個(gè)軟件系統(tǒng)性能下降.

由于微服務(wù)架構(gòu)提倡服務(wù)的重用，微服務(wù)系統(tǒng)中將包含第三方服務(wù)[77].如何對(duì)第三方服務(wù)進(jìn)行安全監(jiān)控是面臨的另一個(gè)挑戰(zhàn).

4.4 安全問題

微服務(wù)架構(gòu)的核心思想是將應(yīng)用程序的復(fù)雜性分布在獨(dú)立可部署的微服務(wù)間.但服務(wù)間以及服務(wù)和數(shù)據(jù)間的復(fù)雜依賴也給微服務(wù)系統(tǒng)帶來安全問題[71].

1）更大的攻擊面.相較傳統(tǒng)的單體系統(tǒng)，微服務(wù)系統(tǒng)暴露出了更多的潛在攻擊.因?yàn)槲⒎?wù)系統(tǒng)由多個(gè)微服務(wù)組成，而這些微服務(wù)在網(wǎng)絡(luò)中都將暴露API 以便通信和交互.這無疑給攻擊者提供了更多的漏洞點(diǎn)來擴(kuò)大攻擊面[71].此外，微服務(wù)結(jié)構(gòu)鼓勵(lì)使用現(xiàn)成的OTS(off-the-shelf) 組件來實(shí)現(xiàn)重用，但部署OTS 組件本身就容易帶來安全威脅.

2）基于可信計(jì)算基礎(chǔ)的攻擊.基于微服務(wù)系統(tǒng)的可信計(jì)算基礎(chǔ)是所有的微服務(wù)彼此信任對(duì)方[72].因此，假如一個(gè)攻擊者獲得某個(gè)可信微服務(wù)的控制權(quán)，則通過服務(wù)間的信任和依賴關(guān)系很容易傳播攻擊，進(jìn)而造成整個(gè)應(yīng)用程序崩潰.也就是說，一個(gè)微服務(wù)被攻破可能導(dǎo)致整個(gè)應(yīng)用程序的崩潰[72].

3）數(shù)據(jù)被偽造或篡改.當(dāng)微服務(wù)系統(tǒng)采用一組數(shù)據(jù)切片時(shí)，如何防止各個(gè)數(shù)據(jù)切片內(nèi)的數(shù)據(jù)被偽造或篡改是至關(guān)重要的.

4）通信消息被偽造或篡改.在沒有集中式的控制下，微服務(wù)間采用基于消息通信的方式進(jìn)行交互和協(xié)作.由于通信消息可能會(huì)被偽造或篡改，因此，如果這些消息通信沒有考慮安全保護(hù)，則服務(wù)間的交互和協(xié)作是不安全的.

5）監(jiān)控安全性的難度增加.微服務(wù)間大量交互帶來的網(wǎng)絡(luò)復(fù)雜性大大增加了監(jiān)控整個(gè)軟件系統(tǒng)安全性的難度[72].一方面，這種網(wǎng)絡(luò)復(fù)雜性決定了對(duì)整個(gè)軟件系統(tǒng)的調(diào)試、監(jiān)控、審計(jì)和鑒證分析的難度不斷增加；另一方面，攻擊者可以利用這種復(fù)雜性對(duì)軟件系統(tǒng)發(fā)起攻擊.

6）未授權(quán)的訪問.由于微服務(wù)系統(tǒng)中存在大量的微服務(wù)，如何防止其他微服務(wù)未經(jīng)授權(quán)的訪問是一項(xiàng)嚴(yán)峻的挑戰(zhàn)[32].

5 結(jié) 語

本文從體系結(jié)構(gòu)、通信和挑戰(zhàn)三個(gè)維度對(duì)微服務(wù)技術(shù)的研究現(xiàn)狀和最新進(jìn)展進(jìn)行分析和概況.首先，從體系結(jié)構(gòu)角度，從組件化、部署和擴(kuò)展、數(shù)據(jù)管理及開發(fā)4 個(gè)方面系統(tǒng)比較了單體架構(gòu)、SOA 和微服務(wù)架構(gòu).其次，從異步通信模型、協(xié)議、數(shù)據(jù)格式和實(shí)現(xiàn)框架4 個(gè)方面概述了微服務(wù)間的通信.最后，列舉了微服務(wù)技術(shù)面臨的4 個(gè)技術(shù)挑戰(zhàn)：數(shù)據(jù)一致性、調(diào)試、監(jiān)控和安全.