微服務體系結構實現框架綜述

辛園園，鈕 俊，謝志軍，張開樂，毛昕怡

寧波大學 信息科學與工程學院，浙江 寧波 315211

1 引言

隨著計算機技術、網絡技術和通訊技術的疾速發展，人們需要分析、設計越來越多高效、可靠的大型軟件系統，如可供全球用戶使用的大型實時社交軟件Twitter、Facebook、WeChat等，在線流媒體服務平臺Netflix[1]以及在線電子商務平臺如Amazon、Alibaba（淘寶）等。在設計階段，良好的體系結構設計是大型軟件系統能夠正常運行的前提和基礎[2]。

一般來說，軟件系統的體系結構規定了系統各個構件單元的集合及構件之間交互、協作或通信應該遵循的規范或協議。一直以來，企業或開發人員都在努力尋找好的軟件體系結構設計來構建應用系統，以期望滿足企業業務需求，提高開發效率，方便業務擴展并能適應時代、技術發展的潮流。大量傳統應用系統由于具備規模較小，結構簡單，用戶群體小及實時通信要求低等特點，通常采用傳統的單體架構模式。所謂單體架構即指將整個軟件系統的功能模塊及運行數據等作為整體看待，統一地設計、開發、打包及部署運行[3]。然而，對于需要應對業務邏輯復雜，數據量龐大和具有高實時性，高可靠性，高伸縮性運行要求的在線軟件系統來說，單體架構存在較多不足。首先，單體應用的代碼龐大，代碼耦合度高，系統靈活性較差；其次，單體架構受技術限制，所有模塊都采用相同技術，難以實現技術協同；第三，單體應用的創建或部署時間較長、成本較高，難以實現持續發布及部署。更為重要的是，單體應用難以被擴展，可伸縮性較差[4]。

近年來，隨著云計算、容器虛擬化以及集成了開發、測試、部署和運營為一體的DevOps[5]等技術的興起和發展，微服務受到工程界和學術界的極大關注，成為信息科學領域的重點研究對象之一[6]。其基本思想是將傳統的單體應用按業務功能拆分為一系列可被獨立設計、開發、部署、運維的軟件服務單元，服務間彼此配合、相互協作以實現最終價值[4]。實際上，微服務可看作面向服務體系結構（Service-Oriented Architecture，SOA）[7]的一種具體實現。另一方面，與Web服務相比，微服務更具優勢，例如采用去中心化管理及輕量級容器部署，提供監控預警及多種高可用容錯策略，服務數據獨立且開發自由。

微服務體系結構的思想將為企業級系統應用的實現提供指導，而微服務框架（Microservice Framework）則是微服務體系結構的具體實現及解決方案。它是企業在構建微服務時考慮將眾多關鍵技術如服務部署、服務通信和服務發現等集成為一個整體，從而形成的一種框架或方案。實質上，微服務框架是眾多優秀開發者已有實踐經驗的總結，企業在實踐或運用微服務框架時，不僅可以提高開發效率，降低開發成本，還可以對框架進一步優化及拓展以滿足多樣化業務需求。目前，微服務框架已被越來越多的中大型企業成功實踐并并取得較好的發展，較典型的有Amazon、Netflix、Uber等公司。本文首先回顧并對比了服務計算、Web服務及微服務的基本概念；第3章介紹了當前較為主流的微服務體系結構實現框架，重點就這些框架中的關鍵技術及核心部件展開詳細分析及對比；第4章介紹微服務框架中服務組合模式存在的問題、服務組合應考慮的關鍵因素及組合方法研究現狀，最后總結了全文。

2 Web服務與微服務基本概念

2.1 Web服務及基于微服務的體系結構

隨著互聯網技術的發展，大型IT系統一般采用分布式計算模式，以優化資源配置并提高系統可靠性、可用性和靈活性等。為了便于分布式信息系統的設計、開發與集成，以及提高系統架構的靈活性、復用性和可增長性，面向服務的體系結構SOA因此產生。SOA體系結構將定義良好的，具有開放接口并獨立于軟硬件平臺以及實現技術的單個服務組件關聯起來，以構造整體應用并采用松耦合的方式保護既有IT基礎設施[7]。實際上，SOA只是一種架構思想，而Web服務及其相關標準和SOAP、WSDL、UDDI等協議的出現，則為SOA的具體實踐提供了技術支撐和處理方案。Web服務基于SOA架構理念，采用一套標準技術實現了對企業間服務資源的共享和復用。SOA體系結構及Web服務等相關標準和技術的產生，為構造松耦合的大型分布式應用指明了較好的方向，并做了開拓性工作。

盡管Web服務為跨平臺的企業開發提供了方便，但是在開發模式上，仍然采用的是單體架構。單體架構由于自身特點較適合小型應用的開發，并不適用于業務復雜度較高、業務需求量較大的中、大型企業。微服務體系結構思想的出現，則較好地解決了上述難題。其核心要義在于基于面向服務的思想，對傳統大型應用系統進行功能分解，推動細粒度服務的使用。微服務架構（MicroServices Architecture，MSA）則指根據應用系統的業務需求，通過對預定義的微服務進行重組而形成企業級應用的分布式體系結構[8]。它主要將傳統概念上的單體應用在功能、數據等方面進行分解，劃分為多個具有明確邊界并可被自由重組的小規模子服務。這些子服務間采用輕量級通信方式實現交互、協作，每個服務都有自己的數據庫并可在獨立進程中被部署、運行等，服務之間保持技術異構性，可由不同的團隊選擇合適的工具、語言進行開發。

與單體架構相比，微服務架構的優勢在于：（1）微服務按業務功能劃分，每個服務都具備特定的功能，易于開發、維護等；（2）每個獨立的微服務可以由不同的語言基于不同的平臺開發，靈活性較好；（3）子服務可獨立部署，能夠實現可持續集成及交付；（4）容錯能力強大，單個微服務出現問題不會影響系統其他服務的運行；（5）可實現動態按需實時擴展等。目前，微服務體系結構的思想已被應用于很多大型公司的分布式應用系統中。

2.2 Web服務與微服務架構的比較

Web服務作為SOA的具體實現，遵循相應技術規范，為面向網絡的分布式應用提供統一的服務注冊、發現、調用等機制。盡管Web服務體系結構與微服務架構在實現服務治理功能上存在相似之處，但在架構本質設計方面仍存在一定差別（具體如表1）。實際上，Web服務體系重在解決異構資源的整合，通過企業服務總線ESB（Enterprise Service Bus）將不同服務集成到企業應用中。盡管ESB在企業級應用構建中獲得成功，但其重量級特性使其靈活性降低，不能很好地支持大型企業級應用的持續變更、發布及部署等。而微服務架構提倡輕量級的服務架構理念，在實踐時采用去中心化的思想，并無Web服務中的重量級ESB，服務間的交互也采用如RESTful HTTP[3]這類輕量級協議。另一方面，在微服務架構中，服務是按業務功能劃分，服務間彼此獨立并具有獨立數據庫，因此，可單獨部署運行在輕量級Docker容器[9]中實現敏捷性開發及部署，更適合現代企業的發展。

3 微服務體系結構實現框架

微服務體系結構為構建具有較高伸縮性需求的大規模應用系統提供了“藍圖”，在實施微服務架構時，還應具體給出服務發現、服務通信、服務容錯、負載均衡和服務部署等解決方案[10]。到目前為止，工程界已出現若干基于微服務體系結構的實踐框架（Microservice Framework，MF），如阿里巴巴集團的Dubbo[11]、微博團隊的 Motan[12-13]、Lightbend公司的 Lagom[14]，以及 Google和IBM等共同開發的Istio等[15]，這些微服務框架通常由服務注冊與發現、負載均衡、服務網關和服務容錯等核心部件聚合而成。本章基于以上構成微服務框架的核心部件及技術，對目前使用較主流的四種微服務框架即Dubbo、Motan、gRPC[16]和 Spring Cloud[17-18]展開詳細分析及比較。

3.1 微服務框架基本介紹

隨著微服務體系結構的不斷發展及成熟，微服務框架已逐漸成為一些中大型企業從傳統架構轉型到微服務架構的最佳化實踐。在本文重點介紹的四種主流微服務框架中，根據服務調用方式以及功能特色可將它們分為RPC（Remote Procedure Call）型微服務框架和RESTful微服務框架兩種[19-21]，這些框架的基本特征如表2所示。

其中，Dubbo、Motan和gRPC屬于RPC型微服務框架，這類框架可以像調用本地服務一樣調用遠程服務，從而實現高效可靠的網絡透明傳輸。Dubbo和Motan屬服務治理型RPC框架，主要提供豐富的服務治理功能。與Dubbo相比，Motan去除了Dubbo中一些不常用的組件和配置，功能雖不如Dubbo強大，但比較簡單、易用。Dubbo自2017年重新維護后又增加了對Node.js、Python等語言的支持并與當當網維護的Dubbox進行了合并[11]，增加了對RESTful的遠程調用，并且在序列化方式等方面也進行了擴展。gRPC則可提供對Java、Objective-C、C++、PHP等多種語言接口的支持，但未實現較為全面的服務治理功能。Spring Cloud來源于Spring Boot框架[17]，本質上是一種RESTful的微服務框架，設計時從資源的角度對系統進行拆分并為每個資源設置特定的URI。與另外三種RPC框架相比，Spring Cloud提供了搭建微服務體系結構幾乎所需的全套功能，而在Dubbo中實際上只實現了Spring Cloud中服務治理的部分。Spring Cloud因其功能全面、部署方便且操作簡單，是業界目前使用最廣泛的微服務框架。

3.2 微服務框架關鍵技術及核心部件

微服務作為一種分布式系統的解決方案，為構建復雜的分布式微服務應用需提供服務注冊與發現、服務間通信和服務部署等關鍵技術。同時，與傳統面向服務體系結構的實施方案相比，微服務體系結構的伸縮性較好，更能滿足大型應用的需求。因此，除需具備傳統實施方案中基本的如服務注冊與發現，服務組合等功能外，微服務體系結構還需某些擴充模塊，并對已有模塊進行擴展或優化。這些擴充模塊主要包括負載均衡、API網關和容錯機制等。

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

微服務提倡輕量級的服務架構理念，單個微服務一般部署在輕量級容器如Docker中。在運行時，服務實例可能隨時被克隆、銷毀或重定位，故需要一種動態的服務發現機制。通常，在實現服務發現時，服務提供者需先將服務實例的地址信息注冊到注冊中心，注冊中心則負責管理服務實例地址并提供心跳檢查等機制，而服務發現組件作為服務調用方，通過注冊中心實現服務查詢并獲得可用的服務實例地址列表。實際上，服務發現組件部署位置并不是固定的，一般可分為客戶端發現和服務端發現兩種[10]。

表1 Web服務體系與微服務架構的比較

表2 微服務框架基本特征比較

客戶端發現中服務發現邏輯由客戶端實現，客戶端作為服務發現組件基于上述方法確定服務實例的網絡地址。服務端發現則是把服務發現邏輯委托給了專門的路由服務。當客戶端有服務請求時需將請求發送給路由服務，再由路由服務與注冊中心交互，以發現滿足請求的服務。與客戶端發現相反，此方式并不需客戶端設計服務發現邏輯，但需要額外的路由服務作為中間件，存在一定的性能損耗。

在微服務體系結構中，要實現服務發現，服務注冊中心尤為重要。注冊中心主要負責管理服務提供者和消費者的URL地址及路由信息等，并實現服務注冊、發布、健康檢查和故障排除等功能。如表3，對目前較為通用的服務注冊中心進行了歸納和比較。

其中，Zookeeper是分布式系統使用較典型的注冊中心，它提供統一命名、集群管理、狀態同步、分布式應用配置管理等功能，并能很好地解決分布式系統數據一致性問題，較適合于大型分布式系統應用[22]。Etcd一般僅存儲一些鍵值對數據，故適用于少量數據的情形。Consul是Google公司開發及維護的注冊中心，與Zookeeper、Etcd相比，它的功能更為全面，如內置了服務發現功能，在實現時也不需依賴其他插件，更容易部署。Redis屬于key-value存儲服務器，主要以事件的發布、訂閱實現服務發現，而Multicast主要采用廣播的形式發布、訂閱消息，但這種組播的方式受網絡結構因素影響較大，比較適合小型應用使用。Netflix Eureka屬于RESTful的微服務注冊與發現組件[23]。與Zookeeper、Redis等注冊中心相比，Eureka在實現服務發現時優先保證服務可用性并且屬于輕量級組件，易于部署、維護。

3.2.2 負載均衡

在微服務體系結構中，為了提高伸縮性，單元微服務通常具有多個進程級服務實例，服務實例的個數隨著服務請求的數量而動態變化。當服務請求數量增多時，相應的服務實例個數有可能隨之增加。相反地，服務實例也可因服務請求數量的減少而被銷毀。因此，需要通過某種負載均衡算法，將服務請求分發至特定的服務實例進行處理。

最簡單的負載均衡算法來自著名的Round Robin算法，即輪詢法[24]。其思想是將多個可用服務實例組織成一個循環隊列，然后根據實例順序輪流分派服務請求。該方法一般僅適用于服務實例處理能力相差不大的情形，然而要應對多個在性能、負載能力方面差異較大的服務實例時，可采用加權輪詢法[25]。該算法在簡單輪詢的基礎上，根據服務實例的性能及負載能力為其設置不同的權重，隨后將請求按順序及權重分配到合適的服務實例上。實際上，上述輪詢算法并未真正考慮服務實例的實際請求連接數（會話數）及當前負載，較好的方法是采用最小連接數算法（Least Connections scheduling，LC）[26]。該算法可根據服務實例當前的連接數，動態的選取連接數最小的服務實例處理服務請求，以提升服務實例的利用率及請求負載能力。此外，負載均衡算法還包括按請求隨機分配的簡單隨機算法、按key值分配的哈希算法等[27]。

在MSA中，負載均衡通常與服務發現組件部署在一起。在實現時，負載均衡作為服務消費方，維護服務發現獲得的服務地址列表并基于負載均衡算法實現服務請求的具體調用。通常，根據負載均衡分布的位置，可將其分為服務端負載、客戶端負載及獨立進程負載三種。

服務端負載將服務負載交由一個獨立的負載均衡器處理（如圖1（a））。目前，較典型的負載均衡器有LVS、Nginx、HAProxy和F5等，這些負載均衡器位于客戶端與服務端之間，并作為一個獨立的服務，主要維護服務端服務實例地址列表，此時的地址列表是運維人員預先為服務配置指向負載均衡器的DNS實現。該方案實現較簡單，但負載均衡器作為中間件很容易造成單點瓶頸問題并存在一定性能損耗。

客戶端負載（如圖1（b））主要針對服務端負載的不足改進，將負載均衡功能集成到了服務消費方進程內，負載能力轉由客戶端提供。與服務端負載不同的是，此時所有客戶端維護的服務實例列表均來源于注冊中心。該方案解決了服務端負載單點瓶頸的問題，但也帶來了基于不同技術棧的客戶端實現負載均衡開發難度較大等問題。

表3 服務注冊中心比較

獨立進程負載是將客戶端與負載均衡作為兩個獨立進程運行在同一個主機中（如圖1（c））。當有客戶端請求時直接發送至負載均衡獨立進程，再由負載均衡獨立進程采用類似客戶端負載的方法實現服務請求調用。此方案綜合了服務端及客戶端負載的優缺點，但存在部署較復雜、不易維護等問題。

圖1 微服務框架負載均衡模式

3.2.3 服務網關

在MSA中，服務網關主要位于網絡的邊緣并作為外部服務請求的統一入口，主要提供身份認證與安全檢查、請求路由管理、服務組合、請求分派與維護、壓力檢測、負載均衡等功能，其基本結構如圖2所示。通常，當有用戶發來服務請求時，網關需先對服務請求進行權限驗證、API監控、流量控制等過濾操作，隨后由智能路由實現服務請求的具體轉發及調用等。實際上，服務網關可作為服務發現和負載均衡組件，對于服務發現模式中客戶端和服務端發現也都可由它實現[10]。其中，對于客戶端發現，服務網關主要為客戶端提供對服務注冊中心的訪問，此時網關只是充當一個訪問代理，對于服務端發現，服務網關則簡單地充當一個路由器。

圖2 服務網關基本結構

隨著微服務相關技術的日趨成熟，服務網關作為微服務體系結構中比較重要的組件，目前已存在多種技術選型。例如，Netflix Zuul[28]是目前使用較典型的服務網關組件，它由Netflix開發，主要作為協調客戶端與微服務的中間層并提供權限驗證、壓力檢測、負載分配、動態路由等較為全面的服務網關功能。實際上，Zuul主要負責處理RESTful的服務請求及調用，然而在不同微服務業務場景下，仍存在外部客戶端是RESTful的接口請求，而內部服務之間卻是RPC通訊的情況。顯然，為同一系統實現兩套不同類型的API接口太過繁瑣，gRPC Gateway則解決了這一問題[29]。gRPC Gateway為gRPC框架的服務網關插件，它可讀取gRPC服務請求并為其生成反向代理服務器，最終實現將RESTful的HTTP/JSON API轉化為內部gRPC的形式，從而解決了服務內外接口不兼容的問題。

3.2.4 服務容錯

在微服務體系結構中，通常存在多種服務間調用及依賴關系。微服務實例之間的動態調用鏈可能會因某個服務實例響應超時、發生錯誤或負載過高等原因導致多個相關聯的微服務不可用，因此需要容錯機制。

目前，常見的微服務框架均提供了服務容錯方案。其中，最基本的是處理服務超時，如超時重試機制[8]。它主要對服務請求設置超時響應時間，并根據設置的服務請求時間和記錄的服務請求次數，決定是否進行重試操作。若服務因負載過高發生故障時，可采用限流和熔斷器兩種策略。其中，限流主要對服務進行限流處理，可分為控制服務請求并行數量和限制訪問速率兩種。熔斷器則會記錄、監測服務執行情況，當某個實例不可用時，可立即更換至新的服務實例，也可通過計算失敗率，當其達到某個閾值時拒絕接收服務請求并將其直接返回[10]。若服務發生錯誤不可用時，可采用回退機制，主要有快速失敗、故障沉默和自定義處理三種策略[30]。同時，為保證服務發生錯誤不會影響到其他服務資源可采用故障隔離機制如壁倉隔離模式，它可為不同的服務分配不同的進程池，實現服務間的隔離[8]。企業在實踐微服務框架時，也可根據自身需求自定義容錯方案。

3.2.5 服務部署與通信

微服務框架除具備上述核心部件，還應重點考慮服務部署及服務間通信的問題。與Web服務相比，單個微服務實例的部署更為靈活方便，通常在微服務框架中服務部署方式一般有三種：其一，多服務實例部署于單個虛擬機或物理機中。這種方式下實例間資源共享，資源利用率高，但彼此之間隔離性較差。其二，單服務實例運行于單獨虛擬機中，服務實例間實現徹底隔離，系統伸縮性較好，但也容易導致資源浪費及實例維護效率降低等問題。其三，單個微服務實例運行于單個輕量級容器如Docker中，服務實例可被靈活部署并保持彼此間較好隔離，且可降低部署難度并提高效率。

鑒于微服務采用分布式系統結構，各個微服務基于上述服務部署方式被部署在不同的節點上，而服務間的通信則是通過網絡傳輸，因此微服務框架在實現時應保證良好的通信機制，從而實現準確、高效的信息交換。通常，在微服務框架中服務間交互有同步請求響應以及異步通信兩種模式。在同步請求響應模式下，客戶端發出通信請求并等待回應，一般采用REST和Thrift兩種協議。這種通信模式沒有中間件作代理，通用性較好，實現較簡單，但其通信機制較為單一，只支持請求/響應模式，在一定程度上降低了系統可用性。異步通信模式則不需等待請求響應，其通信模式一般基于消息隊列，通過消息中間件緩存消息，可實現客戶端與服務端的松耦合。該模式可采用如AMQP、KAFKA等多種協議[8]，并支持請求/異步響應、發布/訂閱和發布/異步響應等多種通信機制，有效地提高了系統的可用性。異步通信模式更適合較復雜的微服務應用場景并可實現較為可靠的消息傳遞，但其引入了消息隊列中間件，在一定程度上加重了消息系統開發、部署和運維的復雜性。通常，在主流微服務框架中，會混用這兩種通信模式以提高系統可伸縮性。

3.3 微服務框架關鍵技術及核心部件比較

在主流微服務框架中，Dubbo、Motan和gRPC都支持多種注冊中心，同時基于不同的負載均衡軟件可實現如隨機、輪詢、一致性哈希等多種負載均衡算法[31]（具體如表4）。Spring Cloud則集成了一系列用于構建分布式系統所需的開發工具包，其中負載均衡軟件采用的是Netflix Ribbon[32]，與Nginx這類負載均衡軟件相比，Ribbon更關注于服務實例的請求并發處理能力，而不只是簡單的請求轉發。例如Ribbon支持的BestAvailable-Rule算法，可動態的感知服務實例的負載情況，并選擇當前最小并發請求數的服務實例分發請求。對于容錯方面，Spring Cloud集成了Netflix Hystrix作為容錯組件[33]。它綜合考慮了服務超時、負載、錯誤及服務隔離等多種情形，主要提供線程隔離、服務降級和熔斷器等多種容錯技術。Hystrix也可被其他組件集成使用，例如Netflix Zuul實際上集成了Hystrix用于網關層的內部容錯處理。Dubbo、Motan和gRPC則更關注于服務超時、錯誤的情形，提供內置集群容錯方案。另外，在服務網關方面，Spring Cloud和gRPC自身就可提供網關組件，而服務治理型框架中Dubbo和Motan主要側重于服務內部接口之間的RPC調用，本身并不提供服務網關功能，實際使用時可結合開源的服務關組件如Netflix Zuul、Kong[34]作為補充。

4 微服務框架中的服務組合方案

在微服務體系結構中，基于單一職責原則，將傳統的單體應用進行有效的拆分，以最終實現敏捷開發及部署。目前，主流微服務框架中所提供的服務注冊與發現、服務容錯和服務通信等核心技術為實現敏捷性開發和部署提供了相應的技術支撐，然而在應對多樣性的外部服務請求時還需重點考慮微服務組合技術，即如何將多個功能明確、單一的微服務通過某種機制，聚合成滿足應用需求、功能更為完整的整體應用以提供服務。

在微服務組合方面，一種直觀的做法就是借鑒Web服務組合的思路和策略。在Web服務組合中，通常采用Choreography（編排）或Orchestration（編制）兩種服務聚合策略，并分別采用CDL（Choreography Description Language）語言、BPEL（Business Process Execution Lan-guage）語言來描述服務之間的交互、協作或通信過程。盡管服務編排、編制語言在Web服務組合中獲得成功，但難以直接被應用至微服務組合中。事實上，上述兩種語言屬于底層基于句法的描述語言，隨著交互服務數量的增加將導致組合服務代碼復雜性的增大。另一方面，它們要求單元服務有定義良好的接口以及交互信息的強類型約束。但是，快速變化的微服務使得難以快速定義其接口并且難以被快速部署。同時，前述兩種語言需要有中心執行引擎如ESB等，難以被用于微服務體系結構中[35]。

表4 主流微服務框架中關鍵技術及核心部件比較

在實現微服務組合時有幾個方面需重點考慮：首先，微服務提倡輕量級的服務架構理念，在實現服務組合時應避免引入企業服務總線這類重量型執行引擎，同時在設計服務組合方法時應使其能適用于輕量級的微服務部署及執行。其次，微服務促進了服務的動態性，在運行時服務實例的地址等信息都是動態變化的，因此服務組合方法應能動態綁定服務地址等信息，并能應對服務因響應超時、發生錯誤等意外情況導致不可用的情況。再者，微服務是無狀態的，服務本身并不存儲特定信息，而服務間的通訊也僅通過語言無關的API進行，因此如何根據服務請求匹配到一組滿足需求的服務組合，是需重點考慮的一個方面。當前，學術界、工程界在微服務組合方面進行了探索研究，在主流微服務框架中也提供了實現服務組合的具體解決方案[35-39]。例如，Spring Cloud通過輕量級的事件驅動機制來實現服務組合，在實施時利用一個事件處理中介如RabbitMQ或Apache Kafka來協調組合服務調用[17]。當有外部服務請求時將直接發送服務調用事件至事件處理中介，事件中介將自動完成服務的具體調用并返回一個包含執行結果的服務執行事件到事件處理引擎，再由事件處理引擎根據服務業務規則觸發滿足服務請求的后續服務的調用。另外，文獻[35]也提出了一種基于事件驅動的輕量級服務組合平臺Medley，但這個輕量級平臺在實現服務組合時重點側重于對組合服務的描述。該平臺為微服務組合設計了一種專門的服務組合描述語言，并通過編譯器為組合描述生成可執行代碼，最終部署運行在Medley平臺上，從而實現對大量的現有服務進行組合。除此之外，Netflix公司為實現服務組合專門設計了一個可用于生產環境的開源框架即Netflix Conductor[36]。它通過將系統所需的微服務和系統服務結合起來，一起定義在一個工作流中，從而形成一個完整的實現某種特定功能的服務組合藍圖。通過事件觸發工作流，實現預定義服務的具體調用。類似的，文獻[37]也提出了一種基于工作流的微服務描述和驗證的形式化框架，并指定了一種基于Petri網的微服務的形式化語義。本質上講，這種方法實際上也是一種工作流形式的微服務組合方法，但其主要完成微服務組合方案的可行性驗證，更偏重于對微服務組合的形式化建模。

5 結束語

目前，國內外對微服務體系結構及實現機制的研究異?；钴S。本文首先論述了微服務體系結構的產生背景、相關概念，并指出傳統單體架構的不足及微服務體系結構的發展背景及優勢。其次，對微服務架構實踐關注的服務注冊與發現、服務通信、服務部署等關鍵策略進行了分析，重點就主流微服務實施框架及其核心部件展開詳細分析和對比，可為基于微服務體系結構的企業級應用開發提供實施框架的選擇、幫助與指導。最后，探討了微服務組合相關問題。隨著持續發布及部署需求的增加及輕量級容器如Docker的推廣，微服務體系結構將更為廣泛地被應用于分布式系統的設計及實施。微服務組合作為微服務體系結構中較為重要的一個方面，目前的研究卻基本集中于通過預定義服務組合工作流模型以實現服務組合的方式。因此，下一步將重點考慮高效的在線動態微服務組合機制的研究。