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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 相關(guān)研究

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

為了避免單體化應(yīng)用的各種問(wèn)題,微服務(wù)應(yīng)運(yùn)而生.這是一種以SOA(面向服務(wù)架構(gòu))為基礎(chǔ)的輕量級(jí)架構(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ù)的簡(jiǎn)潔性,允許開發(fā)團(tuán)隊(duì)在云環(huán)境中快速擴(kuò)展、部署應(yīng)用,這是一種面向云計(jì)算的持續(xù)解決方案.

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

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

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

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

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

2.1 單體化架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

對(duì)于微服務(wù)架構(gòu)來(lái)說(shuō),根據(jù)不同的業(yè)務(wù)實(shí)現(xiàn),系統(tǒng)被拆分為多個(gè)獨(dú)立的服務(wù)模塊,合理劃分系統(tǒng)的功能模塊很重要,由于本貸款系統(tǒng)業(yè)務(wù)邏輯簡(jiǎn)單,即可將其劃分為兩個(gè)微服務(wù)uS1和uS2,分別對(duì)應(yīng)單體化架構(gòu)中的S1和S2.微服務(wù)間通過(guò)有限的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ā)起請(qǐng)求時(shí),由于微服務(wù)架構(gòu)包含多個(gè)服務(wù)模塊,客戶端完成一次業(yè)務(wù)邏輯往往需要發(fā)送多個(gè)HTTP請(qǐng)求,這會(huì)造成應(yīng)用系統(tǒng)的吞吐量下降,在高延遲的網(wǎng)絡(luò)環(huán)境下更會(huì)影響用戶體驗(yàn).因此,不同于單體化應(yīng)用,微服務(wù)需要通過(guò)加入門戶應(yīng)用程序(Gateways application)提高系統(tǒng)性能.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

系統(tǒng)包含關(guān)系型數(shù)據(jù)庫(kù),數(shù)據(jù)操作通過(guò)EBeans實(shí)現(xiàn).EBeans ORM是一種快速、簡(jiǎn)單的數(shù)據(jù)訪問(wèn)結(jié)構(gòu),也是Play默認(rèn)的對(duì)象關(guān)系映射模型,在瀏覽器端執(zhí)行的應(yīng)用程序用Angular.js實(shí)現(xiàn),因?yàn)樗芎芎玫闹С諫oogle.

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

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

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

1.3.14 (HTML5,CSS和JQuery).

微服務(wù)架構(gòu)系統(tǒng)由四個(gè)相對(duì)獨(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ù)庫(kù)用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)上,并通過(guò)對(duì)系統(tǒng)的性能測(cè)試選出滿足表1所示業(yè)務(wù)需求的AWS實(shí)例.例如,對(duì)單體化Play架構(gòu)系統(tǒng)的性能測(cè)試以C4簇(c4.large、c4.xlarge、c4.2xlarge)實(shí)例為測(cè)試用例,其中c4.2xlarge能很好地滿足表1中的業(yè)務(wù)需求,即采用c4.2xlarge實(shí)例.

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

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

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

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

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

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

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

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

③ 門戶應(yīng)用:Web應(yīng)用部署在EC2的m3.medium型實(shí)例上,配置參數(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)的帶寬、存儲(chǔ)等因素在兩種架構(gòu)中保持一致.

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

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

4 實(shí)驗(yàn)結(jié)果分析

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

4.1 性能

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

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

1)微服務(wù)不會(huì)因?yàn)槭褂梅?wù)主機(jī)數(shù)量過(guò)多而導(dǎo)致響應(yīng)時(shí)間的延遲;

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

4.2 開發(fā)方法

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

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

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

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

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

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

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

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

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

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

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

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

下一步我們將對(duì)微服務(wù)架構(gòu)的各方面性能做進(jìn)一步評(píng)估,比如更大粒度的可擴(kuò)展性和更低的資源開銷,如何劃分微服務(wù)也是我們需要重點(diǎn)考慮的一個(gè)問(wèn)題.微服務(wù)和門戶應(yīng)用的自動(dòng)化部署采用不同的策略、工具和云服務(wù)管理器進(jìn)行評(píng)估.后續(xù)工作還包括評(píng)估微服務(wù)的一些其他特性,如容錯(cuò)能力、分布式事務(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;收到修改稿時(shí)間:2016-09-23

10.15888/j.cnki.csa.005746