微服務技術發展的現狀與展望

人工智能技術與咨詢?

來源：計算機研究與發展，作者馮志勇等

摘 要?隨著云計算、物聯網等技術迅速發展，用戶對軟件系統的需求趨于多樣化，面向服務的體系架構(service oriented architecture, SOA)需要在服務穩定集成與需求靈活適配之間尋求平衡.基于此，擁有獨立進程、具備獨立部署能力的微服務技術應運而生，它具有分布式存儲、高可用性、可伸縮性、運維智能化等優勢，能夠彌補傳統SOA的缺陷.首先,從系統集成角度的出發，闡述微服務出現的應用背景，利用微服務的核心組件、軟件技術發展、架構演化等基礎技術，以保證微服務基礎設施的可用性；其次，基于微服務體系架構在實際應用中的問題，從分布式通信、分布式數據存儲、分布式調用鏈、測試的復雜性等方面，分析微服務體系架構具體應用中采用的關鍵技術，并給出具體應用案例，以保證微服務的技術可行性；最后，從基礎設施、信息交互、數據安全與網絡安全等方面探尋微服務所面臨的諸多挑戰，并分析未來發展趨勢分析，以期為微服務未來的創新和發展提供有價值的理論與技術參考.

隨著云計算、物聯網、服務計算等技術快速發展，社會生產生活對軟件系統的需求量與日俱增，用戶需求的多樣性、個性化趨勢日趨凸顯.為了滿足不斷演化的用戶需求，許多軟件企業開放其軟件產品線，允許上下游相關企業、外部開發者甚至用戶參與到軟件開發維護工作之中，進而有效加快軟件產業的垂直分工和水平整合，促進了軟件生態系統(software ecosystems, SECO)[1]的豐富和完善.

隨著軟件功能不斷擴展、用戶負載量逐漸增長等發展問題，軟件生態系統中模塊與組件之間的調用依賴關系也變得越來越復雜.在這種背景下，新組件的引入與迭代、數據的快速更新，無疑會造成軟件生態系統的不穩定、不平衡.為了確保系統滿足高可用、高并發的要求，系統架構需要根據用戶需求合理配置資源，以保證資源利用率最大化.具體而言，從系統集成的角度，軟件生態系統的演化過程可以大致分為3個階段，各階段特點如圖1[2]所示.

1) 點對點集成

點對點集成階段通常產生在系統發展初期，其演化和擴展的方式為1對1集成.在企業應用系統個數較少的場景下，系統通過提供的對應接口，實現系統間的數據傳輸.當應用系統數量達到一定程度時，系統間的接口眾多，會導致大量重復開發和聯調工作，接口的開發難易程度和維護成本會隨之增大.因此，整個軟件生態系統的擴展能力較弱，其演化方式也顯得笨重且僵硬.在此種情況下，面向服務體系架構(service-oriented achitecture， SOA)[3]的集成理念應運而生.

2) 平臺集成

SOA是一種軟件系統的設計方法，以松耦合的方式，將應用系統的不同服務功能進行拆分，通過服務之間定義良好的接口實現服務集成.SOA理念[4]的出現使企業開始從整體角度看待IT(information technology)架構的建設，更加強調自上至下的整體架構.同時，企業服務總線(enterprise service bus， ESB)[5]的興起，為服務整合提供行之有效的解決方案，ESB在數據集成、應用集成、流程集成、門戶集成等方面具有獨特的優勢，可以有效地簡化IT系統結構，提高系統的靈活性和可擴展能力.

3) 互聯網集成

隨著移動互聯網與互聯網+的發展，原有的SOA體系架構遇到了4個問題：①缺乏有效的服務治理，服務資產混雜不清，沒有有效的服務管控手段；②業務支撐響應慢，系統尾大不掉，無法做到實時更新和模塊化發布；③系統可用性差，無法做到7×24 h無間斷提供服務；④創新業務難以支撐，特別是帶有互聯網特點的創新業務.

基于此，開發人員以體系結構優化為出發點，提出了基于微服務的SOA體系架構[6]；其核心理念是將復雜的應用系統以獨立業務單元的形式分解為多個服務，每個服務可以采用不同的實現技術，以輕量級、更靈活的模式進行獨立設計、開發、部署，運行于獨立的進程中，形成高度內聚的自治單元[7].

具體而言，SOA把系統劃分成不同的服務，使用接口進行數據交互，服務之間通過相互依賴、有效整合，以達到系統的整體功能[8].而在體系架構方面，微服務架構是基于SOA架構基礎上的改進，并且融入組件化思想與領域建模思想.首先，系統被拆分為多個微服務，以松耦合的方式被獨立部署；其次，每個微服務僅需高質量地完成本身任務，且每個任務代表著一項細粒度業務能力；由此，各項業務被徹底的組件化和服務化[9]；最后，提供領域服務能力的模塊在底層微服務架構中實現服務的組合和組裝.如圖2(a)所示，整體架構將所有軟件功能放在一個進程中，由多個服務器共同支持運行計算任務，最后將運行結果返還給用戶；而微服務架構(圖2(b))將軟件整體功能分解成多個服務，分別由不同類別的服務器進行支持；然后，將數據反饋給數據庫，用戶可以從數據庫中獲取數據，既加快了系統的整體響應速度，又滿足互聯網化環境下前后端分離的業務需求.由此可見，微服務體系架構的優勢[10]主要體現在：分布式(物理部署、服務部署、數據存儲)、高可用(分布式架構、集群化部署、服務自動注冊)、可伸縮(按需分配資源)、運維智能化等方面.

隨著軟件系統功能的日益擴展復雜化，基于微服務的SOA架構開始日益興起.具體而言，微服務在前臺支撐業務的快速響應與個性化，是采用面向服務開發的SOD(service-oriented development)，具有開發快速、響應及時、易于實現等特點[11]；ESB服務總線作為后端支撐各系統、技術、平臺的集成，而面向服務的基礎設施(service-oriented infrastruc-ture, SOI)[12]，具有穩定、高度集成等特點.微服務技術與ESB技術二者相輔相成，分別在SOA架構中發揮不同的核心作用，以期達到軟件系統的自服務效果.

本文首先以系統集成角度，闡述微服務出現的特定背景，并逐漸深入探討微服務核心組件以及微服務技術與架構發展；其次，詳細介紹近年來微服務系統所采用的關鍵技術；最后，對微服務所面臨的挑戰與未來發展趨勢進行了分析.

1 微服務的核心組件

根據Lewis等人[13]的闡述，軟件架構研討會(Seminar on Software Architecture)于2014年5月首次定義了“微服務”這一術語，用來表示諸多學者一直探索的系統共同架構方法.此前，部分學者已經使用不同的方法實現了該框架.例如亞馬遜公司Vogels等人[14]將該種架構方法描述為“將直接操作數據的業務邏輯來封裝數據，通過已發布的服務接口進行唯一訪問”，Netflix公司Cockcroft[15]將其定義為“松散耦合的面向服務的體系結構與有限制的信息交換”.工業界中相關概念有“fine-grained SOA”和“SOA done right”等方法.

從字面去理解微服務，即什么是“微”、什么是“服務”，“微”狹義上來講就是體積小、架構小，而"服務"，區別于整體系統的概念，是一個或者一組相對較小且獨立的功能單元，是用戶可以感知到的最小功能集；每個微服務具有自己的輕量處理和通信機制，并且自動化部署在單個或多個服務器上.其中，微服務概念來源領域驅動設計(domain-driven design, DDD)[16]，即是一種基于模型的開發方法，由有限組織環境和持續軟件集成等原則進行指導.該設計統一了分析和設計編程，使得軟件能夠更靈活快速跟隨需求變化.解決了分布式Web規模應用程序(Facebook，Spotify等)中存在的挑戰以及大型科技公司面臨的組織問題.

微服務為分布式軟件系統提供了良好的解決方案.與傳統面向服務體系結構的實施方案相比，微服務體系結構除了提供服務注冊與發現，服務組合等基本組件外，還加入了負載均衡、服務網關和容錯機制等，同時對已有模塊進行了擴展和優化；圖3是對微服務框架相關元素[17]及元素內容的具體展示.將結合圖3，從5個方面介紹微服務核心組件.

1.1 服務發現機制與注冊中心

微服務遵循輕量級通信原則，單個微服務一般部署在輕量級容器如Docker中.然而，在運行過程中，服務實例隨時可能被銷毀、克隆或者重新定位；由此，服務實例在動態變化中，創建一種服務發現機制，有利于服務之間感知彼此的存在.其中，服務注冊中心[18]是服務發現機制中重要的一環，即服務啟動時會將自身的網絡地址與數據提交到注冊中心，并訂閱自己需要消費的服務.

服務注冊中心是服務發現的核心，必須具有高可用性和實時更新功能；主要存儲服務提供者和消費者的統一資源定位器(uniform resoure locator， URL)地址及路由轉發信息；實現服務注冊、發布、健康檢查和故障檢測等功能.表1對目前較為流行的服務注冊中心進行了分析與歸納.其中，在Key-Value，Kubernetes，Cloud Foundry等應用平臺中使用的Etcd具有分布式、高可用性以及強一致性特征，適合于少量數據的情形.而由Google公司開發和維護注冊中心Consul功能更為全面，作為一個用于發現和配置的工具，Consul提供了允許客戶端注冊和發現服務的API，而其提供的服務健康檢查，可以幫助確定服務可用性.此外，具有高協調能力的Zookeeper在分布式系統中應用較為廣泛[19]，通過提供統一命名服務、集群管理、狀態同步、分布式應用配置與管理等功能，解決了分布式系統中數據一致性問題.

Table 1 Service Registry Comparisons
表1 服務注冊中心比較

1.2 負載均衡

為了保證服務具有高度可用性，微服務需要部署多個服務實例來提供業務支持；當請求面對同一服務的多個實例，如何合理選擇服務實例以減少業務等待時間成為一個亟待解決的問題，由此負載均衡可以分為客戶端負載均衡與服務端負載均衡，以選擇合理的服務負載均衡策略.

負載均衡具有多種實現算法，其中應用最廣泛來自著名的Round Robin算法，即輪詢法[20]；其基本思想是將多個可用服務實例組織成一個循環隊列，然后根據實例順序輪流分配給內部的服務器，從1到N(N個服務器)依次循環；該方法適用于基本配置相同的服務且服務平均請求相對均衡的情境；然而，在面臨性能方面差異較大的服務實例時，一般采用加權輪詢法[21],即根據服務器的不同處理能力，給每個服務器分配不同權重，響應具有相應權值數的服務請求；該均衡算法可以提升高性能服務器的利用率，降低低性能服務器負載過重的概率，避免負載不均衡的情況.但在實際應用中，客戶端每一次請求服務，服務器響應時間都具有較大差異；因此，若采用簡單輪詢或隨機均衡算法，并不能達到真正的負載均衡.鑒于這一缺點，可采用最小連接數算法(least connections scheduling, LCS)[22]；該算法記錄當前服務器可負載實例數量，以及該服務器正在處理的進程數量；具體而言，當產生新服務連接請求時，將把當前請求分配給連接數最少的服務器，以提升服務實例利用率以及服務器負載能力.

微服務架構均支持以上負載均衡算法.與傳統整體架構負載均衡不同的是，傳統整體架構使用負載均衡器分發高并發的網絡請求[23].在微服務架構中,服務端的軟件模塊維護一個可用的服務端清單；客戶端節點也需維護本身所訪問的服務端清單，而這份服務端清單來自于(微服務架構中獨有)服務注冊中心，例如Eureka服務注冊中心；同時，客戶端需要維護服務端清單的健康性，也需與服務注冊中心配合完成[24].其中，SpringCloud Ribbon是微服務架構中基于客戶端的負載均衡工具，將面向服務的REST(representational state transfer)模板請求自動轉換成客戶端負載均衡的微服務調用[25].

此外，微服務架構支持的負載均衡算法還包括隨機分配服務器算法、生成請求源IP Hash值方式，精確找到服務器的IP Hash算法等相關算法.這里不再一一贅述.

1.3 服務容錯

容錯，即將系統錯誤產生的影響限制在一定邊界內.在微服務體系結構中調用集群服務時，若單個微服務調用異常，產生如連接超時、請求失敗、流量突增或負載過高等問題，則需要制定容錯策略進行容錯處理，使微服務具有自我恢復功能.

服務容錯分為2種情況：1)若產生超時異常，可采用超時重試機制[26]，通過設置服務請求超時響應時間；或者服務的響應時間和次數，進而決定是否采用超時重試機制.2)若服務因負載過高引起異常，可采用限流和熔斷器2種容錯策略.其中，限流是以限制服務的最大訪問量或者訪問速率的方式，對服務進行容錯處理，熔斷器會記錄和監測服務執行情況；若監測到某個服務實例超過閾值，可拒絕接收服務請求將其直接返回.目前，微服務框架支持的容錯策略還有控制并發、線程隔離等策略；如果連續失敗多次則直接熔斷，不再發起調用，避免單個服務異常影響系統中整體服務的運行.

1.4 服務網關

服務網關(service gateway)作為微服務架構中的重要組件，其關鍵思想是：將輕量級網關作為所有客戶端/消費者的主要入口點，并在Gateway(網關)級別實現常見的非功能需求.服務網關的基本功能有：統一接入、安全防護、協議適配、流量管控、長短鏈接支持、系統容錯能力等.目前已有許多成功的應用案例.例如，由Netflix公司開發的Netflix Zuul[27]是目前較通用的服務網關組件；其主要作用是協調客戶端與微服務的中間層，提供權限驗證、壓力測試、負載分配、審查監控等較為全面的服務網關功能.其中，Zuul主要負責處理RESTful的服務請求及調用.然而，在部分微服務業務場景下,仍存在“外部客戶端是RESTful的接口請求,而內部服務之間卻是RPC通信”的情況.因此，產生同一系統具有2套不同類型的API接口，無疑增加了通信的復雜度.由此，GRPC Gateway通過讀取GRPC服務請求并為其生成反向代理服務器,將RESTful的HTTP/JSON API接口轉化為內部GRPC的形式,從而解決了服務內外接口不兼容這一問題[28].其他網關解決方案這里不再贅述.

1.5 服務部署和服務通信

作為微服務框架核心部件之一，微服務部署和服務通信具有至關重要的作用.微服務部署中關鍵問題之一是如何做到獨立于其他微服務部署，使每個微服務級別都可以進行部署與擴展.從而在單個微服務的故障不影響任何其他服務前提下，快速構建和部署微服務，Docker[29]作為一種開源應用容器引擎，以應用打包以及依賴包到一個可移植容器中的方式，達到上述功能需求.其具體理念是：將每個服務實例部署為容器，微服務作為Docker容器鏡像打包，根據容器實例數量變化進行縮放.在Docker容器部署過程中，使用Kubernetes應用平臺組件，將一組Linux容器作為單個系統進行管理，在多個主機上管理和運行Docker容器；根據容器的部署位置，進行服務發現和復制控制等機制，以期對Docker功能進行擴展與伸縮.基于此種方式，構建、部署和啟動微服務的速度將會大大提升.其中，Kubernetes技術為Docker容器部署微服務提供了強有力的支持.

服務通信是指網絡傳輸過程中，服務之間進行信息交互或消息傳遞.其關鍵是保證具有良好的通信機制，實現準確、高效的信息交換.在微服務框架中，微服務通信方式分為同步和異步2種模式.在同步通信模式下，客戶端發出請求，服務器即時響應.這種通信模式實現較為簡單，沒有中間件做代理，一般采用REST和Thrift兩種協議.其缺點是：通信機制較為單一，制約了進程的速度，在一定程度上降低了系統的可用性.在異步通信模式中，客戶端請求不會阻塞進程，服務端中響應可以是非即時.其優點是實現了客戶端與服務器之間的松耦合，通過中間件進行消息緩沖，實現靈活交互，提高了系統可用性；缺點是基于請求/響應交互模式的復雜性大大提高，為開發人員帶來大量額外工作.在主流系統框架中，一般采用同步、異步混合通信模式以提高系統可伸縮性以及系統可用性.

2 微服務技術的發展過程

從微服務最初定義到逐步被軟件系統平臺應用，微服務技術在不斷發展進步，以適應平臺中數據量大、更新迭代快的特點.下面以微服務軟件技術發展與微服務架構發展2個方面，揭示微服務技術的不斷演變.

2.1 微服務軟件技術發展

早期微服務應用程序受到新一代軟件開發、部署和管理工具的影響較大.然而，隨著微服務架構應用越來越廣泛，管理工具不斷發展創新，目前微服務可以支持更龐大、更加多樣化的用戶數據群.圖4顯示了10種“waves”軟件技術發展的時間表[30]；其中包括應用較為廣泛的工具，這些工具在過去10年中極大地影響了微服務應用程序開發、部署和運行等方面.

在“微服務”概念提出之前，業界已經誕生5次相關新技術[30].

1) 輕量級容器(lightweight container engine)技術(例如LXC和Docker)，允許在系統運行時有效地對各個服務打包、部署和管理.

2) 服務發現(service discovery)技術(例如Eureka和Consul)，允許服務彼此通信而無需明確地參考服務網絡位置.

3) 監控(monitoring)技術(例如Graphite和Sensu)，能夠在不同層次程度上監控和分析微服務資源的行為.

4) 容器編排(container orchestration)技術(例如Mesos和Kubernetes)，自動化分配容器和管理任務，開發人員從底層架構中抽象出底層物理或虛擬基礎架構，為開發人員提供一個抽象層，以確定應用程序部署在服務器以及數據中心中.

5) 建立延遲和容錯(default tolerance)通信庫(例如Finagle和Hystrix)，使服務進行更有效地執行，更可靠地通信.

后5次系統軟件管理方法的提出，為微服務系統實施提供了底層技術支撐.

6) 包括持續交付(continuous delivery)技術(例如Ansible和Drone)即指通過軟件自動化的方式，快速迭代發布軟件；允許團隊頻繁地交付快速更新的軟件產品.其特征是持續整合、內置測試、持續監控和分析反饋.為系統提供了通用集成的解決方案[31]，并且在Web級微服務生產環境中已經進行DevOps實踐.

7) 混沌工程(chaos engineering)技術(例如Simian Army和Chaos Toolkit)[32]可自動解決系統中出現的故障，具有高可靠性與高可用性等特性.

8) 邊車(sidecar)技術(例如Prana和Envoy)[33]，封裝與通信相關的功能.例如服務發現以及特定協議和容錯通信庫的使用功能，使服務開發人員快速獲得通信消息.

9) 包括“無服務器”計算(serverless computing)技術(例如AWS Lambda,OpenWhisk,Amazon Web Services)[34]，實現了“功能即服務”(functions as a service， FaaS)云模型.這種模式允許云用戶開發、部署及交付更精細的服務功能，而無需創建和管理(如應對不一致的流量模式)復雜基礎模塊執行所需的資源.

10) 服務網格(service mesh)技術(例如Linkerd和Istio)[35]，以邊車技術為基礎，提供完全集成的服務通信監控.

圖4中大部分工具都源于工業應用領域.作為開源項目提供給用戶下載與應用.其中，表2給出了每個工具的URL網址[30].

Table 2 The Web Site of the Microservice Tool in Figure 4
表2 在圖4中微服務工具的網址(URLs)

2.2 微服務架構的發展

在工業應用中，一個完整的微服務架構由多個元素構成，它具有獨立的生態圈；不但需要基礎設施配合，還需生產環節部門共同協作；不但在系統運行時進行管理控制，而且還要具有安全保障的服務治理.其中，微服務治理從4個步驟[36]進行：1)請求網關.常用有Zuul,Spring Cloud Gateway等組件.2)信息采集.具有服務注冊發現、服務日志、鏈路追蹤等功能.3)信息分析.具有時序性統計、監控平臺以及監控報警等功能.4)治理策略.具有負載均衡、請求限流、服務容錯與服務配置等功能.在傳統微服務架構中，可能需要鏈接不同的容器和主機，以使多個微服務共同協作[37]完成一項業務.在此種架構中，若使用傳統的日志定位出現問題的容器和主機，不僅會耗費大量的人力與物力，而且可能導致系統運行失誤.

在此種情境下，需要在技術層面提供分布式調用鏈跟蹤能力，以能夠快速定位出現問題的節點.同樣，在微服務架構中，原來整體式系統分解成多個微服務，在此種情況下，傳統的逐步式部署方式已不再適合.自動化部署方式成為軟件系統所面臨的必然選擇.此外，出于服務治理和系統安全考慮，需要對分散的微服務進行集中管控,因此，服務網關也是必不可少的組件.這些組件構成是由微服務特點所決定的.具體而言，微服務架構生態圖[38]如圖5所示.同時，由圖5中微服務相關技術逐步發展，這些技術革新的影響在微服務應用程序架構發展中有明顯體現.

圖6概括了4代微服務體系架構[30].其中，在第1代結構中，如圖6(a)所示，使用輕量級容器技術(如LXC)打包每個服務，然后使用容器編排工具(如Mesos)在運行時進行部署和管理.每個服務都負責跟蹤其他服務的位置，并且根據特定的通信協議調用其他服務；任何故障處理機制(例如重試和回退)都直接在服務的源代碼中產生深遠的影響.隨著應用程序中服務數量的增加，應對不同執行環境中部署和重新部署服務日益增長的需求，調用正確的服務實例成為一個難題.此外，新服務的實現語言不盡相同，因此重用現有代碼以及快速有效地處理故障變得愈加困難.

為解決上述問題，第2代引入了服務和可重復利用的容錯通信庫，如圖6(b)所示服務使用公共發現服務(例如Consul)來注冊其提供的功能.客戶端服務可以動態發現和調用這些功能，而無需明確被調用服務的位置.在服務調用期間，所有特定協議和故障處理功能被委托給相對應通信庫；例如Finagle；該策略不僅簡化了服務實現和測試，還允許跨服務重復利用的樣板通信代碼.

然而，隨著通信庫功能愈加復雜，利用不同編程語言對通信功能重新實現變得越來越困難.開發人員經常被迫使用當前程序編程語言來實現新服務，無疑增加服務接口的難度.由此，微服務可以使開發人員自由編寫程序，開發人員可以自主選擇任何編程語言，或以適合特定服務的需求選擇相對應開發編程語言，這是之前技術所不具備的優點.

因此，第3代引入標準服務代理或sidecars邊車模式，如圖6(c)所示，例如Envoy作為可檢測的服務中間體.基本思想是通過邊車封裝所有服務發現和通信功能，從而提高軟件可重用性.由于每個邊車都是一個獨立的服務，因此該策略將現有容錯通信庫的優勢帶到新的編程語言，從而大大提高了自主開發性.

當作為網絡中介時，邊車成為監控微服務應用程序中所有服務信息交互行為的場所.這些工具擴展自包含邊車理念，以提供更加集成的服務通信解決方案.應用運營商可以集中控制平面動態監控和管理多個分布式邊車的行為.基于此種方式，運營商可以對各種服務及服務通信功能進行更加細粒度的控制，包括服務發現、負載平衡、容錯、消息路由和安全性等功能.

第4代旨在將微服務應用程序引入一個全新的應用領域，如圖6(d)所示基本思想是利用最新的FaaS技術和無中斷計算技術，簡化微服務底層開發和持續交付[39]操作.這種無服務器架構，其基本思想是將微服務應用程序變成“短暫”函數的集合，每個函數根據特定需求，進行快速、創建、更新、替換和刪除等操作，從而極大地提高微服務的運行、部署等操作效率.當然，這種無服務器架構仍然需要以通信為中心的技術,例如邊車技術和服務網格.現有FaaS平臺并未提供融合2種技術的通信和流量管理功能.因此，若在無服務器應用程序中創建函數到函數的交互，一個具有更全面控制功能的服務(或功能)網格應被創建，以便監控和管理這些邊車功能的行為.

3 微服務關鍵技術

微服務強調服務功能的大小，但在實際應用中并沒有統一標準.一個功能相對簡單的微服務在實際需求與擴展中會變得更加復雜，并且同一業務由多個微服務共同協作完成.由此，微服務存在3個問題：1)在分布式協作方面，存在微服務之間通信、分布式數據存儲一致性等問題；2)在微服務定位方面，如何快速定位出現的性能瓶頸.3)在測試方面，眾多的微服務如何協調一致，保證測試的準確性.基于這3個問題，微服務的順暢運行主要采用一些關鍵技術.

3.1 微服務分布式通信

首先，在功能相互依賴的大型網絡系統中，服務之間的實時通信顯得尤為重要.在微服務架構中，每1個服務都是1個進程，使用進程間通信(inter-process communication， IPC)技術，以實現進程間信息交互.IPC將進程間的交互模式分為2種：1)1對1交互模式與1對多交互模式.簡而言之，1對1模式即是單個客戶端向服務器端發出請求，客戶端期望此響應即時到達；然而在線程應用中，請求傳送過程可能造成線程阻塞.2)1對多交互模式即是一個客戶端發出多個通知，被多個相關聯服務消費模式.進程間的通信統分為以上2種模式，而在實際技術應用層面，不同編程語言對應著不同的通信技術.以Java底層編程語言為基礎的微服務架構通信為例，闡述相關技術及協議的應用.在早期分布式初步通信時，采用RPC(remote produce call)，即遠程過程調用協議[40]，是基于客戶端/服務器(Client/Server， C/S)模式調用機制，客戶端向服務器端發送調用請求等待服務器應答，是一種典型的請求應答機制；其基本過程是本地分布式對象向本機發出請求，不用開發人員編寫底層通信代碼，直接向服務器發送請求；服務器對象接受請求信息后，經過計算將處理后的結果返還回客戶端.然而，由于RPC不支持面向對象，使用的場景大幅度降低；進而促進遠程方法調用(remote method invocation, RMI)協議[41]的發展，RMI協議支持面向對象；采用客戶機(stubs)和框架(skeletons)進行遠程對象(remote object)的通信.stubs模擬成遠程對象的客戶端代理，具有與遠程對象相同的遠程接口；遠程對象調用操作實際是通過調用該對象的客戶端代理對象stub來完成，實現效果與調用本地對象相同.其優點是支持分布式對象、跨平臺高速率的數據傳輸；缺點是不能跨越編程語言進行數據傳輸.

隨著微服務的架構廣泛應用，相對應的通信協議也在成熟發展以適應層次不同的通信要求，如JMS(Java message service),Web Service等通信標準已被較為成熟地應用.

3.2 分布式的數據存儲一致性

傳統整體架構是基于數據庫提供的事務一致性[42]標準，即通過數據庫提供的提交以及回滾機制中相關操作的原子性、一致性、隔離性、持久性(atomicity,consistency,isolation,durability, ACID)，保證數據庫中的數據一致性.在微服務架構中，每個微服務具有獨立的數據庫，以保證微服務進程獨立演進、獨立開發.然而在分布式環境中，每個服務訪問數據是相互分隔，服務之間不能依靠傳統數據庫中ACID保證事務一致性.由此，基于對微服務分布數據一致性要求，開發人員在初始階段采用2階段2PC(two phase commit)提交協調機制，該機制為分布式事務提供了強一致保障.然而該機制存在隔離性互斥的特點.在事務執行過程中，所有的資源都是被鎖定的，該機制只適合執行時間確定的短事務，并降低了系統的吞吐率.基于此種情況，開發人員通過業務邏輯將互斥鎖操作從資源層面移到業務層面，即提出TCC(try,confirm,cancel)方式.通過Try(嘗試執行業務)、Confirm(確認執行業務)及Cancel(取消業務)三種操作方式，達到數據最終一致性，以提高系統整體性能.但是TCC方式中，微小事務變動，牽動整個業務邏輯，復雜性較高.Saga事務[43]正好彌補該缺點.Saga事務就是一個長期運行在線的事務，由多個本地事務所組成，每個本地事務具有相應的執行模塊和補償模塊.當Saga事務中任意一個本地事務出錯，可以通過調用相關事務對應的補償方法進行恢復，達到事務最終一致性目標.然而Saga只提供ACD(atomicity,consistency,durability)，不能保證事務的隔離性.由此，產生諸如2個Saga事務同時操作一個資源出現語義不一致、2個Saga事務操作同一個訂單出現更新丟失等問題，但可以采用在應用層面加入邏輯鎖邏輯或者在Session層面隔離來保證串行化等操作，以實現數據分布一致性.Saga的實現方式可以分布2種:1)集中式實現方式，即協調器負責服務調用以及事務協調.2)分布式實現方式，即以事件驅動的底層方法進行事務協調.在2017年5月，Saga模式在華為開源微服務框架[44]中已被應用，并且在不斷地發展進步.

在微服務分布式數據存儲一致性方面，不同系統具有不同性能、環境以及對事務協調一致性的要求，采用不同模式事務分布機制以達到分布式數據存儲一致性的要求.

3.3 分布式調用鏈

在微服務架構下，服務按照不同維度進行拆分.由此，一次業務請求需要調用到多個微服務.系統應用構建在不同軟件模塊中，存在不同模塊由不同的團隊、編程語言實現.同時，可能部署在幾千臺服務器，橫跨成百個不同的數據中心.因此，亟需理解系統行為、用于分析性能問題的工具，以便發生故障時能夠快速定位和解決問題.分布式調用鏈應運而生，即可以監控那些橫跨不同應用、不同服務器之間的關聯動作，進而快速定位與解決故障.

Google公司首先開發其分布式跟蹤系統并且發表相關論文[45]，Twitter參照該論文設計思想開發zipkin分布式跟蹤系統，以期為微服務架構提供參考.zipkin通過采集跟蹤數據，從而使開發人員深入了解在分布式系統中某一個特定請求如何執行.例如，存在一個用戶請求超時，跟蹤系統可以將這個超時的請求調用鏈展示在UI當中.開發人員可以快速定位出現故障的服務，具體可定位到服務中導致超時的具體位置.同時，通過服務調用鏈路能夠快速定位并解決系統的性能瓶頸.同時，針對不同的應用系統，存在其他的應用程序性能管理(application performance management， APM)工具，如Pinpoint是一款針對Java編程語言大規模分布式系統的APM工具，通過JavaAgent機制字節碼代碼植入，實現加入traceid和抓取性能數據目標；Central Application Tracking是由國內大眾點評網開源出來的追蹤系統，已被成熟應用[46].

在分布式調用鏈方面，不同的系統平臺根據其特有的功能屬性，開發符合其特點的追蹤系統以及調用鏈.

3.4 測試方面的復雜性

隨著平臺系統開發模式逐漸從傳統的整體式產品向快節奏的微服務架構遷移，軟件測試人員也必須相應地調整測試方法和工具，才能快速便捷地提高測試覆蓋率.傳統整體應用只需測試單一的REST API(application programming interface)測試，需要啟動相關聯所有其他服務，使得測試復雜性較高.在開發-測試-部署方面，業界已經具備一套較為成熟的解決方案.然而微服務架構是一種演進式架構，系統最初劃分獨立服務的數量可能極少；隨著業務復雜功能分解與擴展，微服務數量不可避免地增加.同時，微服務數量眾多，功能相對獨立；在執行業務過程中，難免需要跨服務調用.如何保證跨服務調用的可靠性以及不同階段的開發測試？

在微服務測試方面，系統被分解成獨立的微服務，即每個微服務都是一個功能完整的小型系統.首先需要保證服務自身業務功能的正確性，即通過單元測試保證每個微型系統正確執行.其次，由眾多微服務構成完整的系統，需要集成測試來保證整體系統的良好質量.然而，在一個微服務架構中，微服務的個數達到一定閾值時，開發團隊面臨如網絡環境不穩定、運行速度慢、反饋周期長等問題，因此對集成測試望而卻步.進而，開發人員采用Pair集成測試，即將集成范圍縮小，保證兩兩微服務集成的可靠性.但是這種Pair測試方法存在模擬(Mock)其他服務，反復測試已經測試過的服務等問題，增加了額外的工作量.由此，引入Contract概念的集成測試[47]，即前端與后端開發人員基于業務共同定義API協議(Contract)；該協議以JSON文件形式存儲于代碼庫的測試資源目錄中.前端在開發過程中以JSON文件作為測試正確依據，后端開發人員則參照該協議編程實現相關API.這種方式具有環境簡單、運行快等優點.但是若存在任意一方修改協議內容，測試便會失敗，缺乏自動化監控機制[48]以及不能提前發現問題等缺點.在基于Contract概念的基礎之上，消費者驅動契約測試(consumer-driven contract testing)將Contract契約中JSON文件轉換成可工作軟件時，文檔的細微修改便會導致任意一方測試失敗；并且通過可工作測試套件保證契約一致性與實時性.由此，成為雙方共同遵守的契約.

3.5 微服務應用案例

在現代企業中，微服務所具有的高可用性、容錯性、可管理性、可替代性[49]等優點，滿足企業用戶的主要業務訴求；由此，越來越多的軟件架構采用微服務架構.基于微服務以上關鍵技術，以教育網站的部分功能為案例[50]，講解微服務技術架構的具體應用.

教育網站具有3部分功能：1)用戶可以登陸注冊、獲取用戶基本信息的功能；2)向用戶發送郵件、短信的功能；3)可以查看課程列表和對課程的基本增加、讀取、更新、刪除等功能.如圖7所示，展示教育網站部分功能整體架構.

網站采用Java為底層基礎語言，部署在輕量級容器Docker中進行實現.根據教育網站部分功能的劃定與分析，進而將整體架構進行分解為登錄注冊微服務、用戶信息微服務、郵件短信微服務以及課程微服務等部分.對于微服務之間的通信，從通信協議角度，采用RPC協議；該框架具有系統可擴展性、持續交付能力與高可用性等優點[51].常用的RPC框架有Dubbo,Motan,Thrifty,GRPC等,采用Dubbo框架實現教育網站中部分功能的通信功能.如圖8所示，展示Dubbo框架的架構[52].其中，短虛線表示系統啟動過程中的初始化階段，長虛線表示異步通信模式，實線表示同步通信模式.在注冊服務部分，服務提供者向注冊中心注冊所提供的服務；在訂閱服務部分，服務消費者向注冊中心訂閱所需的服務；在通知部分，注冊中心返還服務提供者地址列表給消費者；在調用部分，采用同步通信，基于負載均衡算法，服務消費者從提供列表中選擇一臺提供者進行調用，若調用失敗，則重新選擇.

在微服務架構方面，SpringCloud是一系列框架的有序集合，具有服務發現與注冊功能的Netflix Eureka、客服端負載均衡功能的Netflix Ribbon、服務網關功能的Netflix Zuul與分布式配置功能的Spring Cloud Config等核心組件.網站中的服務網關采用具有易于認證、易于監控的Netflix Zuul組件.如圖9[50]所示，客戶端請求服務調用，通過API Gateway，轉發到后端微服務的REST API，以期調用網站中各個微服務；每個微服務具有獨立的數據庫，進而查詢每個微服務基本信息，實現用戶所需功能.

SpringCloud框架是具有高質量、穩定性與持續性等特性的一系列核心組件，可以完成以Java編程語言為基礎的微服務架構的核心功能，這里不再一一贅述.

基于對微服務核心組件與關鍵技術的介紹，微服務架構具有4個優勢：1)整體式應用分解為具有獨立功能的微服務，提供多種服務方法，解決系統整體功能復雜性問題；2)每個微服務可以由專有團隊開發，對編程語言具有寬泛的選擇性；3)每個微服務可以獨立部署，提升系統部署的效率；4)由于每個微服務具有獨立性，易于在原有微服務基礎上進行功能擴展，提升系統的整體可擴展性.然而，微服務應用采用的分布式架構，具有其固有的復雜性，因此，面臨以下挑戰.

4 微服務面臨的挑戰

雖然微服務相關技術在逐步發展創新，但由于微服務相當于是相對獨立的小型軟件系統，在一個具有多種功能、多樣性復雜的大型系統平臺中，如何在一定人力物力成本中，快速部署微服務以及大量底層應用組件，使其具有自動化部署功能；微服務之間如何迅速準確地通信，以滿足用戶快速響應的需求；如何在正常通信中，保證用戶的數據信息安全；在數量眾多的微服務中，如何保證數據傳輸中的網絡安全.基于這些問題，微服務面臨4種挑戰.

4.1 基礎設施

隨著分布式系統中應用程序需求迅速增長，傳統依賴于客戶端向服務器處理端發起請求的整體體系結構開始發生轉變；這種體系結構不足以應付不斷增長的快速請求；面向服務的體系結構發展成為客戶端-服務器體系結構中最成功表示形式之一，然而，從功能角度，SOA架構中服務之間通過相互依賴最終形成一系列的功能，服務組件大小既可以是小型應用程序服務，也可以是大型企業應用程序，部分組件可以實現多項功能；由此，SOA仍然屬于整體式系統，不能達到客戶在彈性、可擴展性、快速軟件交付等方面的期望；由此，微服務體系結構利用其本身靈活性、占用更少資源等特性，滿足了商業系統自身特性發展的需要[53].Newman[54]從服務平臺的角度，闡述了微服務架構存在必要性；系統可以通過微服務使用不同的技術、不同編程語言進而滿足不同的應用需求；與此同時，微服務之間相互獨立與更新，可以通過大型虛擬機運行，如使用VMW和AWS(amazon Web services)等虛擬技術；然而一方面，配置大型虛擬機耗費較長時間；另一方面，管理程序層具有很大的運載負荷；基于此，容器技術被提出，如Linux Containers[55]，容器技術為程序提供了分割的空間，而不需要管理程序層控制整個虛擬機.隨著容器技術的發展，Docker創建了輕量級容器技術，具有將服務及其依賴項打包成單個映像的特性，使其具有代碼移植性[56].每個微服務都位于本身容器內，因此需使用調度程序協調微服務之間事務一致性，由此產生“集群管理器”，其基本任務是確認主機與之相對應的容器[57].同時，微服務分布在不同容器內，使之只能使用輕量級通信.利用其HTTP特性，REST API成為最適合微服務的消息交換機制，可以使用多種語言格式，如XML與JSON[58].

在網格和集群計算時代，通用監控工具只能關注監控性能與數據中心資源級別的層次，但不能監控到微服務層次，如Amazon EC2容器的監控技術框架并不能監控到微服務級別的服務表現.由此，收集、整合所有微服務和數據中心資源的整體技術作為新課題被提出[59-60].另一方面，在部署階段跟蹤通過網關的微服務請求流，增加了監控成本[61].Kang等人[62]基于對容器中管理服務狀態面臨挑戰的研究，對于容器服務管理和監控，則需動態服務發現和注冊等組件.

追根究底，微服務目的是使系統在水平擴縮容和彈性伸縮方面更加敏捷、迅速，但前提是仍需基礎設施自動化，如何實現微服務基礎設施自動化？就目前發展來看，是微服務發展過程中不可避免的挑戰.

4.2 信息交互

在微服務信息交互方面，若單個服務由攻擊者掌控，該服務可能會惡意影響系統其他服務.由此，微服務架構應該驗證微服務之間信息交流的真實性與正確性.從微服務信息交互的認證權限角度，Gegick等人[63]只將最低和必要權限分配給相對應的用戶，并且在最短時間生效.通過謹慎授權訪問權限方式，限制攻擊者破壞系統.從授權協議的角度出發，輕量級目錄訪問協議(lightweight directory access protocol, LDAP)[64]是在SaaS應用程序中常用的認證協議;通過LDAP，服務可以存儲相對靜態授權信息，適合于一次記錄，多次讀取的應用場景.在數據結構方面，基于樹結構的LDAP有效、清晰地描述組織的結構信息，簡化了目錄訪問協議(directory access protocol, DAP)，以提供基于TCP/IP網絡的輕量級協議，降低管理維護成本.

針對系統內部的共享資源，一些學者認為授權策略應該以層次結構方式構建，以實現可伸縮性與可表達性.為達到層次性訪問控制，網格安全基礎設施(grid security infrastructure, GSI)[65]被廣泛應用，其包括私鑰保護和通信加密等步驟.與傳統的授權系統相比，基于分布式管理機制的社區授權服務(community authorization service, CAS)模型[66]，允許資源提供者授予部分權限，既可以對社區細粒度訪問控制進行維護，又對資源保持最大控制，提高系統的可擴展性與靈活性.Patanjali等人[67]提出了基于模塊化的微服務架構；通過動態評級、計費模式為云服務提供商驗證相關接口.基于對服務提供商在整個應用程序生命周期中權限安全性要求，Thanh等人[68]利用包含網絡功能虛擬化等新興技術的微服務框架DevOps[69]，該框架具有2個重要的安全優勢:1)是虛擬化安全功能/服務，框架為用戶選擇和集成多個供應商提供安全解決方案；2)對于網絡層訪問控制，利用防火墻即服務(firewall as a service, FWaaS)[70]技術，使用戶對進入和離開應用程序的網絡流量采取不同訪問控制策略.Li等人[71]采用微服務框架OAuth保證相關權限的安全性，OAuth框架授權第三方訪問用戶帳戶以及用戶身份，但是第三方網站可以以訪問用戶帳戶臨時密鑰方式得到訪問用戶身份信息，由此產生用戶私有信息泄露問題.Cheung等人[72]基于微服務的框架，采用第2版本的OAuth修復用戶信息漏洞等問題，采用HTTPS協議并簡單化授權驗證過程，但上述問題仍然存在.在信息交互方面，微服務框架與對應接口認證權限，仍需不斷地擴展、改進.以適應大數據時代下用戶需求以及隱私信息保護需求.

在微服務信息交互層面，仍存在其他問題，如信息交互用時較長、信息交互準確率較低等問題.基于以上闡述，微服務信息交互在信息安全性、網絡穩定性等方面，仍面臨巨大挑戰.

4.3 數據安全

在微服務數據安全方面，微服務架構在云環境中應用越來越廣泛，微服務中分布式數據隱私信息保護以及保密性越來越被重視.部分學者采用密碼學中傳統加密方式對數據進行加密.基于密碼學的加密技術可以分為對稱與非對稱方法[73-76].對稱加密技術，即是通過加密密鑰對原始數據進行加密，反之亦然.非對稱技術，即是通過公有/私有密鑰對原始數據加密，只有相對應私有/公有密鑰才能進行解密.一般來說,加密密鑰越長，加密后的數據也更加安全.然而，這表示在加密與解密過程中產生更大性能開銷[77].基于此，考慮到微服務模型中數據具體應用場景與對部分敏感信息的保護，學者們力求在計算復雜度與數據安全保護取得平衡.Shah等人[78]從提高數據安全性角度，利用第三方審計協議，允許用戶評估風險并提高降低風險的效率；同時還提出了支持在線存儲內部服務和外部審計的數據隱私方法.審計目的是監控服務器和網絡中用戶詳細行為信息記錄，一旦發現違反安全策略相關行為信息，立即向管理員報告.Wang等人[79]僅從數據加密角度出發，并沒有考慮對審計協議的設計，由此并不能保證數據不會被泄露給第三方平臺.

微服務是分布式的，即擁有眾多不同的數據服務平臺，由此需對不同數據來源加以保護.Callegati等人[80]從數據可靠性、完整性和真實性角度出發，采取4個步驟進行保護數據源:1)提出一個具有可驗證性、可問責性和可生產性的數據源管理系統,可驗證性是指管理體系應能夠驗證與操作有關的參與者(或服務)的數據源,可問責性即是指管理系統應能夠讓參與者(或服務)對其在數據源中的行為負責,可生產性是指管理系統應能夠在數據源上生產過程；2)為數據流認證創建一個私有和公共密鑰系統；3)使用基于密碼學出處驗證方法確認數據源主機數據屬性與完整性；4)將數據元數據傳播與密鑰分發傳播管理相結合，確保數據源管理系統的可靠性.基于以上4個步驟，既可以有效地進行微服務架構信息交流，又可以對數據來源進行有效保護.Subashini等人[81]從企業數據安全的角度，建議對數據供應商采取額外的安全檢查，以確保數據源安全并防止應用程序中安全漏洞.企業數據定期備份使用強加密方案，便于在發生緊急情況時快速進行數據恢復.Saad等人[82]以對數據源全方位保護角度，建立保障數據源存儲與訪問事務處理安全的信任模型，提高了服務之間信任度.

基于以上闡述，在微服務分布式結構中，如何有效保證數據源信息的安全以及對第三方平臺數據有效認證，是十分值得思考的問題.

4.4 網絡安全

在微服務網絡安全方面，首先，數量眾多的微服務帶來網絡復雜性，增加監控整個應用程序安全性的難度.其次，微服務通常被設計成彼此完全信任，因此單個微服務的失誤可能會導致整個應用程序崩潰.Sun等人[83]從微服務增加了監控整個應用程序安全性的難度與單一微服務失敗會導致整個應用程序崩潰的角度，提出了基于微服務云應用安全即服務(security-as-a-service， SaaS)設計方案.通過為網絡管理程序添加一個新的API原語流TAP，進而為網絡流量構建了靈活地監控和策略強制基礎設施，以保護云應用程序的安全.基于對監控數據中心網絡流量和安全威脅模型、方法和設備的描述，Ahuja等人[84]擴展了安全系統中微服務的層次結構.具體而言，創建第1層次結構的新微服務，以配置第1層與第2層次結構中微服務之間的數據平面連接；配置第1層與第3層次結構微服務；同時將新加入的微服務包括在第1個層次結構的負載平衡決策中，以提高微服務網絡安全性.Ross等人[85]研發分布式微服務中提供漏洞掃描系統.該系統包括多個微分段環境，既與云數據中心服務器相關聯，又與云環境的多個微分段環境耦合.云數據中心服務器具有安全控制器與主動探測控制器，前者為每一個微分段環境提供安全策略，后者為主動探測微分段環境設備，并執行漏洞掃描策略.Yarygina等人[86]基于對目前技術僅對微服務系統特定安全問題的研究；提供微服務安全分類，進而評估微服務架構的安全性；最后提出相關合理解決方案，并對Docker Swarm和Netflix的安全決策進行分析.

一方面，微服務安全是一個多方應用結合的問題，目前沒有系統的分層安全解決方案；另一方面，如果這些安全挑戰得到解決，微服務體系結構的安全性將會大大提高.

5 總結與展望

目前，國內外學者對基于微服務技術的SOA架構及其實現機制的研究進展十分重視，微服務具有獨立進程、輕量級通信和獨立部署環境等顯著的特性；將系統整體功能分解到單個微服務中以實現對系統的解耦；這種方式不僅可以降低系統的耦合性，提升系統的內聚性，而且減少服務交互的成本，提供更加靈活的服務支持.本文從微服務概念、核心組件與技術發展過程、面臨挑戰3個方面進行了分析：

1) 論述了微服務體系結構的產生背景、相關概念，指出傳統整體架構不足及微服務體系結構發展背景及優勢.

2) 論述了微服務的核心組件與技術發展，前者在服務發現機制、服務容錯等層面進行研究；后者在技術發展方面，從微服務軟件技術層面以及微服務架構層面2個方面進行概述.

3) 基于對核心組件的介紹，進而對微服務關鍵技術進行分析；提出微服務在基礎設施層面、信息交互層面、數據安全層面、網絡安全面臨的四大挑戰以及發展趨勢.

與傳統開發模型相同，選擇合適的未來開發平臺對于微服務十分重要.微服務如何與2個主要的新興平臺進行集成，即云平臺[87]和物聯網[88].隨著科技新興技術與數據時代的到來，兩個平臺很可能在互聯網行業中占主導地位.由于微服務本身具有移植性和可伸縮性等特性，在物聯網上運行存在部分難題，若在云平臺中運行微服務似乎是恰當的選擇.但從系統安全性角度出發，存在部分功能具有低計算能力且具有較高風險的缺點.因此，微服務與具體應用平臺相結合，解決微服務與平臺相集成的特定實施方案以及安全方案需求，變得更加迫切.

總結

以上是生活随笔為你收集整理的微服务技术发展的现状与展望的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。