微服務架構特點、技術趨勢及在行業應用中關鍵問題研究

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

關鍵詞： 微服務;軟件平臺系統架構;服務網格

中圖分類號： TP311.5 ? ?文獻標識碼： A ? ?DOI：10.3969/j.issn.1003-6970.2020.06.028

本文著錄格式：王義. 微服務架構特點、技術趨勢及在行業應用中關鍵問題研究[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 ?引言

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

1 ?微服務特點以及發展趨勢

1.1 ?大型軟件平臺系統架構發展的歷史背景和趨勢

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

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

微服務是SOA思想的進一步深化，是軟件架構設計向著“去中心化”的進一步演進。通過一系列功能單一，強內聚、松耦合，可獨立部署，可擴展的應用組件，微服務對軟件平臺系統架構進行了更進一步的專業化拆分，顆粒度從功能模塊層級精細到組件層級。

1.2 ?微服務架構的特點和優勢

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

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

二是支持敏捷開發。微服務面向分布式開發，允許業務部門根據自身的業務需求，通過定義好的接口對已有的微服務應用組件進行組合，自助式開發新項目。在對單個應用組件進行代碼重構時，也不會對其他組件構成影響，從而實現以持續集成的方式交付項目。

三是靈活部署擴展。由于各個應用組件在功能、部署和數據層面均采用相對獨立的松耦合設計，開發者不需要協調其它組件對本組件的影響，從而可以加快項目部署速度。在業務開展后，可以根據實際需求對單個應用組件獨立擴展，或隨著業務發展特點和趨勢及時地對應用組件類別進行動態調整，精準實現多項功能的收縮和擴展。

1.3 ?微服務的三個關鍵實施要素

容器、編排調度和開發運營一體化（DevOps）是保證微服務成功的三個關鍵要素。

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

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

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

1.4 ?微服務的最佳應用實踐場景

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

1.5 ?微服務技術發展趨勢

微服務架構沒有公認技術標準，受科技巨頭推動，已相繼出現若干具有影響力的開源或商用框架。根據框架在應用開發代碼中的植入強度，主要分為侵入式架構和非侵入式架構[10]，以服務網格為代表的非侵入式架構被認為是微服務未來發展趨勢。

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

從2017年初第一代架構Linkerd到2018年Google、IBM和Lyft聯合開發的第二代架構Istio，服務網格從萌芽走向成熟。服務網格部署應用程序時，會同時部署SideCar和Control Plane兩大核心模塊[13]。其中，SideCar由一系列輕量級的網絡代理組成，這些網絡代理實現了服務框架的各項功能，通過SideCar，應用服務和框架之間實現了松耦合，服務節點只關注業務自身，服務之間的調用由SideCar完成。Control Plane是一個大型服務網格的統一控制節點，通過控制SideCar從全局角度實現服務網格的各項功能，負責SideCar的注冊，協助各個SideCar之間進行負載均衡和請求調用，同時收集所有SideCar的監控信息和日志數據。

2 ?微服務在行業中應用以及落地過程中的問題

近年來，企業數字化轉型進入加速期。伴隨著產業互聯網蓬勃發展，企業通過引入各種形式的云，升級、優化內部軟件平臺系統，提升對上層業務的賦能。在這種趨勢下，微服務受到越來越多企業的重視，行業應用范圍迅速拓展。研究顯示，至2023年，微服務架構市場預計將增至320.1億美元[14]，4年年復合增長率達到16.17%。

2.1 ?微服務在不同行業企業中的應用情況

對微服務在不同行業樣本企業中的應用情況進行研究和分析，結果顯示，互聯網行業已經實現微服務的大規模應用落地;傳統行業中，隨著市場認可度提升，軟件和IT企業積極布局，一些大型企業已經基于微服務完成了內部平臺系統的重構。未來，伴隨著云平臺被越來越多行業采納和使用，微服務也將更廣泛、更深入的滲透到社會的方方面面。

首批成功采用微服務的企業主要集中在以互聯網業務為主的數字商業市場[15]，例如數字媒體、社交網絡、電子商務等領域，這類企業的業務模式對軟件平臺系統在敏捷性和可擴展性方面有著極高要求。

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

2.2 ?應用過程中出現的問題

研究過程中，我們發現，并非所有企業的軟件平臺系統都適合微服務。微服務的適用性需要綜合考慮業務在彈性、迭代速度、并發性和可用性等方面的需求，以及業務復雜程度，長期演進目標，業務對復用性的需要。部分企業在平臺系統建設初期考慮不足，沒有對自身現狀進行深入分析，而是強推微服務架構，不僅沒有達到預期效果，相反帶來巨大損失。

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

3 ?實施部署微服務的建議

不是所有的軟件平臺系統都適用微服務架構，技術選型時，企業需充分考慮業務應用的特點，以產品和業務為目標導向，加強多利益相關方的參與協作，綜合衡量各方利益，以實現在系統復雜性和敏捷性之間最優的平衡。

微服務實施重點不在于開發框架和開發技術，而在于前期規劃和設計，即微服務組件拆分，每個組件提供功能和接口定義。除基礎技術能力之外，企業應更重視以下幾個方面。

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

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

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

4 ?結論

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

參考文獻

[1] 李智慧. 大型網站技術架構： 核心原理與案例分析[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年云計算發展白皮書[R]. 2018-8 [2019-12-14].

[11] 許進. 重新定義Spring Cloud實戰[M]. 北京： 機械工業出版社， 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.