王紀軍,張 斌,顧永生,高沈剛

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

云環(huán)境中Web應用的微服務架構評估①

王紀軍,張 斌,顧永生,高沈剛

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

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

云平臺;微服務;持續(xù)交付;可擴展應用

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

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

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

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

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

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

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

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

1 相關研究

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

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

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

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

2 單體化及微服務化架構特點

以一個包含兩種業(yè)務邏輯的應用系統(tǒng)為例,對兩種架構及系統(tǒng)部署的特點進行說明比較.

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

2.1 單體化架構

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

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

圖1 單體化架構

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

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

2)代碼依賴關系復雜,不易于管理維護;

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

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

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

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

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

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

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

2.2 微服務架構

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

圖3 微服務架構

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

門戶應用負責為不同類型的終端用戶提供相應的服務接口,它可以將客戶端請求轉換為一組內部服務的調用.此外,門戶應用可減小客戶端與微服務的關聯(lián)性,服務器升級將不再影響客戶端.

門戶應用程序和微服務一樣,由一個單獨的開發(fā)團隊負責開發(fā)、測試、部署、維護、擴展和升級.微服務通過門戶應用程序向外界提供服務.

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

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

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

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

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

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

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

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

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

3 單體及微服務化應用的云化部署

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

圖4 微服務部署架構(示意圖)

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

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

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

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

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

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

1.3.14 (HTML5,CSS和JQuery).

微服務架構系統(tǒng)由四個相對獨立的應用模塊組成,使用技術棧及框架如下:

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

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

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

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

1.3.14 (HTML5,CSS和JQuery).

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

3.1 單體化架構云端部署

單體化架構云端部署采用圖1所示結構,其中的Web應用及前端應用所用AWS實例如下所示:

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

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

3.2 微服務架構云端部署

微服務架構云端部署采用圖3所示結構,其中的微服務uS1、uS2、門戶應用及前端應用所用AWS實例如下所示:

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

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

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

④ 前端應用:與單體化應用架構前端部署情況類似.

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

表2 單體化架構部署的基礎設施開銷

表3 微服務架構部署的基礎設施開銷

4 實驗結果分析

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

4.1 性能

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

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

1)微服務不會因為使用服務主機數(shù)量過多而導致響應時間的延遲;

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

4.2 開發(fā)方法

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

圖5 單體化架構和微服務架構的平均響應時間

圖6 單體化架構和微服務架構90%響應時間線

微服務架構系統(tǒng)開發(fā)過程中應遵循以下原則:

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

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

3)保證門戶應用提供的服務便于前端應用(瀏覽器、安卓、IOS)調用.

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

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

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

5 結論和進一步工作

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

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

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