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

寧波大學(xué) 信息科學(xué)與工程學(xué)院，浙江 寧波 315211

1 引言

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

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

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

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

2 Web服務(wù)與微服務(wù)基本概念

2.1 Web服務(wù)及基于微服務(wù)的體系結(jié)構(gòu)

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

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

與單體架構(gòu)相比，微服務(wù)架構(gòu)的優(yōu)勢在于：（1）微服務(wù)按業(yè)務(wù)功能劃分，每個服務(wù)都具備特定的功能，易于開發(fā)、維護(hù)等；（2）每個獨立的微服務(wù)可以由不同的語言基于不同的平臺開發(fā)，靈活性較好；（3）子服務(wù)可獨立部署，能夠?qū)崿F(xiàn)可持續(xù)集成及交付；（4）容錯能力強(qiáng)大，單個微服務(wù)出現(xiàn)問題不會影響系統(tǒng)其他服務(wù)的運(yùn)行；（5）可實現(xiàn)動態(tài)按需實時擴(kuò)展等。目前，微服務(wù)體系結(jié)構(gòu)的思想已被應(yīng)用于很多大型公司的分布式應(yīng)用系統(tǒng)中。

2.2 Web服務(wù)與微服務(wù)架構(gòu)的比較

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

3 微服務(wù)體系結(jié)構(gòu)實現(xiàn)框架

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

3.1 微服務(wù)框架基本介紹

隨著微服務(wù)體系結(jié)構(gòu)的不斷發(fā)展及成熟，微服務(wù)框架已逐漸成為一些中大型企業(yè)從傳統(tǒng)架構(gòu)轉(zhuǎn)型到微服務(wù)架構(gòu)的最佳化實踐。在本文重點介紹的四種主流微服務(wù)框架中，根據(jù)服務(wù)調(diào)用方式以及功能特色可將它們分為RPC（Remote Procedure Call）型微服務(wù)框架和RESTful微服務(wù)框架兩種[19-21]，這些框架的基本特征如表2所示。

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

3.2 微服務(wù)框架關(guān)鍵技術(shù)及核心部件

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

3.2.1 服務(wù)發(fā)現(xiàn)機(jī)制與注冊中心

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

表1 Web服務(wù)體系與微服務(wù)架構(gòu)的比較

表2 微服務(wù)框架基本特征比較

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

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

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

3.2.2 負(fù)載均衡

在微服務(wù)體系結(jié)構(gòu)中，為了提高伸縮性，單元微服務(wù)通常具有多個進(jìn)程級服務(wù)實例，服務(wù)實例的個數(shù)隨著服務(wù)請求的數(shù)量而動態(tài)變化。當(dāng)服務(wù)請求數(shù)量增多時，相應(yīng)的服務(wù)實例個數(shù)有可能隨之增加。相反地，服務(wù)實例也可因服務(wù)請求數(shù)量的減少而被銷毀。因此，需要通過某種負(fù)載均衡算法，將服務(wù)請求分發(fā)至特定的服務(wù)實例進(jìn)行處理。

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

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

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

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

表3 服務(wù)注冊中心比較

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

圖1 微服務(wù)框架負(fù)載均衡模式

3.2.3 服務(wù)網(wǎng)關(guān)

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

圖2 服務(wù)網(wǎng)關(guān)基本結(jié)構(gòu)

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

3.2.4 服務(wù)容錯

在微服務(wù)體系結(jié)構(gòu)中，通常存在多種服務(wù)間調(diào)用及依賴關(guān)系。微服務(wù)實例之間的動態(tài)調(diào)用鏈可能會因某個服務(wù)實例響應(yīng)超時、發(fā)生錯誤或負(fù)載過高等原因?qū)е露鄠€相關(guān)聯(lián)的微服務(wù)不可用，因此需要容錯機(jī)制。

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

3.2.5 服務(wù)部署與通信

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

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

3.3 微服務(wù)框架關(guān)鍵技術(shù)及核心部件比較

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

4 微服務(wù)框架中的服務(wù)組合方案

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

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

表4 主流微服務(wù)框架中關(guān)鍵技術(shù)及核心部件比較

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

5 結(jié)束語

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