微服務架構研究概述
2019-10-15 02:21:53李春霞
軟件導刊 2019年8期
摘 要：目前對微服務軟件架構的研究正處于探索階段，Amazon、Netflix等互聯網巨頭的成功案例表明微服務架構在大規模企業應用中具有明顯優勢。通過對單體架構應用與微服務架構的對比，對微服務軟件架構研究現狀進行綜述，介紹微服務架構的概念、優勢、設計模式等，分析微服務軟件架構面臨的問題與挑戰，總結微服務架構與單體架構的適用場景。
關鍵詞：微服務;軟件架構;單體架構
DOI：10. 11907/rjdk. 182825 開放科學（資源服務）標識碼（OSID）：
中圖分類號：TP303 文獻標識碼：A 文章編號：1672-7800（2019）008-0001-03
Research Overview of Microservices Architecture
LI Chun-xia
（Institute of Information Science and Engineering，Ocean University of China，Qingdao 266100，China）
Abstract： At present， the microservices software architecture is in the stages of exploration and rise. The successful cases of Amazon， Netflix and other Internet giants show that microservices architecture have obvious advantages in large-scale enterprise applications. In this paper， by comparing to monolithic architecture application， microservices software architecture for the current research status were reviewed. This paper introduces the principle， development and design patterns of microservices architecture， then analyzes its advantages and disadvantages， and summarize the applicable scenarios of microservices architecture and monolithic architecture application in the end.
Key Words： microservices; software architecture; monolithic architecture
作者簡介：李春霞（1993-），女，中國海洋大學信息科學與工程學院碩士研究生，研究方向為高性能計算。
0 引言
隨著互聯網用戶群體的日益擴大、互聯網技術的不斷革新以及線上業務的快速增長，近年來互聯網的發展十分迅猛[1]。互聯網用戶群體的不斷增加也促進了新型網站的研究與開發，各種購物網站、社區論壇以及直播網站等層出不窮。隨著各網站活躍用戶數量與訪問量的日益增長，互聯網后臺技術面臨著巨大考驗。Java Web[2]、Yii[3]、Rails[4]框架等是目前比較流行的互聯網后臺實現方案。其中，Java Web入門簡單，是現階段非常流行的輕量級框架，解決了老式EJB[5]（Enterprise JavaBean）開發難度大、維護成本高、部署困難等諸多問題。但隨著用戶群體的不斷擴大、用戶范圍越來越廣，用戶的業務需求也持續增加，因此對互聯網軟件開發速度提出了非常高的要求，即使輕量級的Java Web也難以滿足市場快速變化的需要。為了提高軟件開發速度，快速搶占市場，各大型互聯網公司投入大量時間、精力進行軟件架構轉型，尋找最敏捷的架構開發方式，以適應當前的互聯網發展態勢。因此，如何以最短時間、最低成本開發出一套穩定、健壯且具有良好可擴展性的后臺系統以滿足企業特定需求，成為各互聯網企業系統開發的首要任務。
在Java Web開發模式中，中小型企業一般選擇傳統的單體應用架構開發方式，例如SSH[6]或SSM[7]。這種單體應用架構開發方式除容器外，基本沒有外部依賴，將應用程序代碼編譯后打包成一個獨立單元，可以是JAR、WAR或其它歸檔格式，并部署在一個JEE[8]容器里，包含了DO/DAO、Service、UI等所有邏輯。當程序運行時，所有功能都運行在同一臺機器的同一進程中，沒有考慮負載均衡與業務需求水平擴展的情況。借助于單體架構應用易于開發、測試與部署，便于共享以及易于水平伸縮的優勢，開發人員可以迅速開發出滿足企業初期功能需求，且具有一定訪問承載量的后臺初始版本[9]。但隨著業務范圍的不斷擴大，系統功能模板數量將進一步增加，系統中的代碼耦合會越來越嚴重，系統的可維護性、擴展性、靈活性將逐步降低，對項目作進一步修改、開發、部署及測試的壓力會不斷增大，使得單體應用架構的缺點越來越明顯地暴露出來。隨著應用程序維護成本不斷增加，并且新人培養周期長、技術選型成本高，最終造成構建全功能團隊難，持續交付周期長[10]。因此，單體架構應用的優勢已逐漸無法滿足互聯網時代快速變化的需要，面臨著越來越多挑戰[11]。
微服務[12]架構是近期軟件應用領域的熱門概念，是一種新的架構風格。通常一個大型復雜軟件應用由一個或多個微服務組成，系統中每個微服務僅關注一件任務，并且能很好地完成任務。各微服務可以獨立部署，微服務之間是松耦合的，各服務之間相互協調、配合，為企業與用戶提供最終價值。近年來，隨著云計算技術的進步與服務量的不斷增長，利用其優勢，微服務正在為敏捷部署以及復雜企業應用實施提供巨大幫助。
1 微服務架構概述
微服務架構[13]將一個大型的單個應用或服務拆分成多個微服務，可擴展單個組件而不是整個應用程序堆棧，從而滿足服務等級協議。微服務架構圍繞業務領域將服務進行拆分，每個服務可以獨立進行開發、管理和迭代，彼此之間使用統一接口進行交流，實現了在分散組件中的部署、管理與服務功能，使產品交付變得更加簡單，從而達到有效拆分應用，實現敏捷開發與部署的目的（見圖1）。Amazon[14]、Netflix[15]等互聯網巨頭的成功案例表明微服務架構在大規模企業應用中具有明顯優勢[16]。
圖1 單體架構與微服務架構
1.1 復雜應用解耦
微服務架構將單一模塊應用分解為多個微服務，同時保持總體功能不變。應用按照業務邏輯被分解為多個可管理的分支或服務，避免了復雜度的不斷積累。每個服務專注于單一功能，通過良好的接口清晰表述服務邊界。由于功能單一、復雜度低，小規模開發團隊完全能夠掌握，易于保持較高的開發效率，且易于維護。
1.2 獨立
微服務在系統軟件生命周期中是獨立開發、測試及部署的。微服務具備獨立的運行進程，每個微服務可進行獨立開發與部署，因此在大型企業互聯網系統中，當某個微服務發生變更時無需編譯、部署整個系統應用。從測試角度來看，每個微服務具備獨立的測試機制，測試過程中不需要建立大范圍的回歸測試，不用擔心測試破壞系統其它功能。因此，微服務組成的系統應用具備一系列可并行的發布流程，使得開發、測試、部署更加高效，同時降低了因系統變更給生產環境造成的風險。
1.3 技術選型靈活
微服務架構下系統應用的技術選型是去中心化的，每個開發團隊可根據自身應用的業務需求發展狀況選擇合適的體系架構與技術，從而更方便地根據實際業務情況獲得系統應用最佳解決方案，并且每個微服務功能單一、結構簡單，在架構轉型或技術棧升級時面臨較低風險，因此系統應用不會被長期限制在某個體系架構或技術棧上。
1.4 容錯
在傳統單體應用架構下，當某一模塊發生故障時，該故障極有可能在整個應用內擴散，造成全局應用系統癱瘓。然而，在微服務架構下，由于各個微服務相互獨立，故障會被隔離在單個服務中，并且系統其它微服務可通過重試、平穩退化等機制實現應用層的容錯，從而提高系統應用的容錯性。微服務架構良好的容錯機制可避免出現單個服務故障導致整個系統癱瘓的情況。
1.5 松耦合，易擴展
傳統單體應用架構通過將整個應用完整地復制到不同節點，從而實現橫向擴展。但當系統應用的不同組件在擴展需求上存在差異時，會導致系統應用的水平擴展成本很高。微服務架構中每個服務之間都是松耦合的，可以根據實際需求實現獨立擴展，體現了微服務架構的靈活性。
2 微服務架構模式方案
微服務是一種軟件架構演變后的新型架構風格，是系統應用開發的一種設計思想，沒有固定開發模式。開發團隊可根據企業實際業務場景進行架構設計，體現了微服務架構的靈活性。常見的微服務設計模式[17]有聚合器微服務設計模式、代理微服務設計模式、鏈式微服務設計模式、分支微服務設計模式、數據共享微服務設計模式、異步消息傳遞微服務設計模式等。
2.1 聚合器微服務
在聚合器微服務中，聚合器[18]調用多個微服務實現系統應用程序所需功能，具體有兩種形式，一種是將檢索到的數據信息進行處理并直接展示;另一種是對獲取到的數據信息增加業務邏輯處理后，再進一步發布成一個新的微服務作為一個更高層次的組合微服務，相當于從服務消費者轉換成服務提供者。與普通微服務特性相同，聚合器微服務也有自己的緩存和數據庫。作為聚合器模式的一個變種，在代理微服務器中，客戶端并不聚合數據，只會根據實際業務需求差別選擇調用具有不同功能的微服務，代理微服務器僅進行委派請求和數據轉換工作。同樣地，代理微服務器也有自己獨立的緩存和數據庫。分支微服務器模式是聚合器微服務模式的一種擴展，在分支微服務器模式下，客戶端或服務允許同時調用兩個不同的微服務鏈。兩個微服務調用鏈相互獨立，互不影響。
2.2 鏈式微服務
客戶端或服務在收到請求后，會返回一個經過合并處理的響應，該模式即為鏈式微服務設計模式。例如，服務A收到請求后會與服務B建立通信，服務B收到請求后會與服務C建立通信，依次往下游發送請求，并對結果進行合并處理后作為請求響應返回上游服務調用者。顯然，該模式下的所有服務調用都采用同步消息傳遞方式，在一條完整的服務鏈調用完成之前，客戶端或調用服務會一直阻塞。因此，在使用該模式過程中，服務調用鏈不宜過長，以避免客戶端處于長時間等待狀態。
2.3 數據共享微服務
運用微服務架構重構現有單體架構應用時，SQL數據庫反規范化可能會導致數據重復與不一致現象。按照微服務的自治設計原則，在單體架構應用到微服務架構的過渡階段，可以使用數據共享微服務設計模式。在該模式下，當服務之間存在強耦合關系時，可能存在多個微服務共享緩存與數據庫存儲的現象。
2.4 異步消息傳遞微服務
目前流行開發RESTful[19]風格的API，REST使用HTTP協議控制資源，并通過URL加以實現。REST提供了一系列架構系統參數作為整體使用，強調組件的獨立部署、組件交互的擴展性，以及接口的通用性，并且盡量減少產生交互延遲的中間件數量。但是REST設計模式是同步的，容易造成阻塞，從而耗費大量時間。消息隊列將消息寫入一個消息隊列中，實現業務邏輯以異步方式運行，從而加快系統響應速度。因此，對于一些不必要以同步方式運行的業務邏輯，可以使用消息隊列代替REST實現請求、響應，加快服務調用的響應速度。但該模式可能會降低系統可用性，并增加系統復雜性，因而在使用過程中，要做好消息隊列的選型。常用消息隊列有ActiveMQ、RabbitMQ、RocketMQ、Kafka等。
3 微服務架構面臨問題與挑戰
微服務架構在規模較大的應用中具有明顯優勢，但其優勢也是有代價的，微服務架構也會給人們帶來新的問題和挑戰。其中一個主要缺點是微服務架構分布式特點帶來的復雜性，開發過程中，需要基于RPC[20]或消息實現微服務之間的調用與通信，使服務發現與服務調用鏈跟蹤變得困難。另一個挑戰是微服務架構的分區數據庫體系，不同服務擁有不同數據庫。受限于CAP原理[21]約束以及NoSQL數據庫的高擴展性[22]，使人們不得不放棄傳統數據庫的強一致性，轉而追求最終一致性，因此對開發人員提出了更高要求。微服務架構給系統測試也帶來了很大挑戰，微服務架構可能涉及多個服務，傳統的單體Web應用只需測試單一API即可，然而對于微服務架構測試，需要啟動其依賴的所有服務，該復雜性不可低估。在大規模應用部署中，在監控、管理、分發及擴容等方面，微服務也存在著巨大挑戰。
因此，對于微服務架構的取舍，要考慮企業開發團隊規模、業務需求變化以及系統用戶群體規模等諸多因素。使用微服務架構主要是為了降低應用程序開發、維護等方面的復雜性，如果系統程序架構已無法再擴展，或數據庫增長速度過快，并且整個團隊（包括產品、設計、研發、測試、運維）都具備微服務思維，采用微服務架構的收益會大于成本。但如果系統現有程序架構還能很好地工作，不需要有太大改動，采用微服務架構則不會有太多收益。綜上所述，盡管微服務架構有很多優勢，但在使用微服務架構之前要結合系統自身特點，綜合評估以后再決定是否采用微服務架構。
4 結語
本文通過對微服務架構概念、優勢及常見設計模式的介紹，分析微服務架構面臨的問題與挑戰，得出微服務架構并不一定是最好的企業開發架構的結論。是否采用微服務架構進行系統開發，需要考慮企業自身業務系統特點，綜合評估利弊后再進行技術架構方案的選定。
參考文獻：
[1] 李敏，唐春玲. 基于語義的Web服務發展現狀[J]. 科技信息，2014 （9）：8.
[2] 孫瑩，許俊華，張毅，等. MVC編程模型在Web程序中的應用及Java實現[J]. 計算機工程與應用，2001，37（17）：160-163.
[3] 程偉根，危建國，吳荷紅. 基于YII框架的實驗室管理系統設計與實現[J]. 軟件導刊，2012，11（11）：99-101.
[4] 周迅飛，王崑聲. 基于MVC模式的Rails框架研究[J]. 計算機仿真，2006，23（2）：270-274.
[5] JOHNSON R，HOELLER J. Expert one-on-one J2EE development without EJB[M]. John Wiley & Sons，2004.
[6] 智為. 基于SSH多層框架的Web安全架構的研究與設計[D]. 沈陽：沈陽工業大學，2007.
[7] 李曉夏. 基于SSM框架的快捷信息輸入APP管理系統研究[D]. 哈爾濱：哈爾濱工業大學，2018.
[8] 楊鵬，李臘元. EJB組件技術在電子商務系統中的應用研究[J]. 武漢理工大學學報：交通科學與工程版，2005，29（2）：223-226.
[9] DRAGONI N，GIALLORENZO S，LAFUENTE A，et al. Microservices： yesterday， today， and tomorrow[J]. Present and Ulterior Software Engineering，2017.
[10] 羅貴木. 基于微服務化的Web后臺系統架構優化及實現[D].北京：北京郵電大學，2017.
[11] 唐志濤，劉星. 企業應用系統架構演進[J]. 科技創新與應用，2017（35）：120-121.
[12] LEWIS J，FOWLER M. Microservices， a definition of this new architectural term[EB/OL]. https：//martinfowler.com/articles/microservices.html.
[13] 王磊. 微服務架構與實踐[M]. 北京：電子工業出版社，2015.
[14] OHANLON C. A conversation with Werner Vogels[J]. Queue，2006，4（4）：14-22.
[15] ADRIAN C. State of the art in microservices[EB/OL]. https：//blog.docker.com/2014/12/deckercon-enrope-keynote-of-the-art-in-microservices-by-adrian-cockcroft-battery-ventures/.
[16] 郭棟，王偉，曾國蓀. 一種基于微服務架構的新型云件PaaS平臺[J]. 信息網絡安全，2015（11）：15-20.
[17] 張鋒. 微服務架構實戰[M]. 北京：電子工業出版社，2018.
[18] GUPTA A. Microservice design patterns[EB/OL]. https：//www.javacodegeeks.com/2015/04/microservice-design-patterns.html.
[19] WEBBER J，PARASTATIDIS S，ROBI I. REST實戰[M]. 南京：東南大學出版社，2011.
[20] 李洋. 云計算中可擴展的遠程服務調用機制的設計與實現[D]. 哈爾濱：哈爾濱工業大學，2012.
[21] 陳明. 分布系統設計的CAP理論[J]. 計算機教育，2013，195（15）：109-112.
[22] STONEBRAKER M. SQL databases v. NoSQL databases[J]. Communications of the ACM， 2010， 53（4）：10-11.
（責任編輯：黃 健）
