微服務(wù)技術(shù)發(fā)展的現(xiàn)狀與展望

馮志勇 徐硯偉 薛 霄 陳世展

(天津大學(xué)智能與計算學(xué)部 天津 300350)

Fig. 1 Integrated evolutionary graph of software ecosystems圖1 軟件生態(tài)系統(tǒng)集成進(jìn)化圖

隨著云計算、物聯(lián)網(wǎng)、服務(wù)計算等技術(shù)快速發(fā)展，社會生產(chǎn)生活對軟件系統(tǒng)的需求量與日俱增，用戶需求的多樣性、個性化趨勢日趨凸顯.為了滿足不斷演化的用戶需求，許多軟件企業(yè)開放其軟件產(chǎn)品線，允許上下游相關(guān)企業(yè)、外部開發(fā)者甚至用戶參與到軟件開發(fā)維護(hù)工作之中，進(jìn)而有效加快軟件產(chǎn)業(yè)的垂直分工和水平整合，促進(jìn)了軟件生態(tài)系統(tǒng)(software ecosystems, SECO)[1]的豐富和完善.

隨著軟件功能不斷擴(kuò)展、用戶負(fù)載量逐漸增長等發(fā)展問題，軟件生態(tài)系統(tǒng)中模塊與組件之間的調(diào)用依賴關(guān)系也變得越來越復(fù)雜.在這種背景下，新組件的引入與迭代、數(shù)據(jù)的快速更新，無疑會造成軟件生態(tài)系統(tǒng)的不穩(wěn)定、不平衡.為了確保系統(tǒng)滿足高可用、高并發(fā)的要求，系統(tǒng)架構(gòu)需要根據(jù)用戶需求合理配置資源，以保證資源利用率最大化.具體而言，從系統(tǒng)集成的角度，軟件生態(tài)系統(tǒng)的演化過程可以大致分為3個階段，各階段特點(diǎn)如圖1[2]所示.

1) 點(diǎn)對點(diǎn)集成

點(diǎn)對點(diǎn)集成階段通常產(chǎn)生在系統(tǒng)發(fā)展初期，其演化和擴(kuò)展的方式為1對1集成.在企業(yè)應(yīng)用系統(tǒng)個數(shù)較少的場景下，系統(tǒng)通過提供的對應(yīng)接口，實(shí)現(xiàn)系統(tǒng)間的數(shù)據(jù)傳輸.當(dāng)應(yīng)用系統(tǒng)數(shù)量達(dá)到一定程度時，系統(tǒng)間的接口眾多，會導(dǎo)致大量重復(fù)開發(fā)和聯(lián)調(diào)工作，接口的開發(fā)難易程度和維護(hù)成本會隨之增大.因此，整個軟件生態(tài)系統(tǒng)的擴(kuò)展能力較弱，其演化方式也顯得笨重且僵硬.在此種情況下，面向服務(wù)體系架構(gòu)(service-oriented achitecture， SOA)[3]的集成理念應(yīng)運(yùn)而生.

2) 平臺集成

SOA是一種軟件系統(tǒng)的設(shè)計方法，以松耦合的方式，將應(yīng)用系統(tǒng)的不同服務(wù)功能進(jìn)行拆分，通過服務(wù)之間定義良好的接口實(shí)現(xiàn)服務(wù)集成.SOA理念[4]的出現(xiàn)使企業(yè)開始從整體角度看待IT(information technology)架構(gòu)的建設(shè)，更加強(qiáng)調(diào)自上至下的整體架構(gòu).同時，企業(yè)服務(wù)總線(enterprise service bus， ESB)[5]的興起，為服務(wù)整合提供行之有效的解決方案，ESB在數(shù)據(jù)集成、應(yīng)用集成、流程集成、門戶集成等方面具有獨(dú)特的優(yōu)勢，可以有效地簡化IT系統(tǒng)結(jié)構(gòu)，提高系統(tǒng)的靈活性和可擴(kuò)展能力.

3) 互聯(lián)網(wǎng)集成

隨著移動互聯(lián)網(wǎng)與互聯(lián)網(wǎng)+的發(fā)展，原有的SOA體系架構(gòu)遇到了4個問題：①缺乏有效的服務(wù)治理，服務(wù)資產(chǎn)混雜不清，沒有有效的服務(wù)管控手段；②業(yè)務(wù)支撐響應(yīng)慢，系統(tǒng)尾大不掉，無法做到實(shí)時更新和模塊化發(fā)布；③系統(tǒng)可用性差，無法做到7×24 h無間斷提供服務(wù)；④創(chuàng)新業(yè)務(wù)難以支撐，特別是帶有互聯(lián)網(wǎng)特點(diǎn)的創(chuàng)新業(yè)務(wù).

基于此，開發(fā)人員以體系結(jié)構(gòu)優(yōu)化為出發(fā)點(diǎn)，提出了基于微服務(wù)的SOA體系架構(gòu)[6]；其核心理念是將復(fù)雜的應(yīng)用系統(tǒng)以獨(dú)立業(yè)務(wù)單元的形式分解為多個服務(wù)，每個服務(wù)可以采用不同的實(shí)現(xiàn)技術(shù)，以輕量級、更靈活的模式進(jìn)行獨(dú)立設(shè)計、開發(fā)、部署，運(yùn)行于獨(dú)立的進(jìn)程中，形成高度內(nèi)聚的自治單元[7].

Fig. 2 Holistic architecture and microservice architecture圖2 整體架構(gòu)與微服務(wù)架構(gòu)

具體而言，SOA把系統(tǒng)劃分成不同的服務(wù)，使用接口進(jìn)行數(shù)據(jù)交互，服務(wù)之間通過相互依賴、有效整合，以達(dá)到系統(tǒng)的整體功能[8].而在體系架構(gòu)方面，微服務(wù)架構(gòu)是基于SOA架構(gòu)基礎(chǔ)上的改進(jìn)，并且融入組件化思想與領(lǐng)域建模思想.首先，系統(tǒng)被拆分為多個微服務(wù)，以松耦合的方式被獨(dú)立部署；其次，每個微服務(wù)僅需高質(zhì)量地完成本身任務(wù)，且每個任務(wù)代表著一項(xiàng)細(xì)粒度業(yè)務(wù)能力；由此，各項(xiàng)業(yè)務(wù)被徹底的組件化和服務(wù)化[9]；最后，提供領(lǐng)域服務(wù)能力的模塊在底層微服務(wù)架構(gòu)中實(shí)現(xiàn)服務(wù)的組合和組裝.如圖2(a)所示，整體架構(gòu)將所有軟件功能放在一個進(jìn)程中，由多個服務(wù)器共同支持運(yùn)行計算任務(wù)，最后將運(yùn)行結(jié)果返還給用戶；而微服務(wù)架構(gòu)(圖2(b))將軟件整體功能分解成多個服務(wù)，分別由不同類別的服務(wù)器進(jìn)行支持；然后，將數(shù)據(jù)反饋給數(shù)據(jù)庫，用戶可以從數(shù)據(jù)庫中獲取數(shù)據(jù)，既加快了系統(tǒng)的整體響應(yīng)速度，又滿足互聯(lián)網(wǎng)化環(huán)境下前后端分離的業(yè)務(wù)需求.由此可見，微服務(wù)體系架構(gòu)的優(yōu)勢[10]主要體現(xiàn)在：分布式(物理部署、服務(wù)部署、數(shù)據(jù)存儲)、高可用(分布式架構(gòu)、集群化部署、服務(wù)自動注冊)、可伸縮(按需分配資源)、運(yùn)維智能化等方面.

隨著軟件系統(tǒng)功能的日益擴(kuò)展復(fù)雜化，基于微服務(wù)的SOA架構(gòu)開始日益興起.具體而言，微服務(wù)在前臺支撐業(yè)務(wù)的快速響應(yīng)與個性化，是采用面向服務(wù)開發(fā)的SOD(service-oriented development)，具有開發(fā)快速、響應(yīng)及時、易于實(shí)現(xiàn)等特點(diǎn)[11]；ESB服務(wù)總線作為后端支撐各系統(tǒng)、技術(shù)、平臺的集成，而面向服務(wù)的基礎(chǔ)設(shè)施(service-oriented infrastruc-ture, SOI)[12]，具有穩(wěn)定、高度集成等特點(diǎn).微服務(wù)技術(shù)與ESB技術(shù)二者相輔相成，分別在SOA架構(gòu)中發(fā)揮不同的核心作用，以期達(dá)到軟件系統(tǒng)的自服務(wù)效果.

本文首先以系統(tǒng)集成角度，闡述微服務(wù)出現(xiàn)的特定背景，并逐漸深入探討微服務(wù)核心組件以及微服務(wù)技術(shù)與架構(gòu)發(fā)展；其次，詳細(xì)介紹近年來微服務(wù)系統(tǒng)所采用的關(guān)鍵技術(shù)；最后，對微服務(wù)所面臨的挑戰(zhàn)與未來發(fā)展趨勢進(jìn)行了分析.

1 微服務(wù)的核心組件

根據(jù)Lewis等人[13]的闡述，軟件架構(gòu)研討會(Seminar on Software Architecture)于2014年5月首次定義了“微服務(wù)”這一術(shù)語，用來表示諸多學(xué)者一直探索的系統(tǒng)共同架構(gòu)方法.此前，部分學(xué)者已經(jīng)使用不同的方法實(shí)現(xiàn)了該框架.例如亞馬遜公司Vogels等人[14]將該種架構(gòu)方法描述為“將直接操作數(shù)據(jù)的業(yè)務(wù)邏輯來封裝數(shù)據(jù)，通過已發(fā)布的服務(wù)接口進(jìn)行唯一訪問”，Netflix公司Cockcroft[15]將其定義為“松散耦合的面向服務(wù)的體系結(jié)構(gòu)與有限制的信息交換”.工業(yè)界中相關(guān)概念有“fine-grained SOA”和“SOA done right”等方法.

從字面去理解微服務(wù)，即什么是“微”、什么是“服務(wù)”，“微”狹義上來講就是體積小、架構(gòu)小，而"服務(wù)"，區(qū)別于整體系統(tǒng)的概念，是一個或者一組相對較小且獨(dú)立的功能單元，是用戶可以感知到的最小功能集；每個微服務(wù)具有自己的輕量處理和通信機(jī)制，并且自動化部署在單個或多個服務(wù)器上.其中，微服務(wù)概念來源領(lǐng)域驅(qū)動設(shè)計(domain-driven design, DDD)[16]，即是一種基于模型的開發(fā)方法，由有限組織環(huán)境和持續(xù)軟件集成等原則進(jìn)行指導(dǎo).該設(shè)計統(tǒng)一了分析和設(shè)計編程，使得軟件能夠更靈活快速跟隨需求變化.解決了分布式Web規(guī)模應(yīng)用程序(Facebook，Spotify等)中存在的挑戰(zhàn)以及大型科技公司面臨的組織問題.

微服務(wù)為分布式軟件系統(tǒng)提供了良好的解決方案.與傳統(tǒng)面向服務(wù)體系結(jié)構(gòu)的實(shí)施方案相比，微服務(wù)體系結(jié)構(gòu)除了提供服務(wù)注冊與發(fā)現(xiàn)，服務(wù)組合等基本組件外，還加入了負(fù)載均衡、服務(wù)網(wǎng)關(guān)和容錯機(jī)制等，同時對已有模塊進(jìn)行了擴(kuò)展和優(yōu)化；圖3是對微服務(wù)框架相關(guān)元素[17]及元素內(nèi)容的具體展示.將結(jié)合圖3，從5個方面介紹微服務(wù)核心組件.

Fig. 3 Microservice core components圖3 微服務(wù)核心組件

1.1 服務(wù)發(fā)現(xiàn)機(jī)制與注冊中心

微服務(wù)遵循輕量級通信原則，單個微服務(wù)一般部署在輕量級容器如Docker中.然而，在運(yùn)行過程中，服務(wù)實(shí)例隨時可能被銷毀、克隆或者重新定位；由此，服務(wù)實(shí)例在動態(tài)變化中，創(chuàng)建一種服務(wù)發(fā)現(xiàn)機(jī)制，有利于服務(wù)之間感知彼此的存在.其中，服務(wù)注冊中心[18]是服務(wù)發(fā)現(xiàn)機(jī)制中重要的一環(huán)，即服務(wù)啟動時會將自身的網(wǎng)絡(luò)地址與數(shù)據(jù)提交到注冊中心，并訂閱自己需要消費(fèi)的服務(wù).

服務(wù)注冊中心是服務(wù)發(fā)現(xiàn)的核心，必須具有高可用性和實(shí)時更新功能；主要存儲服務(wù)提供者和消費(fèi)者的統(tǒng)一資源定位器(uniform resoure locator， URL)地址及路由轉(zhuǎn)發(fā)信息；實(shí)現(xiàn)服務(wù)注冊、發(fā)布、健康檢查和故障檢測等功能.表1對目前較為流行的服務(wù)注冊中心進(jìn)行了分析與歸納.其中，在Key-Value，Kubernetes，Cloud Foundry等應(yīng)用平臺中使用的Etcd具有分布式、高可用性以及強(qiáng)一致性特征，適合于少量數(shù)據(jù)的情形.而由Google公司開發(fā)和維護(hù)注冊中心Consul功能更為全面，作為一個用于發(fā)現(xiàn)和配置的工具，Consul提供了允許客戶端注冊和發(fā)現(xiàn)服務(wù)的API，而其提供的服務(wù)健康檢查，可以幫助確定服務(wù)可用性.此外，具有高協(xié)調(diào)能力的Zookeeper在分布式系統(tǒng)中應(yīng)用較為廣泛[19]，通過提供統(tǒng)一命名服務(wù)、集群管理、狀態(tài)同步、分布式應(yīng)用配置與管理等功能，解決了分布式系統(tǒng)中數(shù)據(jù)一致性問題.

Table 1 Service Registry Comparisons表1 服務(wù)注冊中心比較

1.2 負(fù)載均衡

為了保證服務(wù)具有高度可用性，微服務(wù)需要部署多個服務(wù)實(shí)例來提供業(yè)務(wù)支持；當(dāng)請求面對同一服務(wù)的多個實(shí)例，如何合理選擇服務(wù)實(shí)例以減少業(yè)務(wù)等待時間成為一個亟待解決的問題，由此負(fù)載均衡可以分為客戶端負(fù)載均衡與服務(wù)端負(fù)載均衡，以選擇合理的服務(wù)負(fù)載均衡策略.

負(fù)載均衡具有多種實(shí)現(xiàn)算法，其中應(yīng)用最廣泛來自著名的Round Robin算法，即輪詢法[20]；其基本思想是將多個可用服務(wù)實(shí)例組織成一個循環(huán)隊(duì)列，然后根據(jù)實(shí)例順序輪流分配給內(nèi)部的服務(wù)器，從1到N(N個服務(wù)器)依次循環(huán)；該方法適用于基本配置相同的服務(wù)且服務(wù)平均請求相對均衡的情境；然而，在面臨性能方面差異較大的服務(wù)實(shí)例時，一般采用加權(quán)輪詢法[21],即根據(jù)服務(wù)器的不同處理能力，給每個服務(wù)器分配不同權(quán)重，響應(yīng)具有相應(yīng)權(quán)值數(shù)的服務(wù)請求；該均衡算法可以提升高性能服務(wù)器的利用率，降低低性能服務(wù)器負(fù)載過重的概率，避免負(fù)載不均衡的情況.但在實(shí)際應(yīng)用中，客戶端每一次請求服務(wù)，服務(wù)器響應(yīng)時間都具有較大差異；因此，若采用簡單輪詢或隨機(jī)均衡算法，并不能達(dá)到真正的負(fù)載均衡.鑒于這一缺點(diǎn)，可采用最小連接數(shù)算法(least connections scheduling, LCS)[22]；該算法記錄當(dāng)前服務(wù)器可負(fù)載實(shí)例數(shù)量，以及該服務(wù)器正在處理的進(jìn)程數(shù)量；具體而言，當(dāng)產(chǎn)生新服務(wù)連接請求時，將把當(dāng)前請求分配給連接數(shù)最少的服務(wù)器，以提升服務(wù)實(shí)例利用率以及服務(wù)器負(fù)載能力.

微服務(wù)架構(gòu)均支持以上負(fù)載均衡算法.與傳統(tǒng)整體架構(gòu)負(fù)載均衡不同的是，傳統(tǒng)整體架構(gòu)使用負(fù)載均衡器分發(fā)高并發(fā)的網(wǎng)絡(luò)請求[23].在微服務(wù)架構(gòu)中,服務(wù)端的軟件模塊維護(hù)一個可用的服務(wù)端清單；客戶端節(jié)點(diǎn)也需維護(hù)本身所訪問的服務(wù)端清單，而這份服務(wù)端清單來自于(微服務(wù)架構(gòu)中獨(dú)有)服務(wù)注冊中心，例如Eureka服務(wù)注冊中心；同時，客戶端需要維護(hù)服務(wù)端清單的健康性，也需與服務(wù)注冊中心配合完成[24].其中，SpringCloud Ribbon是微服務(wù)架構(gòu)中基于客戶端的負(fù)載均衡工具，將面向服務(wù)的REST(representational state transfer)模板請求自動轉(zhuǎn)換成客戶端負(fù)載均衡的微服務(wù)調(diào)用[25].

此外，微服務(wù)架構(gòu)支持的負(fù)載均衡算法還包括隨機(jī)分配服務(wù)器算法、生成請求源IP Hash值方式，精確找到服務(wù)器的IP Hash算法等相關(guān)算法.這里不再一一贅述.

1.3 服務(wù)容錯

容錯，即將系統(tǒng)錯誤產(chǎn)生的影響限制在一定邊界內(nèi).在微服務(wù)體系結(jié)構(gòu)中調(diào)用集群服務(wù)時，若單個微服務(wù)調(diào)用異常，產(chǎn)生如連接超時、請求失敗、流量突增或負(fù)載過高等問題，則需要制定容錯策略進(jìn)行容錯處理，使微服務(wù)具有自我恢復(fù)功能.

服務(wù)容錯分為2種情況：1)若產(chǎn)生超時異常，可采用超時重試機(jī)制[26]，通過設(shè)置服務(wù)請求超時響應(yīng)時間；或者服務(wù)的響應(yīng)時間和次數(shù)，進(jìn)而決定是否采用超時重試機(jī)制.2)若服務(wù)因負(fù)載過高引起異常，可采用限流和熔斷器2種容錯策略.其中，限流是以限制服務(wù)的最大訪問量或者訪問速率的方式，對服務(wù)進(jìn)行容錯處理，熔斷器會記錄和監(jiān)測服務(wù)執(zhí)行情況；若監(jiān)測到某個服務(wù)實(shí)例超過閾值，可拒絕接收服務(wù)請求將其直接返回.目前，微服務(wù)框架支持的容錯策略還有控制并發(fā)、線程隔離等策略；如果連續(xù)失敗多次則直接熔斷，不再發(fā)起調(diào)用，避免單個服務(wù)異常影響系統(tǒng)中整體服務(wù)的運(yùn)行.

1.4 服務(wù)網(wǎng)關(guān)

服務(wù)網(wǎng)關(guān)(service gateway)作為微服務(wù)架構(gòu)中的重要組件，其關(guān)鍵思想是：將輕量級網(wǎng)關(guān)作為所有客戶端/消費(fèi)者的主要入口點(diǎn)，并在Gateway(網(wǎng)關(guān))級別實(shí)現(xiàn)常見的非功能需求.服務(wù)網(wǎng)關(guān)的基本功能有：統(tǒng)一接入、安全防護(hù)、協(xié)議適配、流量管控、長短鏈接支持、系統(tǒng)容錯能力等.目前已有許多成功的應(yīng)用案例.例如，由Netflix公司開發(fā)的Netflix Zuul[27]是目前較通用的服務(wù)網(wǎng)關(guān)組件；其主要作用是協(xié)調(diào)客戶端與微服務(wù)的中間層，提供權(quán)限驗(yàn)證、壓力測試、負(fù)載分配、審查監(jiān)控等較為全面的服務(wù)網(wǎng)關(guān)功能.其中，Zuul主要負(fù)責(zé)處理RESTful的服務(wù)請求及調(diào)用.然而，在部分微服務(wù)業(yè)務(wù)場景下,仍存在“外部客戶端是RESTful的接口請求,而內(nèi)部服務(wù)之間卻是RPC通信”的情況.因此，產(chǎn)生同一系統(tǒng)具有2套不同類型的API接口，無疑增加了通信的復(fù)雜度.由此，GRPC Gateway通過讀取GRPC服務(wù)請求并為其生成反向代理服務(wù)器,將RESTful的HTTP/JSON API接口轉(zhuǎn)化為內(nèi)部GRPC的形式,從而解決了服務(wù)內(nèi)外接口不兼容這一問題[28].其他網(wǎng)關(guān)解決方案這里不再贅述.

1.5 服務(wù)部署和服務(wù)通信

作為微服務(wù)框架核心部件之一，微服務(wù)部署和服務(wù)通信具有至關(guān)重要的作用.微服務(wù)部署中關(guān)鍵問題之一是如何做到獨(dú)立于其他微服務(wù)部署，使每個微服務(wù)級別都可以進(jìn)行部署與擴(kuò)展.從而在單個微服務(wù)的故障不影響任何其他服務(wù)前提下，快速構(gòu)建和部署微服務(wù)，Docker[29]作為一種開源應(yīng)用容器引擎，以應(yīng)用打包以及依賴包到一個可移植容器中的方式，達(dá)到上述功能需求.其具體理念是：將每個服務(wù)實(shí)例部署為容器，微服務(wù)作為Docker容器鏡像打包，根據(jù)容器實(shí)例數(shù)量變化進(jìn)行縮放.在Docker容器部署過程中，使用Kubernetes應(yīng)用平臺組件，將一組Linux容器作為單個系統(tǒng)進(jìn)行管理，在多個主機(jī)上管理和運(yùn)行Docker容器；根據(jù)容器的部署位置，進(jìn)行服務(wù)發(fā)現(xiàn)和復(fù)制控制等機(jī)制，以期對Docker功能進(jìn)行擴(kuò)展與伸縮.基于此種方式，構(gòu)建、部署和啟動微服務(wù)的速度將會大大提升.其中，Kubernetes技術(shù)為Docker容器部署微服務(wù)提供了強(qiáng)有力的支持.

Fig. 4 Development of microservice technology圖4 微服務(wù)技術(shù)發(fā)展歷程

服務(wù)通信是指網(wǎng)絡(luò)傳輸過程中，服務(wù)之間進(jìn)行信息交互或消息傳遞.其關(guān)鍵是保證具有良好的通信機(jī)制，實(shí)現(xiàn)準(zhǔn)確、高效的信息交換.在微服務(wù)框架中，微服務(wù)通信方式分為同步和異步2種模式.在同步通信模式下，客戶端發(fā)出請求，服務(wù)器即時響應(yīng).這種通信模式實(shí)現(xiàn)較為簡單，沒有中間件做代理，一般采用REST和Thrift兩種協(xié)議.其缺點(diǎn)是：通信機(jī)制較為單一，制約了進(jìn)程的速度，在一定程度上降低了系統(tǒng)的可用性.在異步通信模式中，客戶端請求不會阻塞進(jìn)程，服務(wù)端中響應(yīng)可以是非即時.其優(yōu)點(diǎn)是實(shí)現(xiàn)了客戶端與服務(wù)器之間的松耦合，通過中間件進(jìn)行消息緩沖，實(shí)現(xiàn)靈活交互，提高了系統(tǒng)可用性；缺點(diǎn)是基于請求/響應(yīng)交互模式的復(fù)雜性大大提高，為開發(fā)人員帶來大量額外工作.在主流系統(tǒng)框架中，一般采用同步、異步混合通信模式以提高系統(tǒng)可伸縮性以及系統(tǒng)可用性.

2 微服務(wù)技術(shù)的發(fā)展過程

從微服務(wù)最初定義到逐步被軟件系統(tǒng)平臺應(yīng)用，微服務(wù)技術(shù)在不斷發(fā)展進(jìn)步，以適應(yīng)平臺中數(shù)據(jù)量大、更新迭代快的特點(diǎn).下面以微服務(wù)軟件技術(shù)發(fā)展與微服務(wù)架構(gòu)發(fā)展2個方面，揭示微服務(wù)技術(shù)的不斷演變.

2.1 微服務(wù)軟件技術(shù)發(fā)展

早期微服務(wù)應(yīng)用程序受到新一代軟件開發(fā)、部署和管理工具的影響較大.然而，隨著微服務(wù)架構(gòu)應(yīng)用越來越廣泛，管理工具不斷發(fā)展創(chuàng)新，目前微服務(wù)可以支持更龐大、更加多樣化的用戶數(shù)據(jù)群.圖4顯示了10種“waves”軟件技術(shù)發(fā)展的時間表[30]；其中包括應(yīng)用較為廣泛的工具，這些工具在過去10年中極大地影響了微服務(wù)應(yīng)用程序開發(fā)、部署和運(yùn)行等方面.

在“微服務(wù)”概念提出之前，業(yè)界已經(jīng)誕生5次相關(guān)新技術(shù)[30].

1) 輕量級容器(lightweight container engine)技術(shù)(例如LXC和Docker)，允許在系統(tǒng)運(yùn)行時有效地對各個服務(wù)打包、部署和管理.

2) 服務(wù)發(fā)現(xiàn)(service discovery)技術(shù)(例如Eureka和Consul)，允許服務(wù)彼此通信而無需明確地參考服務(wù)網(wǎng)絡(luò)位置.

3) 監(jiān)控(monitoring)技術(shù)(例如Graphite和Sensu)，能夠在不同層次程度上監(jiān)控和分析微服務(wù)資源的行為.

4) 容器編排(container orchestration)技術(shù)(例如Mesos和Kubernetes)，自動化分配容器和管理任務(wù)，開發(fā)人員從底層架構(gòu)中抽象出底層物理或虛擬基礎(chǔ)架構(gòu)，為開發(fā)人員提供一個抽象層，以確定應(yīng)用程序部署在服務(wù)器以及數(shù)據(jù)中心中.

5) 建立延遲和容錯(default tolerance)通信庫(例如Finagle和Hystrix)，使服務(wù)進(jìn)行更有效地執(zhí)行，更可靠地通信.

后5次系統(tǒng)軟件管理方法的提出，為微服務(wù)系統(tǒng)實(shí)施提供了底層技術(shù)支撐.

6) 包括持續(xù)交付(continuous delivery)技術(shù)(例如Ansible和Drone)即指通過軟件自動化的方式，快速迭代發(fā)布軟件；允許團(tuán)隊(duì)頻繁地交付快速更新的軟件產(chǎn)品.其特征是持續(xù)整合、內(nèi)置測試、持續(xù)監(jiān)控和分析反饋.為系統(tǒng)提供了通用集成的解決方案[31]，并且在Web級微服務(wù)生產(chǎn)環(huán)境中已經(jīng)進(jìn)行DevOps實(shí)踐.

7) 混沌工程(chaos engineering)技術(shù)(例如Simian Army和Chaos Toolkit)[32]可自動解決系統(tǒng)中出現(xiàn)的故障，具有高可靠性與高可用性等特性.

8) 邊車(sidecar)技術(shù)(例如Prana和Envoy)[33]，封裝與通信相關(guān)的功能.例如服務(wù)發(fā)現(xiàn)以及特定協(xié)議和容錯通信庫的使用功能，使服務(wù)開發(fā)人員快速獲得通信消息.

9) 包括“無服務(wù)器”計算(serverless computing)技術(shù)(例如AWS Lambda,OpenWhisk,Amazon Web Services)[34]，實(shí)現(xiàn)了“功能即服務(wù)”(functions as a service， FaaS)云模型.這種模式允許云用戶開發(fā)、部署及交付更精細(xì)的服務(wù)功能，而無需創(chuàng)建和管理(如應(yīng)對不一致的流量模式)復(fù)雜基礎(chǔ)模塊執(zhí)行所需的資源.

10) 服務(wù)網(wǎng)格(service mesh)技術(shù)(例如Linkerd和Istio)[35]，以邊車技術(shù)為基礎(chǔ)，提供完全集成的服務(wù)通信監(jiān)控.

圖4中大部分工具都源于工業(yè)應(yīng)用領(lǐng)域.作為開源項(xiàng)目提供給用戶下載與應(yīng)用.其中，表2給出了每個工具的URL網(wǎng)址[30].

Table 2 The Web Site of the Microservice Tool in Figure 4表2 在圖4中微服務(wù)工具的網(wǎng)址(URLs)

Continued (Table 2)

2.2 微服務(wù)架構(gòu)的發(fā)展

在工業(yè)應(yīng)用中，一個完整的微服務(wù)架構(gòu)由多個元素構(gòu)成，它具有獨(dú)立的生態(tài)圈；不但需要基礎(chǔ)設(shè)施配合，還需生產(chǎn)環(huán)節(jié)部門共同協(xié)作；不但在系統(tǒng)運(yùn)行時進(jìn)行管理控制，而且還要具有安全保障的服務(wù)治理.其中，微服務(wù)治理從4個步驟[36]進(jìn)行：1)請求網(wǎng)關(guān).常用有Zuul,Spring Cloud Gateway等組件.2)信息采集.具有服務(wù)注冊發(fā)現(xiàn)、服務(wù)日志、鏈路追蹤等功能.3)信息分析.具有時序性統(tǒng)計、監(jiān)控平臺以及監(jiān)控報警等功能.4)治理策略.具有負(fù)載均衡、請求限流、服務(wù)容錯與服務(wù)配置等功能.在傳統(tǒng)微服務(wù)架構(gòu)中，可能需要鏈接不同的容器和主機(jī)，以使多個微服務(wù)共同協(xié)作[37]完成一項(xiàng)業(yè)務(wù).在此種架構(gòu)中，若使用傳統(tǒng)的日志定位出現(xiàn)問題的容器和主機(jī)，不僅會耗費(fèi)大量的人力與物力，而且可能導(dǎo)致系統(tǒng)運(yùn)行失誤.

在此種情境下，需要在技術(shù)層面提供分布式調(diào)用鏈跟蹤能力，以能夠快速定位出現(xiàn)問題的節(jié)點(diǎn).同樣，在微服務(wù)架構(gòu)中，原來整體式系統(tǒng)分解成多個微服務(wù)，在此種情況下，傳統(tǒng)的逐步式部署方式已不再適合.自動化部署方式成為軟件系統(tǒng)所面臨的必然選擇.此外，出于服務(wù)治理和系統(tǒng)安全考慮，需要對分散的微服務(wù)進(jìn)行集中管控,因此，服務(wù)網(wǎng)關(guān)也是必不可少的組件.這些組件構(gòu)成是由微服務(wù)特點(diǎn)所決定的.具體而言，微服務(wù)架構(gòu)生態(tài)圖[38]如圖5所示.同時，由圖5中微服務(wù)相關(guān)技術(shù)逐步發(fā)展，這些技術(shù)革新的影響在微服務(wù)應(yīng)用程序架構(gòu)發(fā)展中有明顯體現(xiàn).

Fig. 5 Microservice architecture ecological graph圖5 微服務(wù)體系架構(gòu)生態(tài)圖

Fig. 6 Four microservice architectures圖6 4種微服務(wù)體系架構(gòu)

圖6概括了4代微服務(wù)體系架構(gòu)[30].其中，在第1代結(jié)構(gòu)中，如圖6(a)所示，使用輕量級容器技術(shù)(如LXC)打包每個服務(wù)，然后使用容器編排工具(如Mesos)在運(yùn)行時進(jìn)行部署和管理.每個服務(wù)都負(fù)責(zé)跟蹤其他服務(wù)的位置，并且根據(jù)特定的通信協(xié)議調(diào)用其他服務(wù)；任何故障處理機(jī)制(例如重試和回退)都直接在服務(wù)的源代碼中產(chǎn)生深遠(yuǎn)的影響.隨著應(yīng)用程序中服務(wù)數(shù)量的增加，應(yīng)對不同執(zhí)行環(huán)境中部署和重新部署服務(wù)日益增長的需求，調(diào)用正確的服務(wù)實(shí)例成為一個難題.此外，新服務(wù)的實(shí)現(xiàn)語言不盡相同，因此重用現(xiàn)有代碼以及快速有效地處理故障變得愈加困難.

為解決上述問題，第2代引入了服務(wù)和可重復(fù)利用的容錯通信庫，如圖6(b)所示服務(wù)使用公共發(fā)現(xiàn)服務(wù)(例如Consul)來注冊其提供的功能.客戶端服務(wù)可以動態(tài)發(fā)現(xiàn)和調(diào)用這些功能，而無需明確被調(diào)用服務(wù)的位置.在服務(wù)調(diào)用期間，所有特定協(xié)議和故障處理功能被委托給相對應(yīng)通信庫；例如Finagle；該策略不僅簡化了服務(wù)實(shí)現(xiàn)和測試，還允許跨服務(wù)重復(fù)利用的樣板通信代碼.

然而，隨著通信庫功能愈加復(fù)雜，利用不同編程語言對通信功能重新實(shí)現(xiàn)變得越來越困難.開發(fā)人員經(jīng)常被迫使用當(dāng)前程序編程語言來實(shí)現(xiàn)新服務(wù)，無疑增加服務(wù)接口的難度.由此，微服務(wù)可以使開發(fā)人員自由編寫程序，開發(fā)人員可以自主選擇任何編程語言，或以適合特定服務(wù)的需求選擇相對應(yīng)開發(fā)編程語言，這是之前技術(shù)所不具備的優(yōu)點(diǎn).

因此，第3代引入標(biāo)準(zhǔn)服務(wù)代理或sidecars邊車模式，如圖6(c)所示，例如Envoy作為可檢測的服務(wù)中間體.基本思想是通過邊車封裝所有服務(wù)發(fā)現(xiàn)和通信功能，從而提高軟件可重用性.由于每個邊車都是一個獨(dú)立的服務(wù)，因此該策略將現(xiàn)有容錯通信庫的優(yōu)勢帶到新的編程語言，從而大大提高了自主開發(fā)性.

當(dāng)作為網(wǎng)絡(luò)中介時，邊車成為監(jiān)控微服務(wù)應(yīng)用程序中所有服務(wù)信息交互行為的場所.這些工具擴(kuò)展自包含邊車?yán)砟睿蕴峁└蛹傻姆?wù)通信解決方案.應(yīng)用運(yùn)營商可以集中控制平面動態(tài)監(jiān)控和管理多個分布式邊車的行為.基于此種方式，運(yùn)營商可以對各種服務(wù)及服務(wù)通信功能進(jìn)行更加細(xì)粒度的控制，包括服務(wù)發(fā)現(xiàn)、負(fù)載平衡、容錯、消息路由和安全性等功能.

第4代旨在將微服務(wù)應(yīng)用程序引入一個全新的應(yīng)用領(lǐng)域，如圖6(d)所示基本思想是利用最新的FaaS技術(shù)和無中斷計算技術(shù)，簡化微服務(wù)底層開發(fā)和持續(xù)交付[39]操作.這種無服務(wù)器架構(gòu)，其基本思想是將微服務(wù)應(yīng)用程序變成“短暫”函數(shù)的集合，每個函數(shù)根據(jù)特定需求，進(jìn)行快速、創(chuàng)建、更新、替換和刪除等操作，從而極大地提高微服務(wù)的運(yùn)行、部署等操作效率.當(dāng)然，這種無服務(wù)器架構(gòu)仍然需要以通信為中心的技術(shù),例如邊車技術(shù)和服務(wù)網(wǎng)格.現(xiàn)有FaaS平臺并未提供融合2種技術(shù)的通信和流量管理功能.因此，若在無服務(wù)器應(yīng)用程序中創(chuàng)建函數(shù)到函數(shù)的交互，一個具有更全面控制功能的服務(wù)(或功能)網(wǎng)格應(yīng)被創(chuàng)建，以便監(jiān)控和管理這些邊車功能的行為.

3 微服務(wù)關(guān)鍵技術(shù)

微服務(wù)強(qiáng)調(diào)服務(wù)功能的大小，但在實(shí)際應(yīng)用中并沒有統(tǒng)一標(biāo)準(zhǔn).一個功能相對簡單的微服務(wù)在實(shí)際需求與擴(kuò)展中會變得更加復(fù)雜，并且同一業(yè)務(wù)由多個微服務(wù)共同協(xié)作完成.由此，微服務(wù)存在3個問題：1)在分布式協(xié)作方面，存在微服務(wù)之間通信、分布式數(shù)據(jù)存儲一致性等問題；2)在微服務(wù)定位方面，如何快速定位出現(xiàn)的性能瓶頸.3)在測試方面，眾多的微服務(wù)如何協(xié)調(diào)一致，保證測試的準(zhǔn)確性.基于這3個問題，微服務(wù)的順暢運(yùn)行主要采用一些關(guān)鍵技術(shù).

3.1 微服務(wù)分布式通信

首先，在功能相互依賴的大型網(wǎng)絡(luò)系統(tǒng)中，服務(wù)之間的實(shí)時通信顯得尤為重要.在微服務(wù)架構(gòu)中，每1個服務(wù)都是1個進(jìn)程，使用進(jìn)程間通信(inter-process communication， IPC)技術(shù)，以實(shí)現(xiàn)進(jìn)程間信息交互.IPC將進(jìn)程間的交互模式分為2種：1)1對1交互模式與1對多交互模式.簡而言之，1對1模式即是單個客戶端向服務(wù)器端發(fā)出請求，客戶端期望此響應(yīng)即時到達(dá)；然而在線程應(yīng)用中，請求傳送過程可能造成線程阻塞.2)1對多交互模式即是一個客戶端發(fā)出多個通知，被多個相關(guān)聯(lián)服務(wù)消費(fèi)模式.進(jìn)程間的通信統(tǒng)分為以上2種模式，而在實(shí)際技術(shù)應(yīng)用層面，不同編程語言對應(yīng)著不同的通信技術(shù).以Java底層編程語言為基礎(chǔ)的微服務(wù)架構(gòu)通信為例，闡述相關(guān)技術(shù)及協(xié)議的應(yīng)用.在早期分布式初步通信時，采用RPC(remote produce call)，即遠(yuǎn)程過程調(diào)用協(xié)議[40]，是基于客戶端/服務(wù)器(Client/Server， C/S)模式調(diào)用機(jī)制，客戶端向服務(wù)器端發(fā)送調(diào)用請求等待服務(wù)器應(yīng)答，是一種典型的請求應(yīng)答機(jī)制；其基本過程是本地分布式對象向本機(jī)發(fā)出請求，不用開發(fā)人員編寫底層通信代碼，直接向服務(wù)器發(fā)送請求；服務(wù)器對象接受請求信息后，經(jīng)過計算將處理后的結(jié)果返還回客戶端.然而，由于RPC不支持面向?qū)ο?，使用的場景大幅度降低；進(jìn)而促進(jìn)遠(yuǎn)程方法調(diào)用(remote method invocation, RMI)協(xié)議[41]的發(fā)展，RMI協(xié)議支持面向?qū)ο?；采用客戶機(jī)(stubs)和框架(skeletons)進(jìn)行遠(yuǎn)程對象(remote object)的通信.stubs模擬成遠(yuǎn)程對象的客戶端代理，具有與遠(yuǎn)程對象相同的遠(yuǎn)程接口；遠(yuǎn)程對象調(diào)用操作實(shí)際是通過調(diào)用該對象的客戶端代理對象stub來完成，實(shí)現(xiàn)效果與調(diào)用本地對象相同.其優(yōu)點(diǎn)是支持分布式對象、跨平臺高速率的數(shù)據(jù)傳輸；缺點(diǎn)是不能跨越編程語言進(jìn)行數(shù)據(jù)傳輸.

隨著微服務(wù)的架構(gòu)廣泛應(yīng)用，相對應(yīng)的通信協(xié)議也在成熟發(fā)展以適應(yīng)層次不同的通信要求，如JMS(Java message service),Web Service等通信標(biāo)準(zhǔn)已被較為成熟地應(yīng)用.

3.2 分布式的數(shù)據(jù)存儲一致性

傳統(tǒng)整體架構(gòu)是基于數(shù)據(jù)庫提供的事務(wù)一致性[42]標(biāo)準(zhǔn)，即通過數(shù)據(jù)庫提供的提交以及回滾機(jī)制中相關(guān)操作的原子性、一致性、隔離性、持久性(atomicity,consistency,isolation,durability, ACID)，保證數(shù)據(jù)庫中的數(shù)據(jù)一致性.在微服務(wù)架構(gòu)中，每個微服務(wù)具有獨(dú)立的數(shù)據(jù)庫，以保證微服務(wù)進(jìn)程獨(dú)立演進(jìn)、獨(dú)立開發(fā).然而在分布式環(huán)境中，每個服務(wù)訪問數(shù)據(jù)是相互分隔，服務(wù)之間不能依靠傳統(tǒng)數(shù)據(jù)庫中ACID保證事務(wù)一致性.由此，基于對微服務(wù)分布數(shù)據(jù)一致性要求，開發(fā)人員在初始階段采用2階段2PC(two phase commit)提交協(xié)調(diào)機(jī)制，該機(jī)制為分布式事務(wù)提供了強(qiáng)一致保障.然而該機(jī)制存在隔離性互斥的特點(diǎn).在事務(wù)執(zhí)行過程中，所有的資源都是被鎖定的，該機(jī)制只適合執(zhí)行時間確定的短事務(wù)，并降低了系統(tǒng)的吞吐率.基于此種情況，開發(fā)人員通過業(yè)務(wù)邏輯將互斥鎖操作從資源層面移到業(yè)務(wù)層面，即提出TCC(try,confirm,cancel)方式.通過Try(嘗試執(zhí)行業(yè)務(wù))、Confirm(確認(rèn)執(zhí)行業(yè)務(wù))及Cancel(取消業(yè)務(wù))三種操作方式，達(dá)到數(shù)據(jù)最終一致性，以提高系統(tǒng)整體性能.但是TCC方式中，微小事務(wù)變動，牽動整個業(yè)務(wù)邏輯，復(fù)雜性較高.Saga事務(wù)[43]正好彌補(bǔ)該缺點(diǎn).Saga事務(wù)就是一個長期運(yùn)行在線的事務(wù)，由多個本地事務(wù)所組成，每個本地事務(wù)具有相應(yīng)的執(zhí)行模塊和補(bǔ)償模塊.當(dāng)Saga事務(wù)中任意一個本地事務(wù)出錯，可以通過調(diào)用相關(guān)事務(wù)對應(yīng)的補(bǔ)償方法進(jìn)行恢復(fù)，達(dá)到事務(wù)最終一致性目標(biāo).然而Saga只提供ACD(atomicity,consistency,durability)，不能保證事務(wù)的隔離性.由此，產(chǎn)生諸如2個Saga事務(wù)同時操作一個資源出現(xiàn)語義不一致、2個Saga事務(wù)操作同一個訂單出現(xiàn)更新丟失等問題，但可以采用在應(yīng)用層面加入邏輯鎖邏輯或者在Session層面隔離來保證串行化等操作，以實(shí)現(xiàn)數(shù)據(jù)分布一致性.Saga的實(shí)現(xiàn)方式可以分布2種:1)集中式實(shí)現(xiàn)方式，即協(xié)調(diào)器負(fù)責(zé)服務(wù)調(diào)用以及事務(wù)協(xié)調(diào).2)分布式實(shí)現(xiàn)方式，即以事件驅(qū)動的底層方法進(jìn)行事務(wù)協(xié)調(diào).在2017年5月，Saga模式在華為開源微服務(wù)框架[44]中已被應(yīng)用，并且在不斷地發(fā)展進(jìn)步.

在微服務(wù)分布式數(shù)據(jù)存儲一致性方面，不同系統(tǒng)具有不同性能、環(huán)境以及對事務(wù)協(xié)調(diào)一致性的要求，采用不同模式事務(wù)分布機(jī)制以達(dá)到分布式數(shù)據(jù)存儲一致性的要求.

3.3 分布式調(diào)用鏈

在微服務(wù)架構(gòu)下，服務(wù)按照不同維度進(jìn)行拆分.由此，一次業(yè)務(wù)請求需要調(diào)用到多個微服務(wù).系統(tǒng)應(yīng)用構(gòu)建在不同軟件模塊中，存在不同模塊由不同的團(tuán)隊(duì)、編程語言實(shí)現(xiàn).同時，可能部署在幾千臺服務(wù)器，橫跨成百個不同的數(shù)據(jù)中心.因此，亟需理解系統(tǒng)行為、用于分析性能問題的工具，以便發(fā)生故障時能夠快速定位和解決問題.分布式調(diào)用鏈應(yīng)運(yùn)而生，即可以監(jiān)控那些橫跨不同應(yīng)用、不同服務(wù)器之間的關(guān)聯(lián)動作，進(jìn)而快速定位與解決故障.

Google公司首先開發(fā)其分布式跟蹤系統(tǒng)并且發(fā)表相關(guān)論文[45]，Twitter參照該論文設(shè)計思想開發(fā)zipkin分布式跟蹤系統(tǒng)，以期為微服務(wù)架構(gòu)提供參考.zipkin通過采集跟蹤數(shù)據(jù)，從而使開發(fā)人員深入了解在分布式系統(tǒng)中某一個特定請求如何執(zhí)行.例如，存在一個用戶請求超時，跟蹤系統(tǒng)可以將這個超時的請求調(diào)用鏈展示在UI當(dāng)中.開發(fā)人員可以快速定位出現(xiàn)故障的服務(wù)，具體可定位到服務(wù)中導(dǎo)致超時的具體位置.同時，通過服務(wù)調(diào)用鏈路能夠快速定位并解決系統(tǒng)的性能瓶頸.同時，針對不同的應(yīng)用系統(tǒng)，存在其他的應(yīng)用程序性能管理(application performance management， APM)工具，如Pinpoint是一款針對Java編程語言大規(guī)模分布式系統(tǒng)的APM工具，通過JavaAgent機(jī)制字節(jié)碼代碼植入，實(shí)現(xiàn)加入traceid和抓取性能數(shù)據(jù)目標(biāo)；Central Application Tracking是由國內(nèi)大眾點(diǎn)評網(wǎng)開源出來的追蹤系統(tǒng)，已被成熟應(yīng)用[46].

在分布式調(diào)用鏈方面，不同的系統(tǒng)平臺根據(jù)其特有的功能屬性，開發(fā)符合其特點(diǎn)的追蹤系統(tǒng)以及調(diào)用鏈.

3.4 測試方面的復(fù)雜性

隨著平臺系統(tǒng)開發(fā)模式逐漸從傳統(tǒng)的整體式產(chǎn)品向快節(jié)奏的微服務(wù)架構(gòu)遷移，軟件測試人員也必須相應(yīng)地調(diào)整測試方法和工具，才能快速便捷地提高測試覆蓋率.傳統(tǒng)整體應(yīng)用只需測試單一的REST API(application programming interface)測試，需要啟動相關(guān)聯(lián)所有其他服務(wù)，使得測試復(fù)雜性較高.在開發(fā)-測試-部署方面，業(yè)界已經(jīng)具備一套較為成熟的解決方案.然而微服務(wù)架構(gòu)是一種演進(jìn)式架構(gòu)，系統(tǒng)最初劃分獨(dú)立服務(wù)的數(shù)量可能極少；隨著業(yè)務(wù)復(fù)雜功能分解與擴(kuò)展，微服務(wù)數(shù)量不可避免地增加.同時，微服務(wù)數(shù)量眾多，功能相對獨(dú)立；在執(zhí)行業(yè)務(wù)過程中，難免需要跨服務(wù)調(diào)用.如何保證跨服務(wù)調(diào)用的可靠性以及不同階段的開發(fā)測試？

在微服務(wù)測試方面，系統(tǒng)被分解成獨(dú)立的微服務(wù)，即每個微服務(wù)都是一個功能完整的小型系統(tǒng).首先需要保證服務(wù)自身業(yè)務(wù)功能的正確性，即通過單元測試保證每個微型系統(tǒng)正確執(zhí)行.其次，由眾多微服務(wù)構(gòu)成完整的系統(tǒng)，需要集成測試來保證整體系統(tǒng)的良好質(zhì)量.然而，在一個微服務(wù)架構(gòu)中，微服務(wù)的個數(shù)達(dá)到一定閾值時，開發(fā)團(tuán)隊(duì)面臨如網(wǎng)絡(luò)環(huán)境不穩(wěn)定、運(yùn)行速度慢、反饋周期長等問題，因此對集成測試望而卻步.進(jìn)而，開發(fā)人員采用Pair集成測試，即將集成范圍縮小，保證兩兩微服務(wù)集成的可靠性.但是這種Pair測試方法存在模擬(Mock)其他服務(wù)，反復(fù)測試已經(jīng)測試過的服務(wù)等問題，增加了額外的工作量.由此，引入Contract概念的集成測試[47]，即前端與后端開發(fā)人員基于業(yè)務(wù)共同定義API協(xié)議(Contract)；該協(xié)議以JSON文件形式存儲于代碼庫的測試資源目錄中.前端在開發(fā)過程中以JSON文件作為測試正確依據(jù)，后端開發(fā)人員則參照該協(xié)議編程實(shí)現(xiàn)相關(guān)API.這種方式具有環(huán)境簡單、運(yùn)行快等優(yōu)點(diǎn).但是若存在任意一方修改協(xié)議內(nèi)容，測試便會失敗，缺乏自動化監(jiān)控機(jī)制[48]以及不能提前發(fā)現(xiàn)問題等缺點(diǎn).在基于Contract概念的基礎(chǔ)之上，消費(fèi)者驅(qū)動契約測試(consumer-driven contract testing)將Contract契約中JSON文件轉(zhuǎn)換成可工作軟件時，文檔的細(xì)微修改便會導(dǎo)致任意一方測試失??；并且通過可工作測試套件保證契約一致性與實(shí)時性.由此，成為雙方共同遵守的契約.

3.5 微服務(wù)應(yīng)用案例

在現(xiàn)代企業(yè)中，微服務(wù)所具有的高可用性、容錯性、可管理性、可替代性[49]等優(yōu)點(diǎn)，滿足企業(yè)用戶的主要業(yè)務(wù)訴求；由此，越來越多的軟件架構(gòu)采用微服務(wù)架構(gòu).基于微服務(wù)以上關(guān)鍵技術(shù)，以教育網(wǎng)站的部分功能為案例[50]，講解微服務(wù)技術(shù)架構(gòu)的具體應(yīng)用.

教育網(wǎng)站具有3部分功能：1)用戶可以登陸注冊、獲取用戶基本信息的功能；2)向用戶發(fā)送郵件、短信的功能；3)可以查看課程列表和對課程的基本增加、讀取、更新、刪除等功能.如圖7所示，展示教育網(wǎng)站部分功能整體架構(gòu).

Fig. 7 The overall framework of some functions of education website圖7 教育網(wǎng)站部分功能整體架構(gòu)

網(wǎng)站采用Java為底層基礎(chǔ)語言，部署在輕量級容器Docker中進(jìn)行實(shí)現(xiàn).根據(jù)教育網(wǎng)站部分功能的劃定與分析，進(jìn)而將整體架構(gòu)進(jìn)行分解為登錄注冊微服務(wù)、用戶信息微服務(wù)、郵件短信微服務(wù)以及課程微服務(wù)等部分.對于微服務(wù)之間的通信，從通信協(xié)議角度，采用RPC協(xié)議；該框架具有系統(tǒng)可擴(kuò)展性、持續(xù)交付能力與高可用性等優(yōu)點(diǎn)[51].常用的RPC框架有Dubbo,Motan,Thrifty,GRPC等,采用Dubbo框架實(shí)現(xiàn)教育網(wǎng)站中部分功能的通信功能.如圖8所示，展示Dubbo框架的架構(gòu)[52].其中，短虛線表示系統(tǒng)啟動過程中的初始化階段，長虛線表示異步通信模式，實(shí)線表示同步通信模式.在注冊服務(wù)部分，服務(wù)提供者向注冊中心注冊所提供的服務(wù)；在訂閱服務(wù)部分，服務(wù)消費(fèi)者向注冊中心訂閱所需的服務(wù)；在通知部分，注冊中心返還服務(wù)提供者地址列表給消費(fèi)者；在調(diào)用部分，采用同步通信，基于負(fù)載均衡算法，服務(wù)消費(fèi)者從提供列表中選擇一臺提供者進(jìn)行調(diào)用，若調(diào)用失敗，則重新選擇.

在微服務(wù)架構(gòu)方面，SpringCloud是一系列框架的有序集合，具有服務(wù)發(fā)現(xiàn)與注冊功能的Netflix Eureka、客服端負(fù)載均衡功能的Netflix Ribbon、服務(wù)網(wǎng)關(guān)功能的Netflix Zuul與分布式配置功能的Spring Cloud Config等核心組件.網(wǎng)站中的服務(wù)網(wǎng)關(guān)采用具有易于認(rèn)證、易于監(jiān)控的Netflix Zuul組件.如圖9[50]所示，客戶端請求服務(wù)調(diào)用，通過API Gateway，轉(zhuǎn)發(fā)到后端微服務(wù)的REST API，以期調(diào)用網(wǎng)站中各個微服務(wù)；每個微服務(wù)具有獨(dú)立的數(shù)據(jù)庫，進(jìn)而查詢每個微服務(wù)基本信息，實(shí)現(xiàn)用戶所需功能.

Fig. 8 Dubbo framework in RPC protocol圖8 RPC協(xié)議中Dubbo框架

Fig. 9 Netflix Zuul service gateway圖9 Netflix Zuul服務(wù)網(wǎng)關(guān)

SpringCloud框架是具有高質(zhì)量、穩(wěn)定性與持續(xù)性等特性的一系列核心組件，可以完成以Java編程語言為基礎(chǔ)的微服務(wù)架構(gòu)的核心功能，這里不再一一贅述.

基于對微服務(wù)核心組件與關(guān)鍵技術(shù)的介紹，微服務(wù)架構(gòu)具有4個優(yōu)勢：1)整體式應(yīng)用分解為具有獨(dú)立功能的微服務(wù)，提供多種服務(wù)方法，解決系統(tǒng)整體功能復(fù)雜性問題；2)每個微服務(wù)可以由專有團(tuán)隊(duì)開發(fā)，對編程語言具有寬泛的選擇性；3)每個微服務(wù)可以獨(dú)立部署，提升系統(tǒng)部署的效率；4)由于每個微服務(wù)具有獨(dú)立性，易于在原有微服務(wù)基礎(chǔ)上進(jìn)行功能擴(kuò)展，提升系統(tǒng)的整體可擴(kuò)展性.然而，微服務(wù)應(yīng)用采用的分布式架構(gòu)，具有其固有的復(fù)雜性，因此，面臨以下挑戰(zhàn).

4 微服務(wù)面臨的挑戰(zhàn)

雖然微服務(wù)相關(guān)技術(shù)在逐步發(fā)展創(chuàng)新，但由于微服務(wù)相當(dāng)于是相對獨(dú)立的小型軟件系統(tǒng)，在一個具有多種功能、多樣性復(fù)雜的大型系統(tǒng)平臺中，如何在一定人力物力成本中，快速部署微服務(wù)以及大量底層應(yīng)用組件，使其具有自動化部署功能；微服務(wù)之間如何迅速準(zhǔn)確地通信，以滿足用戶快速響應(yīng)的需求；如何在正常通信中，保證用戶的數(shù)據(jù)信息安全；在數(shù)量眾多的微服務(wù)中，如何保證數(shù)據(jù)傳輸中的網(wǎng)絡(luò)安全.基于這些問題，微服務(wù)面臨4種挑戰(zhàn).

4.1 基礎(chǔ)設(shè)施

隨著分布式系統(tǒng)中應(yīng)用程序需求迅速增長，傳統(tǒng)依賴于客戶端向服務(wù)器處理端發(fā)起請求的整體體系結(jié)構(gòu)開始發(fā)生轉(zhuǎn)變；這種體系結(jié)構(gòu)不足以應(yīng)付不斷增長的快速請求；面向服務(wù)的體系結(jié)構(gòu)發(fā)展成為客戶端-服務(wù)器體系結(jié)構(gòu)中最成功表示形式之一，然而，從功能角度，SOA架構(gòu)中服務(wù)之間通過相互依賴最終形成一系列的功能，服務(wù)組件大小既可以是小型應(yīng)用程序服務(wù)，也可以是大型企業(yè)應(yīng)用程序，部分組件可以實(shí)現(xiàn)多項(xiàng)功能；由此，SOA仍然屬于整體式系統(tǒng)，不能達(dá)到客戶在彈性、可擴(kuò)展性、快速軟件交付等方面的期望；由此，微服務(wù)體系結(jié)構(gòu)利用其本身靈活性、占用更少資源等特性，滿足了商業(yè)系統(tǒng)自身特性發(fā)展的需要[53].Newman[54]從服務(wù)平臺的角度，闡述了微服務(wù)架構(gòu)存在必要性；系統(tǒng)可以通過微服務(wù)使用不同的技術(shù)、不同編程語言進(jìn)而滿足不同的應(yīng)用需求；與此同時，微服務(wù)之間相互獨(dú)立與更新，可以通過大型虛擬機(jī)運(yùn)行，如使用VMW和AWS(amazon Web services)等虛擬技術(shù)；然而一方面，配置大型虛擬機(jī)耗費(fèi)較長時間；另一方面，管理程序?qū)泳哂泻艽蟮倪\(yùn)載負(fù)荷；基于此，容器技術(shù)被提出，如Linux Containers[55]，容器技術(shù)為程序提供了分割的空間，而不需要管理程序?qū)涌刂普麄€虛擬機(jī).隨著容器技術(shù)的發(fā)展，Docker創(chuàng)建了輕量級容器技術(shù)，具有將服務(wù)及其依賴項(xiàng)打包成單個映像的特性，使其具有代碼移植性[56].每個微服務(wù)都位于本身容器內(nèi)，因此需使用調(diào)度程序協(xié)調(diào)微服務(wù)之間事務(wù)一致性，由此產(chǎn)生“集群管理器”，其基本任務(wù)是確認(rèn)主機(jī)與之相對應(yīng)的容器[57].同時，微服務(wù)分布在不同容器內(nèi)，使之只能使用輕量級通信.利用其HTTP特性，REST API成為最適合微服務(wù)的消息交換機(jī)制，可以使用多種語言格式，如XML與JSON[58].

在網(wǎng)格和集群計算時代，通用監(jiān)控工具只能關(guān)注監(jiān)控性能與數(shù)據(jù)中心資源級別的層次，但不能監(jiān)控到微服務(wù)層次，如Amazon EC2容器的監(jiān)控技術(shù)框架并不能監(jiān)控到微服務(wù)級別的服務(wù)表現(xiàn).由此，收集、整合所有微服務(wù)和數(shù)據(jù)中心資源的整體技術(shù)作為新課題被提出[59-60].另一方面，在部署階段跟蹤通過網(wǎng)關(guān)的微服務(wù)請求流，增加了監(jiān)控成本[61].Kang等人[62]基于對容器中管理服務(wù)狀態(tài)面臨挑戰(zhàn)的研究，對于容器服務(wù)管理和監(jiān)控，則需動態(tài)服務(wù)發(fā)現(xiàn)和注冊等組件.

追根究底，微服務(wù)目的是使系統(tǒng)在水平擴(kuò)縮容和彈性伸縮方面更加敏捷、迅速，但前提是仍需基礎(chǔ)設(shè)施自動化，如何實(shí)現(xiàn)微服務(wù)基礎(chǔ)設(shè)施自動化？就目前發(fā)展來看，是微服務(wù)發(fā)展過程中不可避免的挑戰(zhàn).

4.2 信息交互

在微服務(wù)信息交互方面，若單個服務(wù)由攻擊者掌控，該服務(wù)可能會惡意影響系統(tǒng)其他服務(wù).由此，微服務(wù)架構(gòu)應(yīng)該驗(yàn)證微服務(wù)之間信息交流的真實(shí)性與正確性.從微服務(wù)信息交互的認(rèn)證權(quán)限角度，Gegick等人[63]只將最低和必要權(quán)限分配給相對應(yīng)的用戶，并且在最短時間生效.通過謹(jǐn)慎授權(quán)訪問權(quán)限方式，限制攻擊者破壞系統(tǒng).從授權(quán)協(xié)議的角度出發(fā)，輕量級目錄訪問協(xié)議(lightweight directory access protocol, LDAP)[64]是在SaaS應(yīng)用程序中常用的認(rèn)證協(xié)議;通過LDAP，服務(wù)可以存儲相對靜態(tài)授權(quán)信息，適合于一次記錄，多次讀取的應(yīng)用場景.在數(shù)據(jù)結(jié)構(gòu)方面，基于樹結(jié)構(gòu)的LDAP有效、清晰地描述組織的結(jié)構(gòu)信息，簡化了目錄訪問協(xié)議(directory access protocol, DAP)，以提供基于TCP/IP網(wǎng)絡(luò)的輕量級協(xié)議，降低管理維護(hù)成本.

針對系統(tǒng)內(nèi)部的共享資源，一些學(xué)者認(rèn)為授權(quán)策略應(yīng)該以層次結(jié)構(gòu)方式構(gòu)建，以實(shí)現(xiàn)可伸縮性與可表達(dá)性.為達(dá)到層次性訪問控制，網(wǎng)格安全基礎(chǔ)設(shè)施(grid security infrastructure, GSI)[65]被廣泛應(yīng)用，其包括私鑰保護(hù)和通信加密等步驟.與傳統(tǒng)的授權(quán)系統(tǒng)相比，基于分布式管理機(jī)制的社區(qū)授權(quán)服務(wù)(community authorization service, CAS)模型[66]，允許資源提供者授予部分權(quán)限，既可以對社區(qū)細(xì)粒度訪問控制進(jìn)行維護(hù)，又對資源保持最大控制，提高系統(tǒng)的可擴(kuò)展性與靈活性.Patanjali等人[67]提出了基于模塊化的微服務(wù)架構(gòu)；通過動態(tài)評級、計費(fèi)模式為云服務(wù)提供商驗(yàn)證相關(guān)接口.基于對服務(wù)提供商在整個應(yīng)用程序生命周期中權(quán)限安全性要求，Thanh等人[68]利用包含網(wǎng)絡(luò)功能虛擬化等新興技術(shù)的微服務(wù)框架DevOps[69]，該框架具有2個重要的安全優(yōu)勢:1)是虛擬化安全功能/服務(wù)，框架為用戶選擇和集成多個供應(yīng)商提供安全解決方案；2)對于網(wǎng)絡(luò)層訪問控制，利用防火墻即服務(wù)(firewall as a service, FWaaS)[70]技術(shù)，使用戶對進(jìn)入和離開應(yīng)用程序的網(wǎng)絡(luò)流量采取不同訪問控制策略.Li等人[71]采用微服務(wù)框架OAuth保證相關(guān)權(quán)限的安全性，OAuth框架授權(quán)第三方訪問用戶帳戶以及用戶身份，但是第三方網(wǎng)站可以以訪問用戶帳戶臨時密鑰方式得到訪問用戶身份信息，由此產(chǎn)生用戶私有信息泄露問題.Cheung等人[72]基于微服務(wù)的框架，采用第2版本的OAuth修復(fù)用戶信息漏洞等問題，采用HTTPS協(xié)議并簡單化授權(quán)驗(yàn)證過程，但上述問題仍然存在.在信息交互方面，微服務(wù)框架與對應(yīng)接口認(rèn)證權(quán)限，仍需不斷地擴(kuò)展、改進(jìn).以適應(yīng)大數(shù)據(jù)時代下用戶需求以及隱私信息保護(hù)需求.

在微服務(wù)信息交互層面，仍存在其他問題，如信息交互用時較長、信息交互準(zhǔn)確率較低等問題.基于以上闡述，微服務(wù)信息交互在信息安全性、網(wǎng)絡(luò)穩(wěn)定性等方面，仍面臨巨大挑戰(zhàn).

4.3 數(shù)據(jù)安全

在微服務(wù)數(shù)據(jù)安全方面，微服務(wù)架構(gòu)在云環(huán)境中應(yīng)用越來越廣泛，微服務(wù)中分布式數(shù)據(jù)隱私信息保護(hù)以及保密性越來越被重視.部分學(xué)者采用密碼學(xué)中傳統(tǒng)加密方式對數(shù)據(jù)進(jìn)行加密.基于密碼學(xué)的加密技術(shù)可以分為對稱與非對稱方法[73-76].對稱加密技術(shù)，即是通過加密密鑰對原始數(shù)據(jù)進(jìn)行加密，反之亦然.非對稱技術(shù)，即是通過公有/私有密鑰對原始數(shù)據(jù)加密，只有相對應(yīng)私有/公有密鑰才能進(jìn)行解密.一般來說,加密密鑰越長，加密后的數(shù)據(jù)也更加安全.然而，這表示在加密與解密過程中產(chǎn)生更大性能開銷[77].基于此，考慮到微服務(wù)模型中數(shù)據(jù)具體應(yīng)用場景與對部分敏感信息的保護(hù)，學(xué)者們力求在計算復(fù)雜度與數(shù)據(jù)安全保護(hù)取得平衡.Shah等人[78]從提高數(shù)據(jù)安全性角度，利用第三方審計協(xié)議，允許用戶評估風(fēng)險并提高降低風(fēng)險的效率；同時還提出了支持在線存儲內(nèi)部服務(wù)和外部審計的數(shù)據(jù)隱私方法.審計目的是監(jiān)控服務(wù)器和網(wǎng)絡(luò)中用戶詳細(xì)行為信息記錄，一旦發(fā)現(xiàn)違反安全策略相關(guān)行為信息，立即向管理員報告.Wang等人[79]僅從數(shù)據(jù)加密角度出發(fā)，并沒有考慮對審計協(xié)議的設(shè)計，由此并不能保證數(shù)據(jù)不會被泄露給第三方平臺.

微服務(wù)是分布式的，即擁有眾多不同的數(shù)據(jù)服務(wù)平臺，由此需對不同數(shù)據(jù)來源加以保護(hù).Callegati等人[80]從數(shù)據(jù)可靠性、完整性和真實(shí)性角度出發(fā)，采取4個步驟進(jìn)行保護(hù)數(shù)據(jù)源:1)提出一個具有可驗(yàn)證性、可問責(zé)性和可生產(chǎn)性的數(shù)據(jù)源管理系統(tǒng),可驗(yàn)證性是指管理體系應(yīng)能夠驗(yàn)證與操作有關(guān)的參與者(或服務(wù))的數(shù)據(jù)源,可問責(zé)性即是指管理系統(tǒng)應(yīng)能夠讓參與者(或服務(wù))對其在數(shù)據(jù)源中的行為負(fù)責(zé),可生產(chǎn)性是指管理系統(tǒng)應(yīng)能夠在數(shù)據(jù)源上生產(chǎn)過程；2)為數(shù)據(jù)流認(rèn)證創(chuàng)建一個私有和公共密鑰系統(tǒng)；3)使用基于密碼學(xué)出處驗(yàn)證方法確認(rèn)數(shù)據(jù)源主機(jī)數(shù)據(jù)屬性與完整性；4)將數(shù)據(jù)元數(shù)據(jù)傳播與密鑰分發(fā)傳播管理相結(jié)合，確保數(shù)據(jù)源管理系統(tǒng)的可靠性.基于以上4個步驟，既可以有效地進(jìn)行微服務(wù)架構(gòu)信息交流，又可以對數(shù)據(jù)來源進(jìn)行有效保護(hù).Subashini等人[81]從企業(yè)數(shù)據(jù)安全的角度，建議對數(shù)據(jù)供應(yīng)商采取額外的安全檢查，以確保數(shù)據(jù)源安全并防止應(yīng)用程序中安全漏洞.企業(yè)數(shù)據(jù)定期備份使用強(qiáng)加密方案，便于在發(fā)生緊急情況時快速進(jìn)行數(shù)據(jù)恢復(fù).Saad等人[82]以對數(shù)據(jù)源全方位保護(hù)角度，建立保障數(shù)據(jù)源存儲與訪問事務(wù)處理安全的信任模型，提高了服務(wù)之間信任度.

基于以上闡述，在微服務(wù)分布式結(jié)構(gòu)中，如何有效保證數(shù)據(jù)源信息的安全以及對第三方平臺數(shù)據(jù)有效認(rèn)證，是十分值得思考的問題.

4.4 網(wǎng)絡(luò)安全

在微服務(wù)網(wǎng)絡(luò)安全方面，首先，數(shù)量眾多的微服務(wù)帶來網(wǎng)絡(luò)復(fù)雜性，增加監(jiān)控整個應(yīng)用程序安全性的難度.其次，微服務(wù)通常被設(shè)計成彼此完全信任，因此單個微服務(wù)的失誤可能會導(dǎo)致整個應(yīng)用程序崩潰.Sun等人[83]從微服務(wù)增加了監(jiān)控整個應(yīng)用程序安全性的難度與單一微服務(wù)失敗會導(dǎo)致整個應(yīng)用程序崩潰的角度，提出了基于微服務(wù)云應(yīng)用安全即服務(wù)(security-as-a-service， SaaS)設(shè)計方案.通過為網(wǎng)絡(luò)管理程序添加一個新的API原語流TAP，進(jìn)而為網(wǎng)絡(luò)流量構(gòu)建了靈活地監(jiān)控和策略強(qiáng)制基礎(chǔ)設(shè)施，以保護(hù)云應(yīng)用程序的安全.基于對監(jiān)控數(shù)據(jù)中心網(wǎng)絡(luò)流量和安全威脅模型、方法和設(shè)備的描述，Ahuja等人[84]擴(kuò)展了安全系統(tǒng)中微服務(wù)的層次結(jié)構(gòu).具體而言，創(chuàng)建第1層次結(jié)構(gòu)的新微服務(wù)，以配置第1層與第2層次結(jié)構(gòu)中微服務(wù)之間的數(shù)據(jù)平面連接；配置第1層與第3層次結(jié)構(gòu)微服務(wù)；同時將新加入的微服務(wù)包括在第1個層次結(jié)構(gòu)的負(fù)載平衡決策中，以提高微服務(wù)網(wǎng)絡(luò)安全性.Ross等人[85]研發(fā)分布式微服務(wù)中提供漏洞掃描系統(tǒng).該系統(tǒng)包括多個微分段環(huán)境，既與云數(shù)據(jù)中心服務(wù)器相關(guān)聯(lián)，又與云環(huán)境的多個微分段環(huán)境耦合.云數(shù)據(jù)中心服務(wù)器具有安全控制器與主動探測控制器，前者為每一個微分段環(huán)境提供安全策略，后者為主動探測微分段環(huán)境設(shè)備，并執(zhí)行漏洞掃描策略.Yarygina等人[86]基于對目前技術(shù)僅對微服務(wù)系統(tǒng)特定安全問題的研究；提供微服務(wù)安全分類，進(jìn)而評估微服務(wù)架構(gòu)的安全性；最后提出相關(guān)合理解決方案，并對Docker Swarm和Netflix的安全決策進(jìn)行分析.

一方面，微服務(wù)安全是一個多方應(yīng)用結(jié)合的問題，目前沒有系統(tǒng)的分層安全解決方案；另一方面，如果這些安全挑戰(zhàn)得到解決，微服務(wù)體系結(jié)構(gòu)的安全性將會大大提高.

5 總結(jié)與展望

目前，國內(nèi)外學(xué)者對基于微服務(wù)技術(shù)的SOA架構(gòu)及其實(shí)現(xiàn)機(jī)制的研究進(jìn)展十分重視，微服務(wù)具有獨(dú)立進(jìn)程、輕量級通信和獨(dú)立部署環(huán)境等顯著的特性；將系統(tǒng)整體功能分解到單個微服務(wù)中以實(shí)現(xiàn)對系統(tǒng)的解耦；這種方式不僅可以降低系統(tǒng)的耦合性，提升系統(tǒng)的內(nèi)聚性，而且減少服務(wù)交互的成本，提供更加靈活的服務(wù)支持.本文從微服務(wù)概念、核心組件與技術(shù)發(fā)展過程、面臨挑戰(zhàn)3個方面進(jìn)行了分析：

1) 論述了微服務(wù)體系結(jié)構(gòu)的產(chǎn)生背景、相關(guān)概念，指出傳統(tǒng)整體架構(gòu)不足及微服務(wù)體系結(jié)構(gòu)發(fā)展背景及優(yōu)勢.

2) 論述了微服務(wù)的核心組件與技術(shù)發(fā)展，前者在服務(wù)發(fā)現(xiàn)機(jī)制、服務(wù)容錯等層面進(jìn)行研究；后者在技術(shù)發(fā)展方面，從微服務(wù)軟件技術(shù)層面以及微服務(wù)架構(gòu)層面2個方面進(jìn)行概述.

3) 基于對核心組件的介紹，進(jìn)而對微服務(wù)關(guān)鍵技術(shù)進(jìn)行分析；提出微服務(wù)在基礎(chǔ)設(shè)施層面、信息交互層面、數(shù)據(jù)安全層面、網(wǎng)絡(luò)安全面臨的四大挑戰(zhàn)以及發(fā)展趨勢.

與傳統(tǒng)開發(fā)模型相同，選擇合適的未來開發(fā)平臺對于微服務(wù)十分重要.微服務(wù)如何與2個主要的新興平臺進(jìn)行集成，即云平臺[87]和物聯(lián)網(wǎng)[88].隨著科技新興技術(shù)與數(shù)據(jù)時代的到來，兩個平臺很可能在互聯(lián)網(wǎng)行業(yè)中占主導(dǎo)地位.由于微服務(wù)本身具有移植性和可伸縮性等特性，在物聯(lián)網(wǎng)上運(yùn)行存在部分難題，若在云平臺中運(yùn)行微服務(wù)似乎是恰當(dāng)?shù)倪x擇.但從系統(tǒng)安全性角度出發(fā)，存在部分功能具有低計算能力且具有較高風(fēng)險的缺點(diǎn).因此，微服務(wù)與具體應(yīng)用平臺相結(jié)合，解決微服務(wù)與平臺相集成的特定實(shí)施方案以及安全方案需求，變得更加迫切.