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