基于API網(wǎng)關(guān)的微服務(wù)組合策略研究

吳潤 武漢大學(xué)計(jì)算機(jī)學(xué)院

1 引言

隨著企業(yè)級應(yīng)用程序規(guī)模的不斷擴(kuò)張，應(yīng)用的更新、部署以及維護(hù)工作變得越來越繁重，以單體架構(gòu)方式構(gòu)建的應(yīng)用越來越難以為繼，而微服務(wù)架構(gòu)的出現(xiàn)為大型應(yīng)用程序開辟了另一條通道，而云計(jì)算、容器虛擬化、基礎(chǔ)設(shè)施自動(dòng)化等技術(shù)的不斷涌現(xiàn)，更是為微服務(wù)架構(gòu)的發(fā)展提供了良好的基礎(chǔ)。微服務(wù)架構(gòu)通過對應(yīng)用進(jìn)行分析，將原本單體應(yīng)用中龐大冗雜的功能模塊分解成體量小，功能明確并且耦合度低的多個(gè)微服務(wù)，這些微服務(wù)相互協(xié)同完成工作。

微服務(wù)通常具備以下特點(diǎn)：

單一職責(zé)。在面向?qū)ο蟪绦蛟O(shè)計(jì)中，我們提倡高內(nèi)聚、低耦合，同理，每個(gè)微服務(wù)在服務(wù)架構(gòu)層面都遵循單一職責(zé)原則，每個(gè)單獨(dú)的微服務(wù)都負(fù)責(zé)特定的業(yè)務(wù)邏輯。

相互獨(dú)立。在傳統(tǒng)的單體架構(gòu)應(yīng)用中，所有的功能模塊代碼都糅合在一起，修改某個(gè)功能模塊很可能會(huì)影響到另一個(gè)功能模塊，在修改過后，還需要進(jìn)行重新集成，通過測試還要進(jìn)行統(tǒng)一打包，再部署到相應(yīng)的服務(wù)器環(huán)境中。因此，在單體應(yīng)用中，功能模塊的開發(fā)、測試和部署過程都會(huì)互相產(chǎn)生影響，而微服務(wù)架構(gòu)中，每個(gè)微服務(wù)都是獨(dú)立的業(yè)務(wù)單元，有著獨(dú)立的代碼庫，并且可以單獨(dú)測試和部署。

輕量級的通信方式。微服務(wù)之間通常通過輕量級的通信機(jī)制進(jìn)行通信，這些輕量級的通信方式通常是與語言和平臺完全無關(guān)的。也正因?yàn)槿绱耍煌奈⒎?wù)甚至可以使用不同的語言進(jìn)行開發(fā)，增加了靈活性。

在微服務(wù)架構(gòu)中，微服務(wù)都是一些功能單一、相互獨(dú)立的功能單元，其功能有限，如果需要實(shí)現(xiàn)某種復(fù)雜功能，則需要對已有的微服務(wù)進(jìn)行適當(dāng)組合，相互協(xié)作以實(shí)現(xiàn)各種多樣化的功能需求。因此，可以將不同功能，易于執(zhí)行且簡單的微服務(wù)通過某種組合策略集成在一起實(shí)現(xiàn)強(qiáng)大的功能。

2 微服務(wù)組合相關(guān)概念

2.1 web服務(wù)組合

提到微服務(wù)架構(gòu)，就不得不提到面向服務(wù)架構(gòu)（SOA），兩者在某些方面有著不少相似之處，在SOA中，服務(wù)也是通過某種組合方式來相互協(xié)同完成某個(gè)具體功能。在web服務(wù)組合策略中，通常分為兩種方式，一種稱為編排方式（choreography），編排方式可以看做是一種消息驅(qū)動(dòng)方式，實(shí)現(xiàn)方案大多是異步的，監(jiān)聽業(yè)務(wù)事件的web服務(wù)會(huì)主動(dòng)獲取消息，進(jìn)行處理，然后發(fā)布自己的消息；另一種方式稱為編制方式（ochestration），編制方式的實(shí)現(xiàn)方案大多是同步的，這種設(shè)計(jì)方式中往往有一個(gè)流程控制服務(wù)，該服務(wù)接收請求，并按照業(yè)務(wù)邏輯調(diào)用各個(gè)web服務(wù)，最后完成任務(wù)。以上兩種服務(wù)組合方式都有對應(yīng)的標(biāo)準(zhǔn)支持，分別是BPEL4WS（Business Process Execution Language for Web Services）和WS-CDL (Web Service Choreography Definition Language)，BPEL4WS 適 合用于服務(wù)編制，此標(biāo)準(zhǔn)主要用于組織內(nèi)部的業(yè)務(wù)流程管理，而且很多BPM產(chǎn)品基于此規(guī)范實(shí)現(xiàn)，WS-CDL是專門的web服務(wù)編排標(biāo)準(zhǔn)。

2.2 微服務(wù)組合

與web服務(wù)組合相類似，微服務(wù)組合采用某種適當(dāng)?shù)夭呗詫⑷舾蓚€(gè)相互獨(dú)立，功能單一的微服務(wù)組合成一個(gè)功能更強(qiáng)大的服務(wù)，為某個(gè)具體的業(yè)務(wù)功能提供支持。不同之處在于微服務(wù)相較于web服務(wù)而言，粒度更小，功能更加獨(dú)立，而不是面向業(yè)務(wù)，因此，相比較而言，微服務(wù)組合問題面臨著更大的挑戰(zhàn)。

2.3 微服務(wù)組合需要解決的問題

在微服務(wù)架構(gòu)中，由于微服務(wù)是較小粒度的獨(dú)立功能單元，因此，通常一個(gè)具體的業(yè)務(wù)功能需要調(diào)用多個(gè)微服務(wù)，這就涉及到服務(wù)的映射和路由問題；其次，安全防護(hù)也是一個(gè)必要的考量，對來訪的用戶應(yīng)該進(jìn)行必要的身份認(rèn)證，只有得到授權(quán)的用戶才有訪問權(quán)限；另外，可用性是保證服務(wù)穩(wěn)定性的重要指標(biāo)，在調(diào)用微服務(wù)的過程中，不可避免地會(huì)出現(xiàn)服務(wù)無響應(yīng)或服務(wù)繁忙等情況，對于這些服務(wù)不可用的情況必須提供超時(shí)或熔斷處理；最后，系統(tǒng)也可能面臨短時(shí)間內(nèi)訪問量劇增的情況，考慮到系統(tǒng)有限的負(fù)載能力，通過采用適當(dāng)?shù)牟呗詼p輕服務(wù)的壓力也是需要考慮的問題。

3 微服務(wù)組合研究現(xiàn)狀

伴隨著微服務(wù)架構(gòu)的出現(xiàn)，對于微服務(wù)組合策略的研究也隨之出現(xiàn)，工業(yè)界和學(xué)術(shù)界也都紛紛提出了不同的解決方案，大體上分為兩種，一種借鑒web服務(wù)組合的編排策略對微服務(wù)進(jìn)行某種形式編排以實(shí)現(xiàn)微服務(wù)組合，另一種則是通過使用API網(wǎng)關(guān)來實(shí)現(xiàn)微服務(wù)組合。

Netflix Conductor是一個(gè)典型的借鑒web服務(wù)組合策略的微服務(wù)組合工具。Conductor支持創(chuàng)建復(fù)雜的業(yè)務(wù)流，這些業(yè)務(wù)流通過基于JSON DSL制定的藍(lán)圖來定義其整個(gè)執(zhí)行流程，這些流程藍(lán)圖反過來也為整個(gè)業(yè)務(wù)流提供了可見性和可追溯性。另外，在業(yè)務(wù)流程的執(zhí)行過程中，Conductor也支持暫停、恢復(fù)、重啟等多個(gè)控制語義，使其在運(yùn)行時(shí)可以靈活應(yīng)對各種突發(fā)情況。在性能上，Conductor能夠在必要時(shí)同步處理所有任務(wù)，并允許擴(kuò)展數(shù)百萬個(gè)并發(fā)處理的業(yè)務(wù)流程?？梢哉f，Conductor作為Netflix內(nèi)部使用多年的微服務(wù)編排工具，其在多個(gè)方面都有優(yōu)秀的表現(xiàn)。

圖1 Netflix Conductor運(yùn)行時(shí)模型

文獻(xiàn)[5]提出了一個(gè)輕量級微服務(wù)組合平臺Medley。Medley首先為微服務(wù)組合定義一套服務(wù)組合規(guī)范，通過這些規(guī)范來約束微服務(wù)組合，然后通過編譯器將這些規(guī)范語義編譯成描述微服務(wù)組合的代碼，最后將這些代碼部署在服務(wù)器的Docker容器中執(zhí)行，從而實(shí)現(xiàn)整個(gè)服務(wù)組合流程。

基于API網(wǎng)關(guān)實(shí)現(xiàn)微服務(wù)組合也是目前微服務(wù)領(lǐng)域較為常用的策略。API網(wǎng)關(guān)往往作為一個(gè)系統(tǒng)的入口，是連接所有客戶端和服務(wù)端的關(guān)鍵節(jié)點(diǎn)，通過一個(gè)統(tǒng)一的API網(wǎng)關(guān)，客戶端和服務(wù)端能夠非常方便地進(jìn)行交互而無需了解其底層微服務(wù)細(xì)節(jié)。API網(wǎng)關(guān)對系統(tǒng)內(nèi)部的細(xì)節(jié)進(jìn)行了封裝，將所有非業(yè)務(wù)功能放在網(wǎng)關(guān)層進(jìn)行處理，使其內(nèi)部組織結(jié)構(gòu)對API調(diào)用者透明，且對于每個(gè)調(diào)用者都提供對應(yīng)的定制API。除此以外，API網(wǎng)關(guān)在微服務(wù)架構(gòu)中還可兼具負(fù)載均衡、身份驗(yàn)證、限流等多個(gè)功能職責(zé)。

4 基于API網(wǎng)關(guān)的微服務(wù)組合

4.1 API網(wǎng)關(guān)的誕生背景和意義

相對于誕生不久的微服務(wù)架構(gòu)而言，其實(shí)API網(wǎng)關(guān)在很多領(lǐng)域并不算是一個(gè)新名詞，早在微服務(wù)被提出并在業(yè)界流行起來之前，API網(wǎng)關(guān)就已經(jīng)在金融證券領(lǐng)域的前置機(jī)系統(tǒng)上得到應(yīng)用。API網(wǎng)關(guān)的作用在于其將客戶端和服務(wù)端有效地進(jìn)行了分離，通過網(wǎng)關(guān)將后端的微服務(wù)進(jìn)行組合并映射到對應(yīng)的API，降低了客戶端和服務(wù)端之間的耦合性，在面對業(yè)務(wù)變化時(shí)也能更方便地進(jìn)行功能擴(kuò)展與變更，節(jié)省了開發(fā)成本，通過API網(wǎng)關(guān)的功能聚合作用，可以有效提高系統(tǒng)訪問效率。

隨著移動(dòng)互聯(lián)網(wǎng)時(shí)代的到來，傳統(tǒng)的系統(tǒng)后臺需要支持的客戶端對象從單一的PC端逐漸轉(zhuǎn)移到手機(jī)，平板等移動(dòng)端，服務(wù)場景的增多一方面對后臺的吞吐量提出了更高的要求，另一方面也無形中增大了后臺服務(wù)的復(fù)雜性，畢竟不同的客戶端由于使用場景的不同對后臺的響應(yīng)需求也各不相同，而借助于API網(wǎng)關(guān)的強(qiáng)大功能，以上問題可以得到有效解決。尤其在微服務(wù)架構(gòu)中，我們構(gòu)建的微服務(wù)可能會(huì)面臨服務(wù)端口更改和服務(wù)實(shí)例的變更問題，不同的微服務(wù)可能采用了不同的數(shù)據(jù)協(xié)議，對于客戶端而言，其直接調(diào)用的往往是粗粒度的API，而微服務(wù)往往是細(xì)粒度的API，如果客戶端直接調(diào)用細(xì)粒度的微服務(wù)，會(huì)大大增加API調(diào)用的復(fù)雜性和系統(tǒng)耦合性，而這些問題也都在API網(wǎng)關(guān)的解決范疇之內(nèi)。因此，隨著微服務(wù)架構(gòu)的日益成熟完善，在很多微服務(wù)架構(gòu)體系中，API網(wǎng)關(guān)都成為了不可或缺的一個(gè)關(guān)鍵組件。

4.2 API網(wǎng)關(guān)的解決方案

隨著微服務(wù)架構(gòu)的發(fā)展成熟，業(yè)界也相繼出現(xiàn)了很多成熟的API網(wǎng)關(guān)解決方案，常見的有Tyk、Orange、Kong、Netflix Zuul、apiaxle、Api-umbrella、Amazon API Gateway 等等。

Tyk是一個(gè)輕量級的開源API網(wǎng)關(guān)，基于Go語言開發(fā)[6]。在安全認(rèn)證方面，Tyk支持多種認(rèn)證方式，包括基本身份認(rèn)證、令牌認(rèn)證、HMAC簽名認(rèn)證、Json Web令牌認(rèn)證，也支持以上多個(gè)認(rèn)證方式組合使用。在API的訪問控制方面，Tyk內(nèi)置了流量限制機(jī)制，包括速率限制、請求配額和請求大小限制。Tyk提供了兩種速率限制器，即硬同步速率限制器和分布式速率限制器來實(shí)現(xiàn)速率限制。配額類似于速率限制，它允許在一定時(shí)間內(nèi)通過一定數(shù)量的請求。Tyk支持在全局和各端點(diǎn)設(shè)置最大請求長度，以拒絕任何超過設(shè)定長度的請求。

Orange是一款基于OpenResty的API網(wǎng)關(guān)，除了具備Nginx的基本功能外，它還具備API重定向和鑒權(quán)、流量切分、訪問限速、訪問統(tǒng)計(jì)以及web防火墻等多種功能，是一個(gè)功能齊全的網(wǎng)關(guān)系統(tǒng)。Orange的特性之一是其內(nèi)置了多個(gè)通用插件，如全局狀態(tài)統(tǒng)計(jì)、URL重寫、URL重定向、自定義監(jiān)控、訪問限速、鑒權(quán)、WAF防火墻等。

Kong是Mashape提供的一款開源API網(wǎng)關(guān)，起初用于維護(hù)、管理和擴(kuò)展其Marketplace中的API和微服務(wù)[8]。Kong是基于Nginx實(shí)現(xiàn)的，或者準(zhǔn)確的說，Kong是一個(gè)運(yùn)行在Nginx中的Lua應(yīng)用程序，它比Nginx提供了更加簡單的配置方式。Kong主要包含兩個(gè)重要組件，即Kong Server和Apache Cassandra，前者用來接收API請求，后者用來存儲操作數(shù)據(jù)，可以通過增加Kong Server的數(shù)量來對Kong服務(wù)進(jìn)行水平擴(kuò)展，并通過負(fù)載均衡器轉(zhuǎn)發(fā)請求以應(yīng)對訪問壓力。Kong的優(yōu)秀之處在于其提供了大量的插件來擴(kuò)展應(yīng)用，為可插拔架構(gòu)奠定了基礎(chǔ)，Orange的很多設(shè)計(jì)也正是借鑒于此。

Zuul是由Netflix開源的網(wǎng)關(guān)產(chǎn)品，其在Spring Cloud Netflix項(xiàng)目中的主要作用相當(dāng)于路由器和服務(wù)器端負(fù)載均衡器[9]。通過Zuul的過濾器，Netflix可以實(shí)現(xiàn)認(rèn)證、測試、動(dòng)態(tài)路由、服務(wù)遷移、安全、流量管理等操作。Zuul的規(guī)則引擎支持任何以JVM語言編寫規(guī)則和過濾器，如Java和Groovy。

Apiaxle是基于Nodejs實(shí)現(xiàn)的開源API管理平臺，是一個(gè)免費(fèi)的本地托管的API管理解決方案[10]。APiaxle系統(tǒng)主要包含三個(gè)組件，即Apiaxle-proxy、Apiaxle-api和Apiaxlerepl，其中，Apiaxle-proxy是系統(tǒng)執(zhí)行代理的組件，負(fù)責(zé)身份驗(yàn)證、，密鑰檢查等工作，Apiaxle-api負(fù)責(zé)負(fù)責(zé)管理用戶、密鑰等，Apiaxle-repl則提供了一個(gè)以命令行的方式來管理Apiaxle的途徑。

通過以上對API網(wǎng)關(guān)的簡要介紹與分析，不難看出不同的API網(wǎng)關(guān)之間還是存在明顯的差異。首先，API網(wǎng)關(guān)可能基于不同的技術(shù)基礎(chǔ)來實(shí)現(xiàn)，如Kong和Orange基于Openresty實(shí)現(xiàn)的，Openresty本身則基于Nginx和Lua實(shí)現(xiàn)，而其他大多數(shù)API網(wǎng)關(guān)基本是原生開發(fā)的。其次，不同的API網(wǎng)關(guān)可能由不同的編程語言開發(fā)，如Tyk基于Go語言開發(fā)，Apiaxle基于Nodejs開發(fā)，Api-umbrella基于Ruby開發(fā)等等。另外，不同的API網(wǎng)關(guān)的性能和穩(wěn)定性可能也不一樣，比如Zuul有著易適用，配置簡單等優(yōu)點(diǎn)，同時(shí)其本身還存在重定向、異常處理等亟待解決的問題，而本身基于Nginx開發(fā)的Kong和Orange等則依托于Nginx的成熟穩(wěn)定，其性能和穩(wěn)定性可以得到有效保障。

盡管不同的API網(wǎng)關(guān)之間差異明顯，但總體而言，API網(wǎng)關(guān)作為微服務(wù)架構(gòu)中的重要一環(huán)，在連接系統(tǒng)客戶端與服務(wù)端并聚合微服務(wù)方面有著重要作用，為微服務(wù)調(diào)用中的安全性、準(zhǔn)確性和穩(wěn)定性提供了重要保障，為微服務(wù)組合問題提供了一個(gè)可行的解決方案。

4.3 使用API網(wǎng)關(guān)來實(shí)現(xiàn)微服務(wù)組合

在微服務(wù)架構(gòu)系統(tǒng)中，API網(wǎng)關(guān)通常作為整個(gè)系統(tǒng)的唯一入口節(jié)點(diǎn)，其封裝了系統(tǒng)內(nèi)部結(jié)構(gòu)，對外為各個(gè)客戶端提供定制API。API網(wǎng)關(guān)負(fù)責(zé)服務(wù)請求路由、服務(wù)組合以及服務(wù)協(xié)議轉(zhuǎn)換，來自客戶端的所有請求首先到達(dá)API網(wǎng)關(guān)，然后API網(wǎng)關(guān)根據(jù)請求路由到對應(yīng)的微服務(wù)，這些最終被調(diào)用到的微服務(wù)通常會(huì)有多個(gè)，API網(wǎng)關(guān)負(fù)責(zé)將它們的返回結(jié)果進(jìn)行合并最終返回給客戶端。此外，一個(gè)功能完整的API網(wǎng)關(guān)往往還負(fù)責(zé)用戶身份認(rèn)證及授權(quán)、超時(shí)處理、服務(wù)限流控制、熔斷保護(hù)、負(fù)載均衡和日志記錄等功能?？梢哉f， API網(wǎng)關(guān)完全可以應(yīng)對各種微服務(wù)組合問題。

4.3.1 服務(wù)路由

API網(wǎng)關(guān)授權(quán)給客戶端調(diào)用某個(gè)API，通常會(huì)預(yù)先在配置文件中配置服務(wù)路由。當(dāng)客戶端訪問請求到達(dá)API網(wǎng)關(guān)時(shí)，根據(jù)已配置的路由規(guī)則，API網(wǎng)關(guān)將訪問接口映射到系統(tǒng)內(nèi)部對應(yīng)的微服務(wù)訪問接口，最終調(diào)用微服務(wù)并返回結(jié)果。當(dāng)然，API網(wǎng)關(guān)也支持主動(dòng)設(shè)置攔截或忽略某些請求， 當(dāng)符合這些配置路徑的請求到達(dá)時(shí)，API網(wǎng)關(guān)攔截這些請求并拒絕提供服務(wù)。

4.3.2客戶端身份認(rèn)證及授權(quán)

API網(wǎng)關(guān)作為系統(tǒng)的統(tǒng)一入口，為保障服務(wù)被安全合法地調(diào)用，身份認(rèn)證自然是其必需的功能。API網(wǎng)關(guān)的身份認(rèn)證功能通常包括用戶客戶端合法性認(rèn)證、客戶端訪問授權(quán)驗(yàn)證等。當(dāng)用戶進(jìn)入系統(tǒng)，系統(tǒng)通過其提供的有效憑證（如用戶名和密碼）為其賦予一個(gè)身份認(rèn)證令牌，當(dāng)客戶端請求某個(gè)服務(wù)資源時(shí)，需要首先提供前面獲得的身份認(rèn)證令牌，身份認(rèn)證服務(wù)通過驗(yàn)證該令牌來確定該用戶請求是否合法有效。

4.3.3 服務(wù)超時(shí)處理

在理想情況下，微服務(wù)應(yīng)該隨調(diào)隨用，但在實(shí)際環(huán)境中，不可避免地會(huì)出現(xiàn)服務(wù)器故障或者斷電等或任何導(dǎo)致服務(wù)實(shí)例失效的情況，在這種情況下，API網(wǎng)關(guān)不可能無限制地等待某個(gè)微服務(wù)響應(yīng)，此時(shí)，服務(wù)超時(shí)處理就顯得尤為關(guān)鍵了。通常，在API網(wǎng)關(guān)中會(huì)設(shè)定一個(gè)最長允許超時(shí)時(shí)間，一旦API網(wǎng)關(guān)調(diào)用微服務(wù)等待時(shí)長超過了這個(gè)設(shè)定值便會(huì)立刻停止調(diào)用，防止無意義的等待。

4.3.4 服務(wù)熔斷保護(hù)處理

熔斷處理在一定程度上保證了微服務(wù)調(diào)用的容錯(cuò)性，當(dāng)API網(wǎng)關(guān)調(diào)用的某個(gè)微服務(wù)出現(xiàn)異常的次數(shù)到達(dá)設(shè)定閾值時(shí)，API網(wǎng)關(guān)會(huì)啟動(dòng)熔斷保護(hù)機(jī)制，臨時(shí)切斷當(dāng)前的微服務(wù)調(diào)用，以防錯(cuò)誤進(jìn)一步擴(kuò)大，同時(shí)在合適的時(shí)機(jī)又會(huì)停止熔斷保護(hù)。常見的熔斷機(jī)制包含三種狀態(tài)，即關(guān)閉狀態(tài)、打開狀態(tài)和半開狀態(tài)，滿足相應(yīng)條件的情況下三種狀態(tài)可以相互轉(zhuǎn)化。正常情況下，熔斷器處于關(guān)閉狀態(tài)，當(dāng)微服務(wù)調(diào)用異常次數(shù)達(dá)到設(shè)定閾值則轉(zhuǎn)化為打開狀態(tài)，打開狀態(tài)經(jīng)過了熔斷保護(hù)時(shí)間則轉(zhuǎn)為半開狀態(tài)，在半開狀態(tài)下微服務(wù)調(diào)用成功則轉(zhuǎn)為關(guān)閉狀態(tài)。

圖2 熔斷器狀態(tài)轉(zhuǎn)換機(jī)制

4.3.5 負(fù)載均衡

負(fù)載均衡在現(xiàn)代大型網(wǎng)站中早已成為標(biāo)配之一，其作用是利用服務(wù)集群的優(yōu)勢提高網(wǎng)站的性能，在API網(wǎng)關(guān)中也是如此。在API網(wǎng)關(guān)中，對API接口進(jìn)行負(fù)載均衡，能充分提高其并發(fā)訪問能力，當(dāng)客戶端請求到達(dá)API網(wǎng)關(guān)，根據(jù)設(shè)定的調(diào)度策略，該請求會(huì)被分配給合適的后臺服務(wù)器進(jìn)行處理，有效的防止了服務(wù)雪崩。

4.3.6 服務(wù)限流

在微服務(wù)架構(gòu)中，我們往往會(huì)面臨系統(tǒng)負(fù)載能力有限，而實(shí)際的請求數(shù)量卻大大超出了系統(tǒng)的負(fù)載上限，為了防止短時(shí)間內(nèi)大量請求對系統(tǒng)造成過大壓力進(jìn)而導(dǎo)致系統(tǒng)崩潰，對服務(wù)進(jìn)行限流控制勢在必行。不同的限流策略可能不盡相同，最常用的方式是為微服務(wù)設(shè)定單位時(shí)間內(nèi)的最大請求數(shù)，當(dāng)這個(gè)服務(wù)的單位時(shí)間內(nèi)的調(diào)用數(shù)到達(dá)設(shè)定閾值時(shí)，API網(wǎng)關(guān)會(huì)短暫地終止對此服務(wù)的調(diào)用。

5 結(jié)束語

伴隨著微服務(wù)架構(gòu)的出現(xiàn)，微服務(wù)組合問題也稱為一個(gè)亟待解決的問題，在將粒度較小、功能單一的微服務(wù)組合為一個(gè)個(gè)具體的業(yè)務(wù)功能的過程中，所面臨的安全性、可用性以及服務(wù)映射等諸多挑戰(zhàn)。借鑒于Web服務(wù)組合所采用的編制和編排方法，誕生了若干針對微服務(wù)組合問題的解決方案，但終究無法面面俱到，而API網(wǎng)關(guān)則為微服務(wù)組合問題提供了一個(gè)較為完備的解決方法，依托于API網(wǎng)關(guān)的強(qiáng)大功能，微服務(wù)組合所面臨的問題都可以得到有效解決。隨著微服務(wù)技術(shù)的日益成熟，API網(wǎng)關(guān)的功能也愈發(fā)強(qiáng)大，相信其能夠?yàn)槲⒎?wù)組合問題提供更有力的支持。