云環(huán)境中Web應(yīng)用的微服務(wù)架構(gòu)評估①

王紀(jì)軍,張 斌,顧永生,高沈剛

(江蘇電力信息技術(shù)有限公司,南京 210024)

云環(huán)境中Web應(yīng)用的微服務(wù)架構(gòu)評估①

王紀(jì)軍,張 斌,顧永生,高沈剛

(江蘇電力信息技術(shù)有限公司,南京 210024)

云計算為我們提供了一種全新、高效的方式來部署可擴(kuò)展的Web應(yīng)用,這種方式使企業(yè)的應(yīng)用可以按需對計算資源進(jìn)行分配.微服務(wù)架構(gòu)用于將龐大復(fù)雜的應(yīng)用系統(tǒng)拆分為一系列可獨(dú)立開發(fā)、測試、部署、運(yùn)行、升級的服務(wù)模塊.微服務(wù)架構(gòu)為大批互聯(lián)網(wǎng)企業(yè)實現(xiàn)云環(huán)境中的應(yīng)用擴(kuò)展、降低應(yīng)用開發(fā)復(fù)雜度、實現(xiàn)敏捷開發(fā)提供了更加有效地方法.本文分析并測試了微服務(wù)架構(gòu)模式,通過一個具體案例--在云環(huán)境中開發(fā)和部署的企業(yè)級應(yīng)用系統(tǒng),對兩種架構(gòu)模式實現(xiàn)(單體架構(gòu)模式和微服務(wù)架構(gòu)模式)進(jìn)行性能測試,得出評估結(jié)果,這些結(jié)果對解決企業(yè)級應(yīng)用微服務(wù)化中可能遇到的問題具有一定指導(dǎo)意義.

云平臺;微服務(wù);持續(xù)交付;可擴(kuò)展應(yīng)用

云計算[1]提供了一種面向企業(yè)應(yīng)用的可實現(xiàn)按需分配計算資源的模型,企業(yè)可以將應(yīng)用部署在IaaS[2]、PaaS[3]或者SaaS[4]服務(wù)平臺上.對于IaaS和PaaS服務(wù)平臺的應(yīng)用部署來說,很多企業(yè)僅僅實現(xiàn)了原有應(yīng)用單體化架構(gòu)的遷移部署.為了充分發(fā)揮云計算平臺的性能優(yōu)勢,他們將面對很多挑戰(zhàn),比如:彈性擴(kuò)展、持續(xù)交付、熱部署、動態(tài)監(jiān)控和高可用性等.

企業(yè)選擇將系統(tǒng)遷移到IaaS、PaaS服務(wù)平臺的主要原因是為了獲取更高的系統(tǒng)執(zhí)行效率,提高系統(tǒng)性能,以及實現(xiàn)按需對應(yīng)用進(jìn)行動態(tài)擴(kuò)展.對于采用三層模型(表現(xiàn)層、業(yè)務(wù)層、持久層)的Web應(yīng)用來說,可使用不同技術(shù)棧實現(xiàn)整個Web應(yīng)用,如J2EE、.NET、PHP等,由于所用的技術(shù)棧不同,應(yīng)用系統(tǒng)不能高效的按需增加或刪除服務(wù)模塊[5],在實現(xiàn)云環(huán)境的部署遷移過程中可能會遇到很多問題[6].

對大部分企業(yè)來說,創(chuàng)新至關(guān)重要,當(dāng)系統(tǒng)實現(xiàn)了新的創(chuàng)新點(diǎn)與功能點(diǎn)時,需要完成從系統(tǒng)開發(fā)到應(yīng)用云端部署的快速迭代更新,以此提升系統(tǒng)應(yīng)用的用戶體驗.這也是大型互聯(lián)網(wǎng)公司和SaaS提供者一直強(qiáng)調(diào)持續(xù)交付的重要原因[7].

在單體化應(yīng)用中,所有的服務(wù)都由一個統(tǒng)一的代碼庫實現(xiàn),由開發(fā)者團(tuán)隊共同維護(hù).當(dāng)某個開發(fā)者想要修改指定服務(wù)時,必須保證其它所有服務(wù)不受影響.隨著應(yīng)用越來越大,服務(wù)越來越多,擴(kuò)展、修改某個服務(wù)將變得異常復(fù)雜.除此之外,單體化應(yīng)用的更新部署需要重啟所有服務(wù)(包括系統(tǒng)中未更新的服務(wù)),而且,單體化應(yīng)用具有單節(jié)點(diǎn)失效性,即只要一個服務(wù)出現(xiàn)問題,整個應(yīng)用系統(tǒng)全部宕機(jī).

很多大型互聯(lián)網(wǎng)公司已經(jīng)意識到單體化架構(gòu)的局限性,他們開始采用一種新的應(yīng)用系統(tǒng)架構(gòu)應(yīng)對出現(xiàn)的問題:微服務(wù)架構(gòu)[8].

微服務(wù)概念由Martin Fowler與James Lewis于2014年提出,短短幾年時間內(nèi)已有越來越多的公司開始嘗試使用微服務(wù)架構(gòu)構(gòu)建圍繞業(yè)務(wù)、細(xì)粒度的分布式系統(tǒng).例如:唯品會通過使用自研的服務(wù)化框架,核心業(yè)務(wù)已經(jīng)全面實現(xiàn)微服務(wù)化,同時構(gòu)建了基于大數(shù)據(jù)體系的新一代全鏈路監(jiān)控系統(tǒng)來支撐微服務(wù)化的監(jiān)控;今日頭條通過將系統(tǒng)從Mono架構(gòu)遷移到微服務(wù)架構(gòu)來應(yīng)對架構(gòu)和基礎(chǔ)設(shè)施在性能及其優(yōu)化、穩(wěn)定性、可運(yùn)維性、可擴(kuò)展性、開發(fā)迭代速度等方面的挑戰(zhàn);電商CRM通過微服務(wù)架構(gòu)的應(yīng)用重構(gòu)了原來臃腫低效的CRM系統(tǒng),讓每個服務(wù)小團(tuán)隊專注自己的業(yè)務(wù)快速迭代.

微服務(wù)架構(gòu)可以幫助企業(yè)將新的功能點(diǎn)快速迭代到生產(chǎn)環(huán)境中,減少開發(fā)、部署的復(fù)雜性、降低資源消耗.對于功能點(diǎn)眾多、業(yè)務(wù)邏輯復(fù)雜的大型應(yīng)用系統(tǒng)來說,采用微服務(wù)架構(gòu)可以有效提高系統(tǒng)開發(fā)效率及容錯性,便于實現(xiàn)系統(tǒng)功能點(diǎn)及集群的擴(kuò)展.此外,應(yīng)用系統(tǒng)的微服務(wù)化可現(xiàn)實服務(wù)模塊的單獨(dú)部署,讓持續(xù)部署成為可能.微服務(wù)架構(gòu)模式正在為敏捷部署以及復(fù)雜企業(yè)應(yīng)用實施提供著巨大的幫助.

論文的內(nèi)容組織:文章的第一部分主要介紹了當(dāng)前的研究背景及微服務(wù)架構(gòu)的優(yōu)勢.第二部分通過一個典型應(yīng)用對比了單體化及微服務(wù)架構(gòu)的特點(diǎn).第三部分實現(xiàn)了典型應(yīng)用在亞馬遜的Web服務(wù)基礎(chǔ)設(shè)施中的部署,包括單體化和微服務(wù)化兩種架構(gòu).第四部分對已部署的單體化及微服務(wù)化應(yīng)用進(jìn)行測試,并分析測試結(jié)果.最后一部分對論文工作進(jìn)行了總結(jié)并對進(jìn)一步工作做了簡單介紹.

1 相關(guān)研究

一個企業(yè)級的單體化應(yīng)用系統(tǒng)通常由統(tǒng)一的代碼庫維護(hù)所有服務(wù)接口,所有開發(fā)人員共享這個代碼庫.單體化應(yīng)用代碼的緊耦合特性會增加系統(tǒng)擴(kuò)展工作的復(fù)雜度,當(dāng)應(yīng)用系統(tǒng)需要對某些服務(wù)或者功能進(jìn)行修改和擴(kuò)展時,整個過程將變得十分復(fù)雜.

為了避免單體化應(yīng)用的各種問題,微服務(wù)應(yīng)運(yùn)而生.這是一種以SOA(面向服務(wù)架構(gòu))為基礎(chǔ)的輕量級架構(gòu)模式,現(xiàn)在已經(jīng)被Amazon[9]、NetFlix[10]、Gilt[11]、LinkedIn[12]、SoundCloud[13]等公司應(yīng)用到系統(tǒng)中.微服務(wù)架構(gòu)強(qiáng)調(diào)敏捷開發(fā)[14]、業(yè)務(wù)邏輯和技術(shù)的簡潔性,允許開發(fā)團(tuán)隊在云環(huán)境中快速擴(kuò)展、部署應(yīng)用,這是一種面向云計算的持續(xù)解決方案.

微服務(wù)架構(gòu)[15]就是把原來的一個提供n種服務(wù)的應(yīng)用模塊劃分為若干個獨(dú)立的服務(wù)模塊,原來應(yīng)用的所有服務(wù)功能都由這些服務(wù)模塊分別實現(xiàn).每一個微服務(wù)都是一個相對獨(dú)立的個體,由專門的開發(fā)團(tuán)隊獨(dú)立開發(fā)、測試、部署,至于采用哪種技術(shù)棧,完全取決于本微服務(wù)模塊,不必考慮其他服務(wù)以及后期集成、部署等問題.在表現(xiàn)層,所有的微服務(wù)都發(fā)布成REST[16]風(fēng)格的接口.

盡管微服務(wù)架構(gòu)在一些企業(yè)中得到了很好的應(yīng)用,滿足云環(huán)境中高效的動態(tài)擴(kuò)展企業(yè)應(yīng)用系統(tǒng)的需求,減少復(fù)雜性、使開發(fā)團(tuán)隊管理更加容易,但對一個沒有微服務(wù)經(jīng)驗的企業(yè)來說,采用微服務(wù)架構(gòu)具有一定挑戰(zhàn)性.本文用單體化及微服務(wù)架構(gòu)分別實現(xiàn)一個小型應(yīng)用系統(tǒng),比較兩種架構(gòu)的表現(xiàn).

2 單體化及微服務(wù)化架構(gòu)特點(diǎn)

以一個包含兩種業(yè)務(wù)邏輯的應(yīng)用系統(tǒng)為例,對兩種架構(gòu)及系統(tǒng)部署的特點(diǎn)進(jìn)行說明比較.

應(yīng)用系統(tǒng)業(yè)務(wù)流程為:查詢和產(chǎn)生某個貸款用戶的還款計劃.為了便于研究,將其抽象為兩個主要服務(wù).服務(wù)S1:CPU密集型操作,負(fù)責(zé)產(chǎn)生還款計劃;服務(wù)S2:接收還款計劃對應(yīng)的ID,通過數(shù)據(jù)庫查詢操作返回這個還款計劃的所有相關(guān)信息.

2.1 單體化架構(gòu)

對于單體化架構(gòu)來說,整個系統(tǒng)的實現(xiàn)包含在一個應(yīng)用中,應(yīng)用在水平方向采用分層架構(gòu),從上至下依次為表現(xiàn)層、業(yè)務(wù)層、持久層等.雖然水平分層降低了業(yè)務(wù)復(fù)雜性,但由于垂直方向缺乏清晰的邊界,針對不同業(yè)務(wù)的處理邏輯相互耦合,因此對于廣度上具有復(fù)雜業(yè)務(wù)的系統(tǒng),單體化架構(gòu)會帶來一系列問題.

對于本貸款業(yè)務(wù)系統(tǒng)來說,服務(wù)S1和服務(wù)S2被實現(xiàn)于一個Web應(yīng)用中,系統(tǒng)實現(xiàn)需要一個統(tǒng)一的代碼庫,其架構(gòu)如圖1所示.

圖1 單體化架構(gòu)

單體化架構(gòu)實現(xiàn)此貸款業(yè)務(wù)系統(tǒng)具有如下特點(diǎn):

1)所有服務(wù)實現(xiàn)于一個應(yīng)用中,易于部署;

2)代碼依賴關(guān)系復(fù)雜,不易于管理維護(hù);

3)局部修改影響不可知,例如,開發(fā)人員修改服務(wù)S1可能造成系統(tǒng)整體出現(xiàn)問題;

4)不易于實現(xiàn)功能調(diào)整及增加,例如,開發(fā)人員增加功能點(diǎn)后,可能會對S1及S2服務(wù)造成影響,需要對系統(tǒng)進(jìn)行全覆蓋測試并重新部署;

5)當(dāng)需要增加硬件資源以應(yīng)對更大的業(yè)務(wù)量時,無法做到針對指定服務(wù)的硬件調(diào)整,由于不同模塊對資源需求差異大,整體的硬件增加會造成資源浪費(fèi).

單化架構(gòu)實現(xiàn)的應(yīng)用系統(tǒng)提供兩個REST風(fēng)格的接口(分別對應(yīng)S1和S2)供Web前端調(diào)用.Web前端應(yīng)用是一個輕量級應(yīng)用,負(fù)責(zé)接收終端用戶的請求(來自瀏覽器),得到服務(wù)端單體化應(yīng)用對請求的處理結(jié)果并將其返回終端.前端應(yīng)用和終端(瀏覽器)之間通過自定義的消息協(xié)議交換消息(JSON格式).

此外,為了提高系統(tǒng)響應(yīng)效率,在Web前端和服務(wù)端間增加負(fù)載均衡服務(wù)器,將單體化應(yīng)用部署在多臺Web服務(wù)器中.對單體化架構(gòu)來說,所有部署了應(yīng)用系統(tǒng)的節(jié)點(diǎn)均包含對數(shù)據(jù)庫的查詢操作實現(xiàn),關(guān)系型數(shù)據(jù)庫存儲了用戶的貸款信息.

部署到云環(huán)境中的系統(tǒng)架構(gòu)圖如圖2所示.

圖2 單體化系統(tǒng)部署架構(gòu)(示意圖)

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

對于微服務(wù)架構(gòu)來說,根據(jù)不同的業(yè)務(wù)實現(xiàn),系統(tǒng)被拆分為多個獨(dú)立的服務(wù)模塊,合理劃分系統(tǒng)的功能模塊很重要,由于本貸款系統(tǒng)業(yè)務(wù)邏輯簡單,即可將其劃分為兩個微服務(wù)uS1和uS2,分別對應(yīng)單體化架構(gòu)中的S1和S2.微服務(wù)間通過有限的API接口相互關(guān)聯(lián),通訊協(xié)議一般使用HTTP,數(shù)據(jù)格式為JSON,系統(tǒng)架構(gòu)如圖3所示.

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

當(dāng)客戶端向應(yīng)用系統(tǒng)發(fā)起請求時,由于微服務(wù)架構(gòu)包含多個服務(wù)模塊,客戶端完成一次業(yè)務(wù)邏輯往往需要發(fā)送多個HTTP請求,這會造成應(yīng)用系統(tǒng)的吞吐量下降,在高延遲的網(wǎng)絡(luò)環(huán)境下更會影響用戶體驗.因此,不同于單體化應(yīng)用,微服務(wù)需要通過加入門戶應(yīng)用程序(Gateways application)提高系統(tǒng)性能.

門戶應(yīng)用負(fù)責(zé)為不同類型的終端用戶提供相應(yīng)的服務(wù)接口,它可以將客戶端請求轉(zhuǎn)換為一組內(nèi)部服務(wù)的調(diào)用.此外,門戶應(yīng)用可減小客戶端與微服務(wù)的關(guān)聯(lián)性,服務(wù)器升級將不再影響客戶端.

門戶應(yīng)用程序和微服務(wù)一樣,由一個單獨(dú)的開發(fā)團(tuán)隊負(fù)責(zé)開發(fā)、測試、部署、維護(hù)、擴(kuò)展和升級.微服務(wù)通過門戶應(yīng)用程序向外界提供服務(wù).

微服務(wù)架構(gòu)實現(xiàn)此貸款業(yè)務(wù)系統(tǒng)具有如下特點(diǎn):

1)每個微服務(wù)足夠內(nèi)聚(只包含S1或S2),易于代碼的開發(fā)與理解;

2)不同服務(wù)部署相對獨(dú)立,例如,對uS2微服務(wù)進(jìn)行更新只需重部署此模塊,uS1在此期間保持正常對外提供服務(wù);

3)易于實現(xiàn)功能和集群擴(kuò)展,可將不同服務(wù)部署于合適的節(jié)點(diǎn),如將uS1部署于高CPU性能節(jié)點(diǎn),uS2部署于大內(nèi)存節(jié)點(diǎn);

4)提高系統(tǒng)容錯性,例如,uS2發(fā)生內(nèi)存泄漏不會致使整個系統(tǒng)癱瘓;

5)能夠隨著業(yè)務(wù)需求的變化靈活調(diào)整、增加系統(tǒng)功能,不受所用技術(shù)的限制.

微服務(wù)在云環(huán)境中的部署架構(gòu)如圖4所示.為了提高系統(tǒng)的可擴(kuò)展性,每一個微服務(wù)均可獨(dú)立擴(kuò)展.微服務(wù)uS1使用一個負(fù)載均衡服務(wù)器及若干Web服務(wù)器完成部署.微服務(wù)uS2除了上述服務(wù)器外還需要一個關(guān)系型數(shù)據(jù)庫存儲相關(guān)數(shù)據(jù).

不同于單體架構(gòu),微服務(wù)化的貸款業(yè)務(wù)系統(tǒng)只有uS2所部署的節(jié)點(diǎn)才會與數(shù)據(jù)庫交互,其他節(jié)點(diǎn)不包含數(shù)據(jù)庫訪問客戶端.

此外,為了提高系統(tǒng)執(zhí)行效率,門戶應(yīng)用同樣采用負(fù)載均衡機(jī)制.

3 單體及微服務(wù)化應(yīng)用的云化部署

以第二部分提到的貸款業(yè)務(wù)系統(tǒng)為例實現(xiàn)兩種架構(gòu)的云化部署.系統(tǒng)中包含的兩個服務(wù)的業(yè)務(wù)需求如表1所示.

圖4 微服務(wù)部署架構(gòu)(示意圖)

表1 兩個服務(wù)的業(yè)務(wù)需求

兩種架構(gòu)均采用Play Web框架[17]實現(xiàn).Play框架是一種輕量級的、無狀態(tài)的、異步的云友好框架.采用Play框架的應(yīng)用程序可以部署在Netty服務(wù)器上,這是一種啟動速度快并且節(jié)約計算資源的服務(wù)器.

系統(tǒng)包含關(guān)系型數(shù)據(jù)庫,數(shù)據(jù)操作通過EBeans實現(xiàn).EBeans ORM是一種快速、簡單的數(shù)據(jù)訪問結(jié)構(gòu),也是Play默認(rèn)的對象關(guān)系映射模型,在瀏覽器端執(zhí)行的應(yīng)用程序用Angular.js實現(xiàn),因為它能很好的支持Google.

單體化架構(gòu)系統(tǒng)由兩個相對獨(dú)立的應(yīng)用模塊組成,使用技術(shù)棧及框架如下:

① Web應(yīng)用:該模塊的開發(fā)采用 Play2.2.2, Scala2.10.2和Java1.7.0,數(shù)據(jù)庫用PostgreSQL9.3.6.

② 前端應(yīng)用:該模塊的開發(fā)采用 Angular.js

1.3.14 (HTML5,CSS和JQuery).

微服務(wù)架構(gòu)系統(tǒng)由四個相對獨(dú)立的應(yīng)用模塊組成,使用技術(shù)棧及框架如下:

① 微服務(wù)uS1:該模塊的開發(fā)采用Play2.2.2, Scala2.10.2和Java1.7.0.

② 微服務(wù) uS2:該模塊的開發(fā)采用 Play2.2.2, Scala2.10.2和Java1.7.0,數(shù)據(jù)庫用PostgreSQL9.3.6.

③ 門戶應(yīng)用(Gateway application):該模塊的開發(fā)采用Play2.2.2,Scala2.10.2和Java1.7.0.

④ 前端應(yīng)用:該模塊的開發(fā)采用 Angular.js

1.3.14 (HTML5,CSS和JQuery).

為了比較部署在云環(huán)境中的不同架構(gòu)系統(tǒng)的表現(xiàn),將兩種架構(gòu)系統(tǒng)均部署在AWS(Amazon Web Service)上,并通過對系統(tǒng)的性能測試選出滿足表1所示業(yè)務(wù)需求的AWS實例.例如,對單體化Play架構(gòu)系統(tǒng)的性能測試以C4簇(c4.large、c4.xlarge、c4.2xlarge)實例為測試用例,其中c4.2xlarge能很好地滿足表1中的業(yè)務(wù)需求,即采用c4.2xlarge實例.

3.1 單體化架構(gòu)云端部署

單體化架構(gòu)云端部署采用圖1所示結(jié)構(gòu),其中的Web應(yīng)用及前端應(yīng)用所用AWS實例如下所示:

①Web應(yīng)用:Web應(yīng)用部署在EC2的c4.2xlarge型實例上,配置參數(shù):8 vCPUs,,31 ECUs和15GB RAM,服務(wù)器:Netty3.7.0,數(shù)據(jù)庫用AWS提供的db.m3.medium型實例(1 vCPU和 3.75GB RAM).

② 前端應(yīng)用:Angular.js的一些靜態(tài)文件存儲在Play的Web服務(wù)器上,通過本地緩存方式響應(yīng)請求.

3.2 微服務(wù)架構(gòu)云端部署

微服務(wù)架構(gòu)云端部署采用圖3所示結(jié)構(gòu),其中的微服務(wù)uS1、uS2、門戶應(yīng)用及前端應(yīng)用所用AWS實例如下所示:

① 微服務(wù)uS1:Web應(yīng)用部署在EC2的c4.xlarge型實例上,配置參數(shù):4 vCPUs,16 ECUs和7.5GB RAM,服務(wù)器:Netty3.7.0.

② 微服務(wù) uS2:Web應(yīng)用部署在 EC2的m3.medium型實例上,配置參數(shù):1 vCPUs,3 ECUs和7.5GB RAM,服務(wù)器:Netty3.7.0.數(shù)據(jù)庫用AWS提供的db.m3.medium型實例(1 vCPU和 3.75GB RAM).

③ 門戶應(yīng)用:Web應(yīng)用部署在EC2的m3.medium型實例上,配置參數(shù):1 vCPUs,3 ECUs和7.5GB RAM,服務(wù)器:Netty3.7.0.

④ 前端應(yīng)用:與單體化應(yīng)用架構(gòu)前端部署情況類似.

兩種架構(gòu)的系統(tǒng)運(yùn)行開銷如表2和表3所示,與開銷相關(guān)的帶寬、存儲等因素在兩種架構(gòu)中保持一致.

表2 單體化架構(gòu)部署的基礎(chǔ)設(shè)施開銷

表3 微服務(wù)架構(gòu)部署的基礎(chǔ)設(shè)施開銷

4 實驗結(jié)果分析

對比單體化架構(gòu)和微服務(wù)架構(gòu)測試數(shù)據(jù),從應(yīng)用系統(tǒng)的性能、部署、開發(fā)等方面分析實驗結(jié)果,得出詳細(xì)結(jié)論.

4.1 性能

在滿足表1中業(yè)務(wù)需求的前提下分析兩種架構(gòu)性能表現(xiàn),我們采用AWS上相同的實例JMter[18]2.13進(jìn)行比較.在測試中,通過配置JMter模擬一個穩(wěn)定的工作負(fù)載,對服務(wù)1每分鐘執(zhí)行30個請求,服務(wù)2每分鐘執(zhí)行1100個請求.

兩種框架每個服務(wù)的平均響應(yīng)時間和90%響應(yīng)時間線如圖5和圖6所示.從圖中可以看出,這兩種框架都滿足了表1提出的業(yè)務(wù)需求,并驗證了如下結(jié)論:

1)微服務(wù)不會因為使用服務(wù)主機(jī)數(shù)量過多而導(dǎo)致響應(yīng)時間的延遲;

2)微服務(wù)允許更大粒度的實例類型減少系統(tǒng)開銷.在本例中微服務(wù)架構(gòu)減少17%的基礎(chǔ)設(shè)施服務(wù)開銷(根據(jù)表2和表3).

4.2 開發(fā)方法

不同于單體化架構(gòu)系統(tǒng)開發(fā)中使用的統(tǒng)一代碼庫,微服務(wù)架構(gòu)的每個開發(fā)團(tuán)隊都是相對獨(dú)立的,他們無需關(guān)心其他微服務(wù)開發(fā)團(tuán)隊的工作細(xì)節(jié),只負(fù)責(zé)自己的微服務(wù)模塊,每個開發(fā)團(tuán)隊都可以根據(jù)各自的技術(shù)特點(diǎn)和業(yè)務(wù)需求使用不同的技術(shù)棧實現(xiàn)微服務(wù).

圖5 單體化架構(gòu)和微服務(wù)架構(gòu)的平均響應(yīng)時間

圖6 單體化架構(gòu)和微服務(wù)架構(gòu)90%響應(yīng)時間線

微服務(wù)架構(gòu)系統(tǒng)開發(fā)過程中應(yīng)遵循以下原則:

1)為了避免使用技術(shù)過多不便管理,通過制定相關(guān)技術(shù)準(zhǔn)則規(guī)范所有團(tuán)隊可以使用的技術(shù)集;

2)通過制定詳細(xì)的規(guī)范文檔、合理設(shè)計每個微服務(wù)模塊及對外發(fā)布的REST API接口,保證微服務(wù)提供的功能模塊能很好的被調(diào)用;

3)保證門戶應(yīng)用提供的服務(wù)便于前端應(yīng)用(瀏覽器、安卓、IOS)調(diào)用.

4.3 部署、擴(kuò)展和持續(xù)交付

對微服務(wù)架構(gòu)應(yīng)用系統(tǒng)而言,新版本的發(fā)布容易破壞其外部原本依賴的一些服務(wù),通過引入服務(wù)版本控制,可避免新服務(wù)加入或舊服務(wù)過期造成的系統(tǒng)依賴異常問題.

在微服務(wù)中,持續(xù)交付耗時耗力,因為持續(xù)交付要求每一次部署工作的重復(fù)性手動任務(wù)被正確執(zhí)行通過,當(dāng)然,通過一些自動化工具可以節(jié)省時間,提高交付效率.微服務(wù)的部署工作也涉及Devops,開發(fā)部署一體化,提供云環(huán)境下的檢測和運(yùn)行機(jī)制.對于部署在AWS上的服務(wù),我們可以通過New Relic很方便的檢測其運(yùn)行狀態(tài),但是不得不面對一個重要問題,即在部署的過程中無法很好的跟蹤從終端用戶到微服務(wù)的請求流程.

5 結(jié)論和進(jìn)一步工作

通過本文的實驗結(jié)果分析,我們看到了微服務(wù)架構(gòu)的一些優(yōu)勢和不足,其最突出的優(yōu)勢是可以把一個復(fù)雜應(yīng)用拆分為一系列功能明確的服務(wù)模塊,每個服務(wù)模塊由專門的開發(fā)團(tuán)隊負(fù)責(zé),獨(dú)立于其他服務(wù)模塊,可以單獨(dú)開發(fā)、測試、部署和擴(kuò)展升級.同時,不同于單體化架構(gòu)的統(tǒng)一代碼庫模式,微服務(wù)架構(gòu)應(yīng)用系統(tǒng)中的每一個微服務(wù)都有各自的代碼庫,各自維護(hù).

下一步我們將對微服務(wù)架構(gòu)的各方面性能做進(jìn)一步評估,比如更大粒度的可擴(kuò)展性和更低的資源開銷,如何劃分微服務(wù)也是我們需要重點(diǎn)考慮的一個問題.微服務(wù)和門戶應(yīng)用的自動化部署采用不同的策略、工具和云服務(wù)管理器進(jìn)行評估.后續(xù)工作還包括評估微服務(wù)的一些其他特性,如容錯能力、分布式事務(wù)、異構(gòu)數(shù)據(jù)分布、服務(wù)版本控制及微服務(wù)的可靠性保障等.

1 BuyyaR.Cloud computing:Thenextrevolution in information technology.The 1st International Conference on Parallel Distributed and Grid Computing(PDGC).Solan. 2010.2–3.

2 Vosshall P.Web scale computing:The power of infrastructure as a service.Athman Bouguettaya,Ingolf Krueger,and Tiziana Margaria,Service-Oriented Computing–ICSOC 2008. Berlin.Springer.2008,1.

3 Beimborn D,Miletzki T,Wenzel S.Platform as a Service (PaaS).Business&Information Systems Engineering,2011, 3(6):381–384.

4 Schütz SW,Kude T,Popp KM.The impactof software-as-a-service on software ecosystems. Georg Herzwurm and Tiziana Margaria,Eds.Software Business. From Physical Products to Software Services and Solutions. Berlin.Springer.2013.130–140.

5 Lorido-Botran T,Miguel-Alonso J,Lozano JA.A review of auto-scaling techniques for elastic applications in cloud environments.Journal of Grid Computing,2014,12(4): 559–592.

6 Cretella G,Di MB.An overview of approaches for the migration of applications to the cloud.Caporarello L,Di Martino B,Martinez M,eds.Smart Organizations and Smart Artifacts.Berlin.Springer.2014.67–75.

7 Rossberg J,Olausson M.ContinuousDelivery.Proc Application Lifecycle Management with Visual Studio 2012. BerkeleyApress.2012.425–432.

8 Lewis J,Fowler M.Microservices.http://martinfowler.com/ articles/microservices.html.[2014-03].

9 Kramer S.GIGAOM.The biggest thing Amazon got right: The Platform. https://gigaom.com/2011/10/12/ 419-thebiggest-thing-amazon-got-right-the-platform/.[2011-10-12].

10 Mauro T.Nginx.Adopting microservices at Netflix:Lessons for architectural design.http://nginx.com/blog/microservicesat-netflix-architectural-best-practices/.[2015-02].

11 Goldberg Y.InfoQ.Scaling Gilt:From monolithic ruby application to distributed scala micro-services architecture. http://www.infoq.com/presentations/scale-gilt.[2014-10].

12 Ihde S.InfoQ.From a monolith to microservices+REST: The evolution of linkedIn’s service architecture. http://www.infoq.com/presentations/linkedin-microservices-urn. [2015-03].

13 Cal?ado P.SoundCloud.Building products at SoundCloud-Part I:Dealing with the Monolith.https://developers. soundcloud.com/blog/building-products-at-soundcloud-part-1-dealing-with-the-monolith.[2014-06].

14 Lawton G.TechTarget.How microservices bring agility to SOA. http://searchcloudapplications.techtarget.com/feature/How-micr oservices-bring-agility-to-SOA.[2015-01].

15 Richardson C.Microservices.Pattern:Microservices architecture.http://microservices.io/patterns/microservices. html.[2014-03].

16 Vinoski S.REST eye for the SOA guy.IEEE Internet Computing,2007,11(1):82–84.

17 Hunt J.Play Framework.A Beginner’s Guide to Scala, Object Orientation and Functional Programming.Berlin: Springer,2014:413–428.

18 Rahmel D.Testing a Site with ApacheBench,JMeter,and Selenium.Advanced Joomla!Berkeley:Apress,2013: 211–247.

Evaluation of Micro-ServiceArchitecture for WebApplication in the Cloud

WANG Ji-Jun,ZHANG Bin,GU Yong-Sheng,GAO Shen-Gang

(Jiangsu Electric Power Information Technology Co.Ltd.,Nanjing 210024,China)

Cloud computing provides a pretty new and efficient way to deploy scalable web application.In this way,it can allocate their computing resource on business requirements for enterprise applications.Micro-service architecture is used to split large applications into a series of small modules that can be developed,tested,deployed,operated and upgraded independently.Micro-service architecture provides a more efficient way for a large number of Internet companies to expand their applications in the cloud,reduce complexity of application development and gain agility.In this paper we analyze and test the micro-service architecture model in a specific case-we develop and deploy the enterprise application system in the cloud to implement performance tests of two architectures(single-mode architecture and micro-service architecture mode),and we can acquire the evaluation result.These results have some guiding significance for solving the problems that may be encountered in the micro-service application of enterprise application.

cloud platform;micro-service;continuous delivery;scalable applications

2016-08-09;收到修改稿時間:2016-09-23

10.15888/j.cnki.csa.005746