摘 要：目前對微服務(wù)軟件架構(gòu)的研究正處于探索階段，Amazon、Netflix等互聯(lián)網(wǎng)巨頭的成功案例表明微服務(wù)架構(gòu)在大規(guī)模企業(yè)應(yīng)用中具有明顯優(yōu)勢。通過對單體架構(gòu)應(yīng)用與微服務(wù)架構(gòu)的對比，對微服務(wù)軟件架構(gòu)研究現(xiàn)狀進行綜述，介紹微服務(wù)架構(gòu)的概念、優(yōu)勢、設(shè)計模式等，分析微服務(wù)軟件架構(gòu)面臨的問題與挑戰(zhàn)，總結(jié)微服務(wù)架構(gòu)與單體架構(gòu)的適用場景。

關(guān)鍵詞：微服務(wù);軟件架構(gòu);單體架構(gòu)

DOI：10. 11907/rjdk. 182825 開放科學(xué)（資源服務(wù)）標識碼（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-），女，中國海洋大學(xué)信息科學(xué)與工程學(xué)院碩士研究生，研究方向為高性能計算。

0 引言

隨著互聯(lián)網(wǎng)用戶群體的日益擴大、互聯(lián)網(wǎng)技術(shù)的不斷革新以及線上業(yè)務(wù)的快速增長，近年來互聯(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)后臺技術(shù)面臨著巨大考驗。Java Web[2]、Yii[3]、Rails[4]框架等是目前比較流行的互聯(lián)網(wǎng)后臺實現(xiàn)方案。其中，Java Web入門簡單，是現(xiàn)階段非常流行的輕量級框架，解決了老式EJB[5]（Enterprise JavaBean）開發(fā)難度大、維護成本高、部署困難等諸多問題。但隨著用戶群體的不斷擴大、用戶范圍越來越廣，用戶的業(yè)務(wù)需求也持續(xù)增加，因此對互聯(lián)網(wǎng)軟件開發(fā)速度提出了非常高的要求，即使輕量級的Java Web也難以滿足市場快速變化的需要。為了提高軟件開發(fā)速度，快速搶占市場，各大型互聯(lián)網(wǎng)公司投入大量時間、精力進行軟件架構(gòu)轉(zhuǎn)型，尋找最敏捷的架構(gòu)開發(fā)方式，以適應(yīng)當前的互聯(lián)網(wǎng)發(fā)展態(tài)勢。因此，如何以最短時間、最低成本開發(fā)出一套穩(wěn)定、健壯且具有良好可擴展性的后臺系統(tǒng)以滿足企業(yè)特定需求，成為各互聯(lián)網(wǎng)企業(yè)系統(tǒng)開發(fā)的首要任務(wù)。

在Java Web開發(fā)模式中，中小型企業(yè)一般選擇傳統(tǒng)的單體應(yīng)用架構(gòu)開發(fā)方式，例如SSH[6]或SSM[7]。這種單體應(yīng)用架構(gòu)開發(fā)方式除容器外，基本沒有外部依賴，將應(yīng)用程序代碼編譯后打包成一個獨立單元，可以是JAR、WAR或其它歸檔格式，并部署在一個JEE[8]容器里，包含了DO/DAO、Service、UI等所有邏輯。當程序運行時，所有功能都運行在同一臺機器的同一進程中，沒有考慮負載均衡與業(yè)務(wù)需求水平擴展的情況。借助于單體架構(gòu)應(yīng)用易于開發(fā)、測試與部署，便于共享以及易于水平伸縮的優(yōu)勢，開發(fā)人員可以迅速開發(fā)出滿足企業(yè)初期功能需求，且具有一定訪問承載量的后臺初始版本[9]。但隨著業(yè)務(wù)范圍的不斷擴大，系統(tǒng)功能模板數(shù)量將進一步增加，系統(tǒng)中的代碼耦合會越來越嚴重，系統(tǒng)的可維護性、擴展性、靈活性將逐步降低，對項目作進一步修改、開發(fā)、部署及測試的壓力會不斷增大，使得單體應(yīng)用架構(gòu)的缺點越來越明顯地暴露出來。隨著應(yīng)用程序維護成本不斷增加，并且新人培養(yǎng)周期長、技術(shù)選型成本高，最終造成構(gòu)建全功能團隊難，持續(xù)交付周期長[10]。因此，單體架構(gòu)應(yīng)用的優(yōu)勢已逐漸無法滿足互聯(lián)網(wǎng)時代快速變化的需要，面臨著越來越多挑戰(zhàn)[11]。

微服務(wù)[12]架構(gòu)是近期軟件應(yīng)用領(lǐng)域的熱門概念，是一種新的架構(gòu)風(fēng)格。通常一個大型復(fù)雜軟件應(yīng)用由一個或多個微服務(wù)組成，系統(tǒng)中每個微服務(wù)僅關(guān)注一件任務(wù)，并且能很好地完成任務(wù)。各微服務(wù)可以獨立部署，微服務(wù)之間是松耦合的，各服務(wù)之間相互協(xié)調(diào)、配合，為企業(yè)與用戶提供最終價值。近年來，隨著云計算技術(shù)的進步與服務(wù)量的不斷增長，利用其優(yōu)勢，微服務(wù)正在為敏捷部署以及復(fù)雜企業(yè)應(yīng)用實施提供巨大幫助。

1 微服務(wù)架構(gòu)概述

微服務(wù)架構(gòu)[13]將一個大型的單個應(yīng)用或服務(wù)拆分成多個微服務(wù)，可擴展單個組件而不是整個應(yīng)用程序堆棧，從而滿足服務(wù)等級協(xié)議。微服務(wù)架構(gòu)圍繞業(yè)務(wù)領(lǐng)域?qū)⒎?wù)進行拆分，每個服務(wù)可以獨立進行開發(fā)、管理和迭代，彼此之間使用統(tǒng)一接口進行交流，實現(xiàn)了在分散組件中的部署、管理與服務(wù)功能，使產(chǎn)品交付變得更加簡單，從而達到有效拆分應(yīng)用，實現(xiàn)敏捷開發(fā)與部署的目的（見圖1）。Amazon[14]、Netflix[15]等互聯(lián)網(wǎng)巨頭的成功案例表明微服務(wù)架構(gòu)在大規(guī)模企業(yè)應(yīng)用中具有明顯優(yōu)勢[16]。

[展示層][數(shù)據(jù)庫][數(shù)據(jù)庫][數(shù)據(jù)庫][展示層][展示層][數(shù)據(jù)庫][單體應(yīng)用架構(gòu)][微服務(wù)架構(gòu)][展示層][服務(wù)A][服務(wù)B][服務(wù)C]

圖1 單體架構(gòu)與微服務(wù)架構(gòu)

1.1 復(fù)雜應(yīng)用解耦

微服務(wù)架構(gòu)將單一模塊應(yīng)用分解為多個微服務(wù)，同時保持總體功能不變。應(yīng)用按照業(yè)務(wù)邏輯被分解為多個可管理的分支或服務(wù)，避免了復(fù)雜度的不斷積累。每個服務(wù)專注于單一功能，通過良好的接口清晰表述服務(wù)邊界。由于功能單一、復(fù)雜度低，小規(guī)模開發(fā)團隊完全能夠掌握，易于保持較高的開發(fā)效率，且易于維護。

1.2 獨立

微服務(wù)在系統(tǒng)軟件生命周期中是獨立開發(fā)、測試及部署的。微服務(wù)具備獨立的運行進程，每個微服務(wù)可進行獨立開發(fā)與部署，因此在大型企業(yè)互聯(lián)網(wǎng)系統(tǒng)中，當某個微服務(wù)發(fā)生變更時無需編譯、部署整個系統(tǒng)應(yīng)用。從測試角度來看，每個微服務(wù)具備獨立的測試機制，測試過程中不需要建立大范圍的回歸測試，不用擔(dān)心測試破壞系統(tǒng)其它功能。因此，微服務(wù)組成的系統(tǒng)應(yīng)用具備一系列可并行的發(fā)布流程，使得開發(fā)、測試、部署更加高效，同時降低了因系統(tǒng)變更給生產(chǎn)環(huán)境造成的風(fēng)險。

1.3 技術(shù)選型靈活

微服務(wù)架構(gòu)下系統(tǒng)應(yīng)用的技術(shù)選型是去中心化的，每個開發(fā)團隊可根據(jù)自身應(yīng)用的業(yè)務(wù)需求發(fā)展狀況選擇合適的體系架構(gòu)與技術(shù)，從而更方便地根據(jù)實際業(yè)務(wù)情況獲得系統(tǒng)應(yīng)用最佳解決方案，并且每個微服務(wù)功能單一、結(jié)構(gòu)簡單，在架構(gòu)轉(zhuǎn)型或技術(shù)棧升級時面臨較低風(fēng)險，因此系統(tǒng)應(yīng)用不會被長期限制在某個體系架構(gòu)或技術(shù)棧上。

1.4 容錯

在傳統(tǒng)單體應(yīng)用架構(gòu)下，當某一模塊發(fā)生故障時，該故障極有可能在整個應(yīng)用內(nèi)擴散，造成全局應(yīng)用系統(tǒng)癱瘓。然而，在微服務(wù)架構(gòu)下，由于各個微服務(wù)相互獨立，故障會被隔離在單個服務(wù)中，并且系統(tǒng)其它微服務(wù)可通過重試、平穩(wěn)退化等機制實現(xiàn)應(yīng)用層的容錯，從而提高系統(tǒng)應(yīng)用的容錯性。微服務(wù)架構(gòu)良好的容錯機制可避免出現(xiàn)單個服務(wù)故障導(dǎo)致整個系統(tǒng)癱瘓的情況。

1.5 松耦合，易擴展

傳統(tǒng)單體應(yīng)用架構(gòu)通過將整個應(yīng)用完整地復(fù)制到不同節(jié)點，從而實現(xiàn)橫向擴展。但當系統(tǒng)應(yīng)用的不同組件在擴展需求上存在差異時，會導(dǎo)致系統(tǒng)應(yīng)用的水平擴展成本很高。微服務(wù)架構(gòu)中每個服務(wù)之間都是松耦合的，可以根據(jù)實際需求實現(xiàn)獨立擴展，體現(xiàn)了微服務(wù)架構(gòu)的靈活性。

2 微服務(wù)架構(gòu)模式方案

微服務(wù)是一種軟件架構(gòu)演變后的新型架構(gòu)風(fēng)格，是系統(tǒng)應(yīng)用開發(fā)的一種設(shè)計思想，沒有固定開發(fā)模式。開發(fā)團隊可根據(jù)企業(yè)實際業(yè)務(wù)場景進行架構(gòu)設(shè)計，體現(xiàn)了微服務(wù)架構(gòu)的靈活性。常見的微服務(wù)設(shè)計模式[17]有聚合器微服務(wù)設(shè)計模式、代理微服務(wù)設(shè)計模式、鏈式微服務(wù)設(shè)計模式、分支微服務(wù)設(shè)計模式、數(shù)據(jù)共享微服務(wù)設(shè)計模式、異步消息傳遞微服務(wù)設(shè)計模式等。

2.1 聚合器微服務(wù)

在聚合器微服務(wù)中，聚合器[18]調(diào)用多個微服務(wù)實現(xiàn)系統(tǒng)應(yīng)用程序所需功能，具體有兩種形式，一種是將檢索到的數(shù)據(jù)信息進行處理并直接展示;另一種是對獲取到的數(shù)據(jù)信息增加業(yè)務(wù)邏輯處理后，再進一步發(fā)布成一個新的微服務(wù)作為一個更高層次的組合微服務(wù)，相當于從服務(wù)消費者轉(zhuǎn)換成服務(wù)提供者。與普通微服務(wù)特性相同，聚合器微服務(wù)也有自己的緩存和數(shù)據(jù)庫。作為聚合器模式的一個變種，在代理微服務(wù)器中，客戶端并不聚合數(shù)據(jù)，只會根據(jù)實際業(yè)務(wù)需求差別選擇調(diào)用具有不同功能的微服務(wù)，代理微服務(wù)器僅進行委派請求和數(shù)據(jù)轉(zhuǎn)換工作。同樣地，代理微服務(wù)器也有自己獨立的緩存和數(shù)據(jù)庫。分支微服務(wù)器模式是聚合器微服務(wù)模式的一種擴展，在分支微服務(wù)器模式下，客戶端或服務(wù)允許同時調(diào)用兩個不同的微服務(wù)鏈。兩個微服務(wù)調(diào)用鏈相互獨立，互不影響。

2.2 鏈式微服務(wù)

客戶端或服務(wù)在收到請求后，會返回一個經(jīng)過合并處理的響應(yīng)，該模式即為鏈式微服務(wù)設(shè)計模式。例如，服務(wù)A收到請求后會與服務(wù)B建立通信，服務(wù)B收到請求后會與服務(wù)C建立通信，依次往下游發(fā)送請求，并對結(jié)果進行合并處理后作為請求響應(yīng)返回上游服務(wù)調(diào)用者。顯然，該模式下的所有服務(wù)調(diào)用都采用同步消息傳遞方式，在一條完整的服務(wù)鏈調(diào)用完成之前，客戶端或調(diào)用服務(wù)會一直阻塞。因此，在使用該模式過程中，服務(wù)調(diào)用鏈不宜過長，以避免客戶端處于長時間等待狀態(tài)。

2.3 數(shù)據(jù)共享微服務(wù)

運用微服務(wù)架構(gòu)重構(gòu)現(xiàn)有單體架構(gòu)應(yīng)用時，SQL數(shù)據(jù)庫反規(guī)范化可能會導(dǎo)致數(shù)據(jù)重復(fù)與不一致現(xiàn)象。按照微服務(wù)的自治設(shè)計原則，在單體架構(gòu)應(yīng)用到微服務(wù)架構(gòu)的過渡階段，可以使用數(shù)據(jù)共享微服務(wù)設(shè)計模式。在該模式下，當服務(wù)之間存在強耦合關(guān)系時，可能存在多個微服務(wù)共享緩存與數(shù)據(jù)庫存儲的現(xiàn)象。

2.4 異步消息傳遞微服務(wù)

目前流行開發(fā)RESTful[19]風(fēng)格的API，REST使用HTTP協(xié)議控制資源，并通過URL加以實現(xiàn)。REST提供了一系列架構(gòu)系統(tǒng)參數(shù)作為整體使用，強調(diào)組件的獨立部署、組件交互的擴展性，以及接口的通用性，并且盡量減少產(chǎn)生交互延遲的中間件數(shù)量。但是REST設(shè)計模式是同步的，容易造成阻塞，從而耗費大量時間。消息隊列將消息寫入一個消息隊列中，實現(xiàn)業(yè)務(wù)邏輯以異步方式運行，從而加快系統(tǒng)響應(yīng)速度。因此，對于一些不必要以同步方式運行的業(yè)務(wù)邏輯，可以使用消息隊列代替REST實現(xiàn)請求、響應(yīng)，加快服務(wù)調(diào)用的響應(yīng)速度。但該模式可能會降低系統(tǒng)可用性，并增加系統(tǒng)復(fù)雜性，因而在使用過程中，要做好消息隊列的選型。常用消息隊列有ActiveMQ、RabbitMQ、RocketMQ、Kafka等。

3 微服務(wù)架構(gòu)面臨問題與挑戰(zhàn)

微服務(wù)架構(gòu)在規(guī)模較大的應(yīng)用中具有明顯優(yōu)勢，但其優(yōu)勢也是有代價的，微服務(wù)架構(gòu)也會給人們帶來新的問題和挑戰(zhàn)。其中一個主要缺點是微服務(wù)架構(gòu)分布式特點帶來的復(fù)雜性，開發(fā)過程中，需要基于RPC[20]或消息實現(xiàn)微服務(wù)之間的調(diào)用與通信，使服務(wù)發(fā)現(xiàn)與服務(wù)調(diào)用鏈跟蹤變得困難。另一個挑戰(zhàn)是微服務(wù)架構(gòu)的分區(qū)數(shù)據(jù)庫體系，不同服務(wù)擁有不同數(shù)據(jù)庫。受限于CAP原理[21]約束以及NoSQL數(shù)據(jù)庫的高擴展性[22]，使人們不得不放棄傳統(tǒng)數(shù)據(jù)庫的強一致性，轉(zhuǎn)而追求最終一致性，因此對開發(fā)人員提出了更高要求。微服務(wù)架構(gòu)給系統(tǒng)測試也帶來了很大挑戰(zhàn)，微服務(wù)架構(gòu)可能涉及多個服務(wù)，傳統(tǒng)的單體Web應(yīng)用只需測試單一API即可，然而對于微服務(wù)架構(gòu)測試，需要啟動其依賴的所有服務(wù)，該復(fù)雜性不可低估。在大規(guī)模應(yīng)用部署中，在監(jiān)控、管理、分發(fā)及擴容等方面，微服務(wù)也存在著巨大挑戰(zhàn)。

因此，對于微服務(wù)架構(gòu)的取舍，要考慮企業(yè)開發(fā)團隊規(guī)模、業(yè)務(wù)需求變化以及系統(tǒng)用戶群體規(guī)模等諸多因素。使用微服務(wù)架構(gòu)主要是為了降低應(yīng)用程序開發(fā)、維護等方面的復(fù)雜性，如果系統(tǒng)程序架構(gòu)已無法再擴展，或數(shù)據(jù)庫增長速度過快，并且整個團隊（包括產(chǎn)品、設(shè)計、研發(fā)、測試、運維）都具備微服務(wù)思維，采用微服務(wù)架構(gòu)的收益會大于成本。但如果系統(tǒng)現(xiàn)有程序架構(gòu)還能很好地工作，不需要有太大改動，采用微服務(wù)架構(gòu)則不會有太多收益。綜上所述，盡管微服務(wù)架構(gòu)有很多優(yōu)勢，但在使用微服務(wù)架構(gòu)之前要結(jié)合系統(tǒng)自身特點，綜合評估以后再決定是否采用微服務(wù)架構(gòu)。

4 結(jié)語

本文通過對微服務(wù)架構(gòu)概念、優(yōu)勢及常見設(shè)計模式的介紹，分析微服務(wù)架構(gòu)面臨的問題與挑戰(zhàn)，得出微服務(wù)架構(gòu)并不一定是最好的企業(yè)開發(fā)架構(gòu)的結(jié)論。是否采用微服務(wù)架構(gòu)進行系統(tǒng)開發(fā)，需要考慮企業(yè)自身業(yè)務(wù)系統(tǒng)特點，綜合評估利弊后再進行技術(shù)架構(gòu)方案的選定。

參考文獻：

[1] 李敏，唐春玲. 基于語義的Web服務(wù)發(fā)展現(xiàn)狀[J]. 科技信息，2014 （9）：8.

[2] 孫瑩，許俊華，張毅，等. MVC編程模型在Web程序中的應(yīng)用及Java實現(xiàn)[J]. 計算機工程與應(yīng)用，2001，37（17）：160-163.

[3] 程偉根，危建國，吳荷紅. 基于YII框架的實驗室管理系統(tǒng)設(shè)計與實現(xiàn)[J]. 軟件導(dǎo)刊，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)的研究與設(shè)計[D]. 沈陽：沈陽工業(yè)大學(xué)，2007.

[7] 李曉夏. 基于SSM框架的快捷信息輸入APP管理系統(tǒng)研究[D]. 哈爾濱：哈爾濱工業(yè)大學(xué)，2018.

[8] 楊鵬，李臘元. EJB組件技術(shù)在電子商務(wù)系統(tǒng)中的應(yīng)用研究[J]. 武漢理工大學(xué)學(xué)報：交通科學(xué)與工程版，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] 羅貴木. 基于微服務(wù)化的Web后臺系統(tǒng)架構(gòu)優(yōu)化及實現(xiàn)[D].北京：北京郵電大學(xué)，2017.

[11] 唐志濤，劉星. 企業(yè)應(yīng)用系統(tǒng)架構(gòu)演進[J]. 科技創(chuàng)新與應(yī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] 王磊. 微服務(wù)架構(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] 郭棟，王偉，曾國蓀. 一種基于微服務(wù)架構(gòu)的新型云件PaaS平臺[J]. 信息網(wǎng)絡(luò)安全，2015（11）：15-20.

[17] 張鋒. 微服務(wù)架構(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]. 南京：東南大學(xué)出版社，2011.

[20] 李洋. 云計算中可擴展的遠程服務(wù)調(diào)用機制的設(shè)計與實現(xiàn)[D]. 哈爾濱：哈爾濱工業(yè)大學(xué)，2012.

[21] 陳明. 分布系統(tǒng)設(shè)計的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.

（責(zé)任編輯：黃 ?。?/p>