摘 ?要： 近年來，微服務(wù)架構(gòu)已成為軟件平臺系統(tǒng)設(shè)計的熱點(diǎn)選項。微服務(wù)架構(gòu)可以有效提升軟件平臺系統(tǒng)的快速交付和靈活部署，并可以更敏捷實(shí)現(xiàn)后期功能的擴(kuò)展。然而，由于微服務(wù)架自身構(gòu)設(shè)計復(fù)雜且專業(yè)性要求較高，導(dǎo)致企業(yè)采用微服務(wù)架構(gòu)的難度較大。本文總結(jié)了微服務(wù)的特點(diǎn)和優(yōu)勢，研究分析了關(guān)鍵技術(shù)要素以及未來技術(shù)的發(fā)展趨勢，并結(jié)合當(dāng)前微服務(wù)在行業(yè)的應(yīng)用情況，剖析了企業(yè)在采用微服務(wù)架構(gòu)方面面臨的主要問題和瓶頸，并就微服務(wù)架構(gòu)在傳統(tǒng)企業(yè)數(shù)字化轉(zhuǎn)型中的實(shí)施和應(yīng)用提出可行建議。

關(guān)鍵詞： 微服務(wù);軟件平臺系統(tǒng)架構(gòu);服務(wù)網(wǎng)格

中圖分類號： TP311.5 ? ?文獻(xiàn)標(biāo)識碼： A ? ?DOI：10.3969/j.issn.1003-6970.2020.06.028

本文著錄格式：王義. 微服務(wù)架構(gòu)特點(diǎn)、技術(shù)趨勢及在行業(yè)應(yīng)用中關(guān)鍵問題研究[J]. 軟件，2020，41（06）：132136

【Abstract】： In recent years， Micro-services architecture has become a popular option for the software system development. Micro-service architecture can effectively improve the agility of software systems， with early delivery， flexible deployment and elastic scalability. However， due to the complexity of the design and the professional prerequisites arising from the deployment of the Micro-service architecture， it presents a lot of challenges for the enterprises to adopt the Micro-service architecture. This article summarizes the pros and cons of Micro-service architecture， depicts its application in various industries， the future development trends and the bottlenecks of implementation， and provides viable suggestion for using Micro-service architecture in assisting the digital transformation of traditional industries.

【Key words】： Microservices; Software platform system architecture; Service mesh

0 ?引言

微服務(wù)是一種軟件架構(gòu)，是指在軟件平臺系統(tǒng)設(shè)計中，將單一的應(yīng)用程序劃分成一組小的服務(wù)組件，組件之間通過設(shè)計好的接口（API）進(jìn)行訪問和調(diào)用。系統(tǒng)運(yùn)行時，這些組件相互協(xié)調(diào)、互相配合，共同實(shí)現(xiàn)上層的復(fù)雜功能。微服務(wù)的概念由Peter Rodgers博士在2005年“云計算會議”上首次提出，起初被稱為“微網(wǎng)絡(luò)服務(wù)”，在之后的幾年內(nèi)一直“不溫不火”。2010年以后云服務(wù)產(chǎn)業(yè)迅速發(fā)展，由于微服務(wù)的設(shè)計理念與云服務(wù)極為契合，因而被廣泛應(yīng)用于各大主流公有云服務(wù)平臺，成為軟件平臺系統(tǒng)設(shè)計的熱點(diǎn)選項。

1 ?微服務(wù)特點(diǎn)以及發(fā)展趨勢

1.1 ?大型軟件平臺系統(tǒng)架構(gòu)發(fā)展的歷史背景和趨勢

大型軟件平臺系統(tǒng)的發(fā)展從“簡”到“繁”，其架構(gòu)設(shè)計從“中心化”向“去中心化”快速演進(jìn)[1]。最早期的大型軟件平臺系統(tǒng)采用單體式架構(gòu)（Monolith），將所有程序和數(shù)據(jù)資源都部署在同一臺服務(wù)器上。后來，隨著產(chǎn)業(yè)不斷發(fā)展，為應(yīng)對大數(shù)據(jù)場景，軟件平臺系統(tǒng)在架構(gòu)設(shè)計上將應(yīng)用和服務(wù)分離，并引入分布式部署和集群，提升系統(tǒng)整體性能。

Gartner公司將面向服務(wù)的思想應(yīng)用在軟件平臺架構(gòu)設(shè)計中，于1996年提出面向服務(wù)架構(gòu)（SOA）概念[2]，其核心特征是以松耦合、粗粒度的服務(wù)單元來構(gòu)建軟件。具體而言，就是將業(yè)務(wù)系統(tǒng)分解成多個獨(dú)立、自治、可復(fù)用的服務(wù)，通過對服務(wù)的編排組合實(shí)現(xiàn)上層業(yè)務(wù)流程。在SOA架構(gòu)的實(shí)現(xiàn)案例中，常常用到企業(yè)服務(wù)總線（ESB），ESB也漸漸成為SOA的核心技術(shù)基礎(chǔ)。

微服務(wù)是SOA思想的進(jìn)一步深化，是軟件架構(gòu)設(shè)計向著“去中心化”的進(jìn)一步演進(jìn)。通過一系列功能單一，強(qiáng)內(nèi)聚、松耦合，可獨(dú)立部署，可擴(kuò)展的應(yīng)用組件，微服務(wù)對軟件平臺系統(tǒng)架構(gòu)進(jìn)行了更進(jìn)一步的專業(yè)化拆分，顆粒度從功能模塊層級精細(xì)到組件層級。

1.2 ?微服務(wù)架構(gòu)的特點(diǎn)和優(yōu)勢

從服務(wù)入口到數(shù)據(jù)持久層，微服務(wù)實(shí)現(xiàn)了組件的“真正獨(dú)立”，無需服務(wù)總線接入，每個組件就相當(dāng)于一個獨(dú)立的項目，組件之間采用松耦合方式，通過接口調(diào)用。這種隔離性使得模塊代碼量明顯減少，遇到問題需要修改組件代碼時也不會對其他組件造成影響[3]。此外，開發(fā)模式更為靈活，每個組件都可以使用不同的存儲方式，支持不同的開發(fā)技術(shù)。與早期的軟件架構(gòu)相比，微服務(wù)具有以下幾點(diǎn)優(yōu)勢。

一是簡化復(fù)雜問題。在總體功能不變的情況下，微服務(wù)通過拆分的辦法解決復(fù)雜性問題，將大型單體式應(yīng)用拆分成多個相互獨(dú)立的應(yīng)用組件，每個組件都有清楚定義的邊界，面向特定的功能，易于設(shè)計、開發(fā)、更新和維護(hù)。

二是支持敏捷開發(fā)。微服務(wù)面向分布式開發(fā)，允許業(yè)務(wù)部門根據(jù)自身的業(yè)務(wù)需求，通過定義好的接口對已有的微服務(wù)應(yīng)用組件進(jìn)行組合，自助式開發(fā)新項目。在對單個應(yīng)用組件進(jìn)行代碼重構(gòu)時，也不會對其他組件構(gòu)成影響，從而實(shí)現(xiàn)以持續(xù)集成的方式交付項目。

三是靈活部署擴(kuò)展。由于各個應(yīng)用組件在功能、部署和數(shù)據(jù)層面均采用相對獨(dú)立的松耦合設(shè)計，開發(fā)者不需要協(xié)調(diào)其它組件對本組件的影響，從而可以加快項目部署速度。在業(yè)務(wù)開展后，可以根據(jù)實(shí)際需求對單個應(yīng)用組件獨(dú)立擴(kuò)展，或隨著業(yè)務(wù)發(fā)展特點(diǎn)和趨勢及時地對應(yīng)用組件類別進(jìn)行動態(tài)調(diào)整，精準(zhǔn)實(shí)現(xiàn)多項功能的收縮和擴(kuò)展。

1.3 ?微服務(wù)的三個關(guān)鍵實(shí)施要素

容器、編排調(diào)度和開發(fā)運(yùn)營一體化（DevOps）是保證微服務(wù)成功的三個關(guān)鍵要素。

容器[4]為拆解后的應(yīng)用組件提供了相互隔離的承載環(huán)境。容器是一種輕量化的虛擬技術(shù)，可以將內(nèi)部的應(yīng)用和其運(yùn)行環(huán)境以一個標(biāo)準(zhǔn)鏡像格式打包，為運(yùn)行在其中的進(jìn)程提供一定程度的隔離和約束，保證應(yīng)用及運(yùn)行環(huán)境的統(tǒng)一性。與傳統(tǒng)虛擬機(jī)不同，容器共享內(nèi)核，支持快速擴(kuò)展。相較于虛擬機(jī)的啟動時延，容器對負(fù)載或者流量增加的反應(yīng)速度可以達(dá)到秒級。目前最主流的容器平臺是由早期Linux容器發(fā)展而來的Docker[5]，通過Docker，開發(fā)人員可以輕松啟?；蜾N毀容器，方便快捷。

編排服務(wù)[6]負(fù)責(zé)基于容器組成分布式集群應(yīng)用的管理工作。容器編排也被稱為調(diào)度器，主要負(fù)責(zé)管理基于容器組成的分布式集群，例如監(jiān)控容器的運(yùn)行狀態(tài)、容器故障自動化恢復(fù)、基于容器的應(yīng)用擴(kuò)容和縮容等。當(dāng)生產(chǎn)環(huán)境需要部署數(shù)百至上千個容器時，容器編排可以極大簡化操作流程，很好應(yīng)對日益增長的集群管理問題。當(dāng)前的最流行的容器編排工具[7]包括Kubernetes和Docker Swarm，分別由Google和Docker公司在2014年和2013年推出。

DevOps是微服務(wù)實(shí)施的充分必要條件。DevOps（開發(fā)運(yùn)營一體化）通過促進(jìn)開發(fā)、技術(shù)運(yùn)營和質(zhì)量保障三者之間的溝通、協(xié)作與整合，使用自動化的“軟件交付”和“架構(gòu)變更”的流程，加快項目進(jìn)度、縮短發(fā)布周期，提供高質(zhì)量的軟件和服務(wù)[8]。微服務(wù)將原先一個應(yīng)用拆分成數(shù)十個組件，拆分后的每個組件都需要進(jìn)行編譯、打包和部署，這將帶來數(shù)倍于先前的工作量。因此對自動化工具、測試流程、團(tuán)隊協(xié)作和代碼質(zhì)量把控有著更為嚴(yán)格的要求，需要開發(fā)部門與運(yùn)維部門通力協(xié)作，打破部門鴻溝，提升各環(huán)節(jié)工具鏈的自動化水平。

1.4 ?微服務(wù)的最佳應(yīng)用實(shí)踐場景

微服務(wù)的價值通過云平臺得到最大化發(fā)揮和體現(xiàn)[9]。一方面云平臺為微服務(wù)發(fā)展提供理想應(yīng)用環(huán)境。云平臺憑借著快速、敏捷、可大規(guī)模擴(kuò)展的基礎(chǔ)架構(gòu)，以及自助服務(wù)和按需付費(fèi)的計費(fèi)功能，正在重塑社會生產(chǎn)力，提升運(yùn)營效率并加快價值實(shí)現(xiàn)。容器技術(shù)日漸成熟，容器所具備的快速啟動、應(yīng)用程序標(biāo)準(zhǔn)化封裝和隔離模型等特性，進(jìn)一步提升了云服務(wù)的效率和敏捷性，這為微服務(wù)架構(gòu)的落地奠定基礎(chǔ)。另一方面，微服務(wù)能夠顯著提升云服務(wù)效率，推動大型企業(yè)的平臺系統(tǒng)上云。現(xiàn)代業(yè)務(wù)的發(fā)展特點(diǎn)以及來自市場的競爭壓力，對平臺系統(tǒng)提出了極高要求，許多業(yè)務(wù)場景要求在確保7×24小時在線的同時，對系統(tǒng)進(jìn)行升級、擴(kuò)容和增加新功能。對于銀行、電子商務(wù)等行業(yè)領(lǐng)域，系統(tǒng)的停機(jī)維護(hù)將帶來巨大經(jīng)濟(jì)損失，甚至將導(dǎo)致客戶流失。微服務(wù)在服務(wù)拆解、資源調(diào)度、魯棒性等方面的獨(dú)特優(yōu)勢，完全適合上述應(yīng)用場景對于成本效率、可伸縮性和7×24可用性的需求。已經(jīng)成為云端應(yīng)用開發(fā)的基礎(chǔ)和實(shí)現(xiàn)全套云功能的核心。借助全面的微服務(wù)平臺，開發(fā)人員可以通過公共云、私有云和混合云創(chuàng)建高性能，高可用性，高成本效益的平臺系統(tǒng)。

1.5 ?微服務(wù)技術(shù)發(fā)展趨勢

微服務(wù)架構(gòu)沒有公認(rèn)技術(shù)標(biāo)準(zhǔn)，受科技巨頭推動，已相繼出現(xiàn)若干具有影響力的開源或商用框架。根據(jù)框架在應(yīng)用開發(fā)代碼中的植入強(qiáng)度，主要分為侵入式架構(gòu)和非侵入式架構(gòu)[10]，以服務(wù)網(wǎng)格為代表的非侵入式架構(gòu)被認(rèn)為是微服務(wù)未來發(fā)展趨勢。

侵入式框架是指在使用這種框架進(jìn)行開發(fā)時，代碼需要繼承或者實(shí)現(xiàn)框架的某一個類或接口，應(yīng)用對框架存在依賴性，一旦把框架去除或者換掉框架時，需要重新修改代碼。目前，侵入式框架占據(jù)微服務(wù)主流市場，其中以Spring公司的SpringCloud[11]和阿里巴巴的Dubbo[12]為典型代表。

從2017年初第一代架構(gòu)Linkerd到2018年Google、IBM和Lyft聯(lián)合開發(fā)的第二代架構(gòu)Istio，服務(wù)網(wǎng)格從萌芽走向成熟。服務(wù)網(wǎng)格部署應(yīng)用程序時，會同時部署SideCar和Control Plane兩大核心模塊[13]。其中，SideCar由一系列輕量級的網(wǎng)絡(luò)代理組成，這些網(wǎng)絡(luò)代理實(shí)現(xiàn)了服務(wù)框架的各項功能，通過SideCar，應(yīng)用服務(wù)和框架之間實(shí)現(xiàn)了松耦合，服務(wù)節(jié)點(diǎn)只關(guān)注業(yè)務(wù)自身，服務(wù)之間的調(diào)用由SideCar完成。Control Plane是一個大型服務(wù)網(wǎng)格的統(tǒng)一控制節(jié)點(diǎn)，通過控制SideCar從全局角度實(shí)現(xiàn)服務(wù)網(wǎng)格的各項功能，負(fù)責(zé)SideCar的注冊，協(xié)助各個SideCar之間進(jìn)行負(fù)載均衡和請求調(diào)用，同時收集所有SideCar的監(jiān)控信息和日志數(shù)據(jù)。

2 ?微服務(wù)在行業(yè)中應(yīng)用以及落地過程中的問題

近年來，企業(yè)數(shù)字化轉(zhuǎn)型進(jìn)入加速期。伴隨著產(chǎn)業(yè)互聯(lián)網(wǎng)蓬勃發(fā)展，企業(yè)通過引入各種形式的云，升級、優(yōu)化內(nèi)部軟件平臺系統(tǒng)，提升對上層業(yè)務(wù)的賦能。在這種趨勢下，微服務(wù)受到越來越多企業(yè)的重視，行業(yè)應(yīng)用范圍迅速拓展。研究顯示，至2023年，微服務(wù)架構(gòu)市場預(yù)計將增至320.1億美元[14]，4年年復(fù)合增長率達(dá)到16.17%。

2.1 ?微服務(wù)在不同行業(yè)企業(yè)中的應(yīng)用情況

對微服務(wù)在不同行業(yè)樣本企業(yè)中的應(yīng)用情況進(jìn)行研究和分析，結(jié)果顯示，互聯(lián)網(wǎng)行業(yè)已經(jīng)實(shí)現(xiàn)微服務(wù)的大規(guī)模應(yīng)用落地;傳統(tǒng)行業(yè)中，隨著市場認(rèn)可度提升，軟件和IT企業(yè)積極布局，一些大型企業(yè)已經(jīng)基于微服務(wù)完成了內(nèi)部平臺系統(tǒng)的重構(gòu)。未來，伴隨著云平臺被越來越多行業(yè)采納和使用，微服務(wù)也將更廣泛、更深入的滲透到社會的方方面面。

首批成功采用微服務(wù)的企業(yè)主要集中在以互聯(lián)網(wǎng)業(yè)務(wù)為主的數(shù)字商業(yè)市場[15]，例如數(shù)字媒體、社交網(wǎng)絡(luò)、電子商務(wù)等領(lǐng)域，這類企業(yè)的業(yè)務(wù)模式對軟件平臺系統(tǒng)在敏捷性和可擴(kuò)展性方面有著極高要求。

其次，在金融、零售、消費(fèi)品制造等傳統(tǒng)行業(yè)中，越來越多的領(lǐng)先企業(yè)也開始采用或已經(jīng)采用了微服務(wù)，較為成功的案例包括Capital One、可口可樂、迪士尼、通用電氣、高盛、耐克和紅牛。

2.2 ?應(yīng)用過程中出現(xiàn)的問題

研究過程中，我們發(fā)現(xiàn)，并非所有企業(yè)的軟件平臺系統(tǒng)都適合微服務(wù)。微服務(wù)的適用性需要綜合考慮業(yè)務(wù)在彈性、迭代速度、并發(fā)性和可用性等方面的需求，以及業(yè)務(wù)復(fù)雜程度，長期演進(jìn)目標(biāo)，業(yè)務(wù)對復(fù)用性的需要。部分企業(yè)在平臺系統(tǒng)建設(shè)初期考慮不足，沒有對自身現(xiàn)狀進(jìn)行深入分析，而是強(qiáng)推微服務(wù)架構(gòu)，不僅沒有達(dá)到預(yù)期效果，相反帶來巨大損失。

從傳統(tǒng)軟件設(shè)計架構(gòu)向微服務(wù)遷移是一個逐步推進(jìn)的過程，盲目強(qiáng)推會帶來巨大風(fēng)險。首先，微服務(wù)架構(gòu)體系復(fù)雜，應(yīng)用之間通過接口交叉調(diào)用，形成邏輯依賴，這對系統(tǒng)的整體設(shè)計、公共代碼開發(fā)和后期運(yùn)營維護(hù)提出了更高的要求。其次，微服務(wù)要想發(fā)揮全部能力需要容器的加持，容器的編排設(shè)計就是另一個將要面臨的挑戰(zhàn)。最后，開發(fā)過程及交付質(zhì)量需要通過持續(xù)集成（CI）嚴(yán)格把控，一個接口的改動會對多個項目造成影響，光靠人工測試很難覆蓋所有情況，這就需要企業(yè)不斷提升流程的自動化水平，不斷提高自動化測試的比例。復(fù)雜的架構(gòu)體系，加大了線上運(yùn)營維護(hù)時定位排查問題的難度，不僅需要團(tuán)隊具備較高的監(jiān)控和鏈路日志分析技能，同時需要開發(fā)和運(yùn)營團(tuán)隊的密切配合，加強(qiáng)跨部門之間的協(xié)同合作。

3 ?實(shí)施部署微服務(wù)的建議

不是所有的軟件平臺系統(tǒng)都適用微服務(wù)架構(gòu)，技術(shù)選型時，企業(yè)需充分考慮業(yè)務(wù)應(yīng)用的特點(diǎn)，以產(chǎn)品和業(yè)務(wù)為目標(biāo)導(dǎo)向，加強(qiáng)多利益相關(guān)方的參與協(xié)作，綜合衡量各方利益，以實(shí)現(xiàn)在系統(tǒng)復(fù)雜性和敏捷性之間最優(yōu)的平衡。

微服務(wù)實(shí)施重點(diǎn)不在于開發(fā)框架和開發(fā)技術(shù)，而在于前期規(guī)劃和設(shè)計，即微服務(wù)組件拆分，每個組件提供功能和接口定義。除基礎(chǔ)技術(shù)能力之外，企業(yè)應(yīng)更重視以下幾個方面。

一是流程機(jī)制[16]。開發(fā)和運(yùn)營流程對于能否成功實(shí)現(xiàn)微服務(wù)至關(guān)重要，構(gòu)建微服務(wù)交付平臺或開發(fā)微服務(wù)應(yīng)用之前，必須準(zhǔn)備與之相配套的流程機(jī)制。與傳統(tǒng)軟件架構(gòu)相比，微服務(wù)對流程的成熟度和自動化程度要求較高，這要求企業(yè)必須根據(jù)DevOps原則，不斷提升敏捷開發(fā)和部署流程的成熟度;針對微服務(wù)在組件調(diào)用管理、版本和服務(wù)質(zhì)量控制等方面存在的難點(diǎn)制定相應(yīng)的新流程，從而實(shí)現(xiàn)快速、持續(xù)交付業(yè)務(wù);同時優(yōu)化測試和質(zhì)量保證流程，以滿足現(xiàn)有和未來業(yè)務(wù)發(fā)展在安全、治理和風(fēng)險合規(guī)等方面的新需求。

二是團(tuán)隊組織。企業(yè)采用的軟件平臺系統(tǒng)很大程度上反映了交付和維護(hù)團(tuán)隊的組織架構(gòu)。要想實(shí)現(xiàn)獨(dú)立、敏捷的業(yè)務(wù)交付，發(fā)揮微服務(wù)的真正價值，需要建立與之相對應(yīng)的團(tuán)隊組織架構(gòu)，打造以客戶為中心的企業(yè)文化，并賦予各級員工實(shí)現(xiàn)上述愿景的能力。部門設(shè)置上，需打破部門孤島，按照業(yè)務(wù)而非技術(shù)領(lǐng)域設(shè)置團(tuán)隊，每個團(tuán)隊都是面向業(yè)務(wù)的跨職能部門，不僅負(fù)責(zé)從應(yīng)用程序到中間件的各項技術(shù)環(huán)節(jié)，同時也負(fù)責(zé)產(chǎn)品包括設(shè)計、建設(shè)、交付、運(yùn)營到后續(xù)升級更新的全生命周期。通過團(tuán)隊設(shè)置，在企業(yè)內(nèi)部形成自制與負(fù)責(zé)相平衡，服務(wù)和工程相結(jié)合的文化行為。

三是數(shù)據(jù)管理[17]。微服務(wù)架構(gòu)中的數(shù)據(jù)具有分布性特征，每個組件內(nèi)的數(shù)據(jù)模型和數(shù)據(jù)產(chǎn)生流程具有較大的獨(dú)立性，組件間數(shù)據(jù)的連續(xù)性和關(guān)聯(lián)性靠接口維護(hù)管理。在進(jìn)行數(shù)據(jù)解耦之前，首先需要進(jìn)行詳細(xì)的規(guī)劃和設(shè)計，明確定義共享數(shù)據(jù)的范疇和邊界，哪些數(shù)據(jù)是組件內(nèi)部資源，哪些數(shù)據(jù)需要在組件之間共享。然后，按照API調(diào)用的數(shù)據(jù)關(guān)系對各組件的數(shù)據(jù)進(jìn)行建模。在具體操作過程中，需要很好的平衡數(shù)據(jù)規(guī)劃與數(shù)據(jù)治理之間的關(guān)系。因為在微服務(wù)架構(gòu)中，沒有中心化的數(shù)據(jù)視圖和控制，這種通過接口調(diào)用的數(shù)據(jù)關(guān)聯(lián)方式，增加了數(shù)據(jù)治理的復(fù)雜度，對前期數(shù)據(jù)規(guī)劃提出了更高要求。

4 ?結(jié)論

從商業(yè)模式到業(yè)務(wù)流程，再到下沉至底層的技術(shù)支撐，傳統(tǒng)企業(yè)在各個環(huán)節(jié)均受互聯(lián)網(wǎng)影響。軟件平臺系統(tǒng)架構(gòu)的創(chuàng)新將推動業(yè)務(wù)發(fā)展，助力企業(yè)轉(zhuǎn)型。2014年至今，歷經(jīng)5年發(fā)展，微服務(wù)從概念階段逐步落地，相關(guān)技術(shù)和理念已經(jīng)在很多場景得到了應(yīng)用和驗證。目前，微服務(wù)在互聯(lián)網(wǎng)，以及偏向于物流、電商、金融等前端線上交易較多的場景里落地較好，但在之外的部分傳統(tǒng)行業(yè)中遭遇了嚴(yán)峻挑戰(zhàn)，僅在一些大型公司得到了實(shí)踐，尚未完全被中小型企業(yè)接受。傳統(tǒng)企業(yè)也日漸清晰地意識到，僅依賴新技術(shù)理念并不能有效解決企業(yè)現(xiàn)有問題，應(yīng)結(jié)合自身業(yè)務(wù)特點(diǎn)重新規(guī)劃內(nèi)部軟件平臺系統(tǒng)的升級路線。隨著云計算被廣泛應(yīng)用，越來越多的企業(yè)將業(yè)務(wù)遷移至云平臺，微服務(wù)將賦能更多行業(yè)，使得更多傳統(tǒng)企業(yè)從中受益。

參考文獻(xiàn)

[1] 李智慧. 大型網(wǎng)站技術(shù)架構(gòu)： 核心原理與案例分析[M]. 北京： 中國書籍出版社， 2017： 4-12.

[2] Gartner. "Service Oriented" Architectures[R/OL]. 1996 [2019- 10-03]. https：//www.gartner.com/en/documents/302868

[3] Mark Richards. Microservices vs. Service-Oriented Architecture?[M]. OReilly Media Inc， 2016： 21-26.

[4] IDC. Software-Defined Compute： Virtualization， cloud， and Container Platforms[R/OL]. [2020-01-03]. https：//www.idc. com/getdoc.jsp？containerId=IDC_P10666

[5] Allison Randal. The Ideal Versus the Real： Revisiting the History of Virtual Machines and Containers[J/OL]， CoRR Lab， 2019-4： 2， 11. https：//arxiv.org/abs/1904.12226

[6] Avinetworks. Container Orchestration Definition [EB/OL]. [2019-12-19]. https：//avinetworks.com/glossary/container- orchestration/

[7] Uchechukwu Awada. Application-Container Orchestration Tools and Platform-as-a-Service Clouds： A Survey[J/OL]. International Journal of Advanced Computer Science and Application， 2018： 3-4. https：//www.researchgate.net/publication/ 325737011_Application-Container_Orchestration_Tools_and_ Platform-as-a-Service_Clouds_A_Survey

[8] Google. State of DevOps 2019[R/OL]. 2019： 5-6. https：// services.google.com/fh/files/misc/state-of-devops-2019.pdf

[9] James A. Scott. Microservices And Containers： Mastering the Cloud， Data and Digital Transformation[M]. MapR， 2017： 43-46. https：//mapr.com/ebook/microservices-and-containers/ assets/microservices-and-containers.pdf

[10] 中國信息通信研究院. 2018年云計算發(fā)展白皮書[R]. 2018-8 [2019-12-14].

[11] 許進(jìn). 重新定義Spring Cloud實(shí)戰(zhàn)[M]. 北京： 機(jī)械工業(yè)出版社， 2018： 3-11.

[12] Dubbo. User Doc[EB/OL]. Apache Org， [2019-12-25]. http：// dubbo.apache.org/en-us/docs/user/preface/architecture.html

[13] Christian Posta， Burr Sutter. Introducing Istio Service Mesh for Microservices： Build and Deploy Resilient， Fault-Tolerant Cloud-Native Applications[M]. U.S.A： OReilly Media Inc， 2018-04： 4-5.

[14] Kenneth Research. Microservice Architecture Market： Global Drivers， Restraints， Opportunities， Trends， and Forecasts up to 2023[EB/OL]. 2019-04-02. https：//www.marketwatch.com/ press-release/microservice-architecture-market-is-expected-to- reach-3201-billion-by-2023-growing-at-a-cagr-of-around-1617- during-the-forecast-period-2019-04-02

[15] Anne Thomas， Aashish Gupta. Innovation Insight for Micro-services[R]. Gartner， 2019： 10.

[16] Gary Olliffe， Kevin Matheny. How to Succeed with Microservices Architecture Using DevOps Practices[R]. Gartner， 2019： 11-25.

[17] Kevin Matheny， Lyn Robison. Working with Data in a Mic?r?o-services Architecture[R]. Gartner， 2019： 5-18.