云環境中Web應用的微服務架構評估①

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

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

云環境中Web應用的微服務架構評估①

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

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

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

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

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

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

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

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

很多大型互聯網公司已經意識到單體化架構的局限性,他們開始采用一種新的應用系統架構應對出現的問題:微服務架構[8].

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

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

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

1 相關研究

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

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

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

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

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

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

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

2.1 單體化架構

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

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

圖1 單體化架構

單體化架構實現此貸款業務系統具有如下特點:

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

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

3)局部修改影響不可知,例如,開發人員修改服務S1可能造成系統整體出現問題;

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

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

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

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

部署到云環境中的系統架構圖如圖2所示.

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

2.2 微服務架構

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

圖3 微服務架構

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

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

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

微服務架構實現此貸款業務系統具有如下特點:

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

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

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

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

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

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

不同于單體架構,微服務化的貸款業務系統只有uS2所部署的節點才會與數據庫交互,其他節點不包含數據庫訪問客戶端.

此外,為了提高系統執行效率,門戶應用同樣采用負載均衡機制.

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

以第二部分提到的貸款業務系統為例實現兩種架構的云化部署.系統中包含的兩個服務的業務需求如表1所示.

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

表1 兩個服務的業務需求

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

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

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

① Web應用:該模塊的開發采用 Play2.2.2, Scala2.10.2和Java1.7.0,數據庫用PostgreSQL9.3.6.

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

1.3.14 (HTML5,CSS和JQuery).

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

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

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

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

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

1.3.14 (HTML5,CSS和JQuery).

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

3.1 單體化架構云端部署

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

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

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

3.2 微服務架構云端部署

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

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

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

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

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

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

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

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

4 實驗結果分析

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

4.1 性能

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

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

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

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

4.2 開發方法

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

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

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

微服務架構系統開發過程中應遵循以下原則:

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

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

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

4.3 部署、擴展和持續交付

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

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

5 結論和進一步工作

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

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

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