微服務架構(gòu)研究概述
2019-10-15 02:21李春霞
軟件導刊 2019年8期
關鍵詞：微服務
摘 要：目前對微服務軟件架構(gòu)的研究正處于探索階段，Amazon、Netflix等互聯(lián)網(wǎng)巨頭的成功案例表明微服務架構(gòu)在大規(guī)模企業(yè)應用中具有明顯優(yōu)勢。通過對單體架構(gòu)應用與微服務架構(gòu)的對比，對微服務軟件架構(gòu)研究現(xiàn)狀進行綜述，介紹微服務架構(gòu)的概念、優(yōu)勢、設計模式等，分析微服務軟件架構(gòu)面臨的問題與挑戰(zhàn)，總結(jié)微服務架構(gòu)與單體架構(gòu)的適用場景。
關鍵詞：微服務;軟件架構(gòu);單體架構(gòu)
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 引言
隨著互聯(lián)網(wǎng)用戶群體的日益擴大、互聯(lián)網(wǎng)技術的不斷革新以及線上業(yè)務的快速增長，近年來互聯(lián)網(wǎng)的發(fā)展十分迅猛[1]。互聯(lián)網(wǎng)用戶群體的不斷增加也促進了新型網(wǎng)站的研究與開發(fā)，各種購物網(wǎng)站、社區(qū)論壇以及直播網(wǎng)站等層出不窮。隨著各網(wǎng)站活躍用戶數(shù)量與訪問量的日益增長，互聯(lián)網(wǎng)后臺技術面臨著巨大考驗。Java Web[2]、Yii[3]、Rails[4]框架等是目前比較流行的互聯(lián)網(wǎng)后臺實現(xiàn)方案。其中，Java Web入門簡單，是現(xiàn)階段非常流行的輕量級框架，解決了老式EJB[5]（Enterprise JavaBean）開發(fā)難度大、維護成本高、部署困難等諸多問題。但隨著用戶群體的不斷擴大、用戶范圍越來越廣，用戶的業(yè)務需求也持續(xù)增加，因此對互聯(lián)網(wǎng)軟件開發(fā)速度提出了非常高的要求，即使輕量級的Java Web也難以滿足市場快速變化的需要。為了提高軟件開發(fā)速度，快速搶占市場，各大型互聯(lián)網(wǎng)公司投入大量時間、精力進行軟件架構(gòu)轉(zhuǎn)型，尋找最敏捷的架構(gòu)開發(fā)方式，以適應當前的互聯(lián)網(wǎng)發(fā)展態(tài)勢。因此，如何以最短時間、最低成本開發(fā)出一套穩(wěn)定、健壯且具有良好可擴展性的后臺系統(tǒng)以滿足企業(yè)特定需求，成為各互聯(lián)網(wǎng)企業(yè)系統(tǒng)開發(fā)的首要任務。
在Java Web開發(fā)模式中，中小型企業(yè)一般選擇傳統(tǒng)的單體應用架構(gòu)開發(fā)方式，例如SSH[6]或SSM[7]。這種單體應用架構(gòu)開發(fā)方式除容器外，基本沒有外部依賴，將應用程序代碼編譯后打包成一個獨立單元，可以是JAR、WAR或其它歸檔格式，并部署在一個JEE[8]容器里，包含了DO/DAO、Service、UI等所有邏輯。當程序運行時，所有功能都運行在同一臺機器的同一進程中，沒有考慮負載均衡與業(yè)務需求水平擴展的情況。借助于單體架構(gòu)應用易于開發(fā)、測試與部署，便于共享以及易于水平伸縮的優(yōu)勢，開發(fā)人員可以迅速開發(fā)出滿足企業(yè)初期功能需求，且具有一定訪問承載量的后臺初始版本[9]。但隨著業(yè)務范圍的不斷擴大，系統(tǒng)功能模板數(shù)量將進一步增加，系統(tǒng)中的代碼耦合會越來越嚴重，系統(tǒng)的可維護性、擴展性、靈活性將逐步降低，對項目作進一步修改、開發(fā)、部署及測試的壓力會不斷增大，使得單體應用架構(gòu)的缺點越來越明顯地暴露出來。隨著應用程序維護成本不斷增加，并且新人培養(yǎng)周期長、技術選型成本高，最終造成構(gòu)建全功能團隊難，持續(xù)交付周期長[10]。因此，單體架構(gòu)應用的優(yōu)勢已逐漸無法滿足互聯(lián)網(wǎng)時代快速變化的需要，面臨著越來越多挑戰(zhàn)[11]。
微服務[12]架構(gòu)是近期軟件應用領域的熱門概念，是一種新的架構(gòu)風格。通常一個大型復雜軟件應用由一個或多個微服務組成，系統(tǒng)中每個微服務僅關注一件任務，并且能很好地完成任務。各微服務可以獨立部署，微服務之間是松耦合的，各服務之間相互協(xié)調(diào)、配合，為企業(yè)與用戶提供最終價值。近年來，隨著云計算技術的進步與服務量的不斷增長，利用其優(yōu)勢，微服務正在為敏捷部署以及復雜企業(yè)應用實施提供巨大幫助。
1 微服務架構(gòu)概述
微服務架構(gòu)[13]將一個大型的單個應用或服務拆分成多個微服務，可擴展單個組件而不是整個應用程序堆棧，從而滿足服務等級協(xié)議。微服務架構(gòu)圍繞業(yè)務領域?qū)⒎者M行拆分，每個服務可以獨立進行開發(fā)、管理和迭代，彼此之間使用統(tǒng)一接口進行交流，實現(xiàn)了在分散組件中的部署、管理與服務功能，使產(chǎn)品交付變得更加簡單，從而達到有效拆分應用，實現(xiàn)敏捷開發(fā)與部署的目的（見圖1）。Amazon[14]、Netflix[15]等互聯(lián)網(wǎng)巨頭的成功案例表明微服務架構(gòu)在大規(guī)模企業(yè)應用中具有明顯優(yōu)勢[16]。
圖1 單體架構(gòu)與微服務架構(gòu)
1.1 復雜應用解耦
微服務架構(gòu)將單一模塊應用分解為多個微服務，同時保持總體功能不變。應用按照業(yè)務邏輯被分解為多個可管理的分支或服務，避免了復雜度的不斷積累。每個服務專注于單一功能，通過良好的接口清晰表述服務邊界。由于功能單一、復雜度低，小規(guī)模開發(fā)團隊完全能夠掌握，易于保持較高的開發(fā)效率，且易于維護。
1.2 獨立
微服務在系統(tǒng)軟件生命周期中是獨立開發(fā)、測試及部署的。微服務具備獨立的運行進程，每個微服務可進行獨立開發(fā)與部署，因此在大型企業(yè)互聯(lián)網(wǎng)系統(tǒng)中，當某個微服務發(fā)生變更時無需編譯、部署整個系統(tǒng)應用。從測試角度來看，每個微服務具備獨立的測試機制，測試過程中不需要建立大范圍的回歸測試，不用擔心測試破壞系統(tǒng)其它功能。因此，微服務組成的系統(tǒng)應用具備一系列可并行的發(fā)布流程，使得開發(fā)、測試、部署更加高效，同時降低了因系統(tǒng)變更給生產(chǎn)環(huán)境造成的風險。
1.3 技術選型靈活
微服務架構(gòu)下系統(tǒng)應用的技術選型是去中心化的，每個開發(fā)團隊可根據(jù)自身應用的業(yè)務需求發(fā)展狀況選擇合適的體系架構(gòu)與技術，從而更方便地根據(jù)實際業(yè)務情況獲得系統(tǒng)應用最佳解決方案，并且每個微服務功能單一、結(jié)構(gòu)簡單，在架構(gòu)轉(zhuǎn)型或技術棧升級時面臨較低風險，因此系統(tǒng)應用不會被長期限制在某個體系架構(gòu)或技術棧上。
1.4 容錯
在傳統(tǒng)單體應用架構(gòu)下，當某一模塊發(fā)生故障時，該故障極有可能在整個應用內(nèi)擴散，造成全局應用系統(tǒng)癱瘓。然而，在微服務架構(gòu)下，由于各個微服務相互獨立，故障會被隔離在單個服務中，并且系統(tǒng)其它微服務可通過重試、平穩(wěn)退化等機制實現(xiàn)應用層的容錯，從而提高系統(tǒng)應用的容錯性。微服務架構(gòu)良好的容錯機制可避免出現(xiàn)單個服務故障導致整個系統(tǒng)癱瘓的情況。
1.5 松耦合，易擴展
傳統(tǒng)單體應用架構(gòu)通過將整個應用完整地復制到不同節(jié)點，從而實現(xiàn)橫向擴展。但當系統(tǒng)應用的不同組件在擴展需求上存在差異時，會導致系統(tǒng)應用的水平擴展成本很高。微服務架構(gòu)中每個服務之間都是松耦合的，可以根據(jù)實際需求實現(xiàn)獨立擴展，體現(xiàn)了微服務架構(gòu)的靈活性。
2 微服務架構(gòu)模式方案
微服務是一種軟件架構(gòu)演變后的新型架構(gòu)風格，是系統(tǒng)應用開發(fā)的一種設計思想，沒有固定開發(fā)模式。開發(fā)團隊可根據(jù)企業(yè)實際業(yè)務場景進行架構(gòu)設計，體現(xiàn)了微服務架構(gòu)的靈活性。常見的微服務設計模式[17]有聚合器微服務設計模式、代理微服務設計模式、鏈式微服務設計模式、分支微服務設計模式、數(shù)據(jù)共享微服務設計模式、異步消息傳遞微服務設計模式等。
2.1 聚合器微服務
在聚合器微服務中，聚合器[18]調(diào)用多個微服務實現(xiàn)系統(tǒng)應用程序所需功能，具體有兩種形式，一種是將檢索到的數(shù)據(jù)信息進行處理并直接展示;另一種是對獲取到的數(shù)據(jù)信息增加業(yè)務邏輯處理后，再進一步發(fā)布成一個新的微服務作為一個更高層次的組合微服務，相當于從服務消費者轉(zhuǎn)換成服務提供者。與普通微服務特性相同，聚合器微服務也有自己的緩存和數(shù)據(jù)庫。作為聚合器模式的一個變種，在代理微服務器中，客戶端并不聚合數(shù)據(jù)，只會根據(jù)實際業(yè)務需求差別選擇調(diào)用具有不同功能的微服務，代理微服務器僅進行委派請求和數(shù)據(jù)轉(zhuǎn)換工作。同樣地，代理微服務器也有自己獨立的緩存和數(shù)據(jù)庫。分支微服務器模式是聚合器微服務模式的一種擴展，在分支微服務器模式下，客戶端或服務允許同時調(diào)用兩個不同的微服務鏈。兩個微服務調(diào)用鏈相互獨立，互不影響。
2.2 鏈式微服務
客戶端或服務在收到請求后，會返回一個經(jīng)過合并處理的響應，該模式即為鏈式微服務設計模式。例如，服務A收到請求后會與服務B建立通信，服務B收到請求后會與服務C建立通信，依次往下游發(fā)送請求，并對結(jié)果進行合并處理后作為請求響應返回上游服務調(diào)用者。顯然，該模式下的所有服務調(diào)用都采用同步消息傳遞方式，在一條完整的服務鏈調(diào)用完成之前，客戶端或調(diào)用服務會一直阻塞。因此，在使用該模式過程中，服務調(diào)用鏈不宜過長，以避免客戶端處于長時間等待狀態(tài)。
2.3 數(shù)據(jù)共享微服務
運用微服務架構(gòu)重構(gòu)現(xiàn)有單體架構(gòu)應用時，SQL數(shù)據(jù)庫反規(guī)范化可能會導致數(shù)據(jù)重復與不一致現(xiàn)象。按照微服務的自治設計原則，在單體架構(gòu)應用到微服務架構(gòu)的過渡階段，可以使用數(shù)據(jù)共享微服務設計模式。在該模式下，當服務之間存在強耦合關系時，可能存在多個微服務共享緩存與數(shù)據(jù)庫存儲的現(xiàn)象。
2.4 異步消息傳遞微服務
目前流行開發(fā)RESTful[19]風格的API，REST使用HTTP協(xié)議控制資源，并通過URL加以實現(xiàn)。REST提供了一系列架構(gòu)系統(tǒng)參數(shù)作為整體使用，強調(diào)組件的獨立部署、組件交互的擴展性，以及接口的通用性，并且盡量減少產(chǎn)生交互延遲的中間件數(shù)量。但是REST設計模式是同步的，容易造成阻塞，從而耗費大量時間。消息隊列將消息寫入一個消息隊列中，實現(xiàn)業(yè)務邏輯以異步方式運行，從而加快系統(tǒng)響應速度。因此，對于一些不必要以同步方式運行的業(yè)務邏輯，可以使用消息隊列代替REST實現(xiàn)請求、響應，加快服務調(diào)用的響應速度。但該模式可能會降低系統(tǒng)可用性，并增加系統(tǒng)復雜性，因而在使用過程中，要做好消息隊列的選型。常用消息隊列有ActiveMQ、RabbitMQ、RocketMQ、Kafka等。
3 微服務架構(gòu)面臨問題與挑戰(zhàn)
微服務架構(gòu)在規(guī)模較大的應用中具有明顯優(yōu)勢，但其優(yōu)勢也是有代價的，微服務架構(gòu)也會給人們帶來新的問題和挑戰(zhàn)。其中一個主要缺點是微服務架構(gòu)分布式特點帶來的復雜性，開發(fā)過程中，需要基于RPC[20]或消息實現(xiàn)微服務之間的調(diào)用與通信，使服務發(fā)現(xiàn)與服務調(diào)用鏈跟蹤變得困難。另一個挑戰(zhàn)是微服務架構(gòu)的分區(qū)數(shù)據(jù)庫體系，不同服務擁有不同數(shù)據(jù)庫。受限于CAP原理[21]約束以及NoSQL數(shù)據(jù)庫的高擴展性[22]，使人們不得不放棄傳統(tǒng)數(shù)據(jù)庫的強一致性，轉(zhuǎn)而追求最終一致性，因此對開發(fā)人員提出了更高要求。微服務架構(gòu)給系統(tǒng)測試也帶來了很大挑戰(zhàn)，微服務架構(gòu)可能涉及多個服務，傳統(tǒng)的單體Web應用只需測試單一API即可，然而對于微服務架構(gòu)測試，需要啟動其依賴的所有服務，該復雜性不可低估。在大規(guī)模應用部署中，在監(jiān)控、管理、分發(fā)及擴容等方面，微服務也存在著巨大挑戰(zhàn)。
因此，對于微服務架構(gòu)的取舍，要考慮企業(yè)開發(fā)團隊規(guī)模、業(yè)務需求變化以及系統(tǒng)用戶群體規(guī)模等諸多因素。使用微服務架構(gòu)主要是為了降低應用程序開發(fā)、維護等方面的復雜性，如果系統(tǒng)程序架構(gòu)已無法再擴展，或數(shù)據(jù)庫增長速度過快，并且整個團隊（包括產(chǎn)品、設計、研發(fā)、測試、運維）都具備微服務思維，采用微服務架構(gòu)的收益會大于成本。但如果系統(tǒng)現(xiàn)有程序架構(gòu)還能很好地工作，不需要有太大改動，采用微服務架構(gòu)則不會有太多收益。綜上所述，盡管微服務架構(gòu)有很多優(yōu)勢，但在使用微服務架構(gòu)之前要結(jié)合系統(tǒng)自身特點，綜合評估以后再決定是否采用微服務架構(gòu)。
4 結(jié)語
本文通過對微服務架構(gòu)概念、優(yōu)勢及常見設計模式的介紹，分析微服務架構(gòu)面臨的問題與挑戰(zhàn)，得出微服務架構(gòu)并不一定是最好的企業(yè)開發(fā)架構(gòu)的結(jié)論。是否采用微服務架構(gòu)進行系統(tǒng)開發(fā)，需要考慮企業(yè)自身業(yè)務系統(tǒng)特點，綜合評估利弊后再進行技術架構(gòu)方案的選定。
參考文獻：
[1] 李敏，唐春玲. 基于語義的Web服務發(fā)展現(xiàn)狀[J]. 科技信息，2014 （9）：8.
[2] 孫瑩，許俊華，張毅，等. MVC編程模型在Web程序中的應用及Java實現(xiàn)[J]. 計算機工程與應用，2001，37（17）：160-163.
[3] 程偉根，危建國，吳荷紅. 基于YII框架的實驗室管理系統(tǒng)設計與實現(xiàn)[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安全架構(gòu)的研究與設計[D]. 沈陽：沈陽工業(yè)大學，2007.
[7] 李曉夏. 基于SSM框架的快捷信息輸入APP管理系統(tǒng)研究[D]. 哈爾濱：哈爾濱工業(yè)大學，2018.
[8] 楊鵬，李臘元. EJB組件技術在電子商務系統(tǒng)中的應用研究[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后臺系統(tǒng)架構(gòu)優(yōu)化及實現(xiàn)[D].北京：北京郵電大學，2017.
[11] 唐志濤，劉星. 企業(yè)應用系統(tǒng)架構(gòu)演進[J]. 科技創(chuàng)新與應用，2017（35）：120-121.
[12] LEWIS J，F(xiàn)OWLER M. Microservices， a definition of this new architectural term[EB/OL]. https：//martinfowler.com/articles/microservices.html.
[13] 王磊. 微服務架構(gòu)與實踐[M]. 北京：電子工業(yè)出版社，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] 郭棟，王偉，曾國蓀. 一種基于微服務架構(gòu)的新型云件PaaS平臺[J]. 信息網(wǎng)絡安全，2015（11）：15-20.
[17] 張鋒. 微服務架構(gòu)實戰(zhàn)[M]. 北京：電子工業(yè)出版社，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實戰(zhàn)[M]. 南京：東南大學出版社，2011.
[20] 李洋. 云計算中可擴展的遠程服務調(diào)用機制的設計與實現(xiàn)[D]. 哈爾濱：哈爾濱工業(yè)大學，2012.
[21] 陳明. 分布系統(tǒng)設計的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.
（責任編輯：黃 ?。?/p>
猜你喜歡
