【51CTO.com原創(chuàng)稿件】隨著互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展，各類線上業(yè)務(wù)蓬勃發(fā)展，軟件系統(tǒng)如雨后春筍般呈現(xiàn)在我們面前。

[[277173]]

圖片來自 Pexels 

為了提高系統(tǒng)的性能和可靠性，將應(yīng)用服務(wù)進(jìn)行拆分微服務(wù)化。作為系統(tǒng)入口的 API 網(wǎng)關(guān)也逐漸成為了標(biāo)配。

今天我們一起來看看 API 網(wǎng)關(guān)的設(shè)計(jì)思路，需要承載了哪些功能?以及如何選擇流行的 API 網(wǎng)關(guān)?

什么是 API 網(wǎng)關(guān)

既然需要 API 網(wǎng)關(guān)為我所用，首先就讓我們來了解一下什么是 API 網(wǎng)關(guān)。

什么是 API 網(wǎng)關(guān)

網(wǎng)關(guān)一詞最早出現(xiàn)在網(wǎng)絡(luò)設(shè)備，比如兩個(gè)相互獨(dú)立的局域網(wǎng)之間通過路由器進(jìn)行通信，中間的路由被稱之為網(wǎng)關(guān)。

任何一個(gè)應(yīng)用系統(tǒng)如果需要被其他系統(tǒng)調(diào)用，就需要暴露 API，這些 API 代表著一個(gè)一個(gè)的功能點(diǎn)。

如果兩個(gè)系統(tǒng)中間通信，在系統(tǒng)之間加上一個(gè)中介者協(xié)助 API 的調(diào)用，這個(gè)中介者就是 API 網(wǎng)關(guān)。

 

對接兩個(gè)系統(tǒng)的 API 網(wǎng)關(guān)

當(dāng)然，API 網(wǎng)關(guān)可以放在兩個(gè)系統(tǒng)之間，同時(shí)也可以放在客戶端與服務(wù)端之間。

 

對接客戶端和服務(wù)端的 API 網(wǎng)關(guān)

知道了 API 網(wǎng)關(guān)的基本定義，再來看看為什么我們要使用它。

為何要使用 API 網(wǎng)關(guān)

網(wǎng)關(guān)作為系統(tǒng)的唯一入口，也就是說，進(jìn)入系統(tǒng)的所有請求都需要經(jīng)過 API 網(wǎng)關(guān)。

當(dāng)系統(tǒng)外部的應(yīng)用或者客戶端訪問系統(tǒng)的時(shí)候，都會(huì)遇到這樣的情況：

• 系統(tǒng)要判斷它們的權(quán)限
• 如果傳輸協(xié)議不一致，需要對協(xié)議進(jìn)行轉(zhuǎn)換
• 如果調(diào)用水平擴(kuò)展的服務(wù)，需要做負(fù)載均衡
• 一旦請求流量超出系統(tǒng)承受的范圍，需要做限流操作
• 針對每個(gè)請求以及回復(fù)，系統(tǒng)會(huì)記錄響應(yīng)的日志

也就是說，只要是涉及到對系統(tǒng)的請求，并且能夠從業(yè)務(wù)中抽離出來的功能，都有可能在網(wǎng)關(guān)上實(shí)現(xiàn)。

例如：協(xié)議轉(zhuǎn)換，負(fù)載均衡，請求路由，流量控制等等。后面我們會(huì)一一給大家介紹這些功能。

在了解 API 網(wǎng)關(guān)有哪些基本功能以后，來看看它可以服務(wù)于哪些系統(tǒng)或者客戶端。

API 網(wǎng)關(guān)服務(wù)定位

API 網(wǎng)關(guān)擁有處理請求的能力，從定位來看分為 5 類：

①面向 WebApp，這部分的系統(tǒng)以網(wǎng)站和 H5 應(yīng)用為主。通過前后端分離的設(shè)計(jì)，將大部分的業(yè)務(wù)功能都放在了后端，前面的 Web App 只展示頁面的內(nèi)容。

②MobileApp，這里的 Mobile 指的是 iOS 和 Android，設(shè)計(jì)思路和 WebApp 基本相同。

區(qū)別是 API 網(wǎng)關(guān)需要做一些移動(dòng)設(shè)備管理的工作(MDM)。例如：設(shè)備的注冊，激活，使用，淘汰等，全生命周期的管理。

由于移動(dòng)設(shè)備的特殊性，導(dǎo)致了我們在考慮移動(dòng)設(shè)備請求的時(shí)候，需要考慮請求，設(shè)備，使用者之間的關(guān)系。

③面向合作伙伴的 OpenAPI，通常系統(tǒng)會(huì)給合作伙伴提供接口。這些接口會(huì)全部開放或者部分開發(fā)，在有條件限制(時(shí)間，流量)的情況下給合作伙伴訪問。因此需要更多考慮 API 網(wǎng)關(guān)的流量和安全以及協(xié)議轉(zhuǎn)換的管理。

④企業(yè)內(nèi)部可擴(kuò)展 API，給企業(yè)內(nèi)部的其他部門或者項(xiàng)目使用，也可以作為中臺(tái)輸出的一部分，支持其他系統(tǒng)。這里需要更多地考慮劃分功能邊界，認(rèn)證和授權(quán)問題。

⑤面向 IOT 設(shè)備，會(huì)接收來自 IOT 設(shè)備的請求，特別是工業(yè)傳感器等設(shè)備。這里需要考慮協(xié)議轉(zhuǎn)換和數(shù)據(jù)過濾。

API 網(wǎng)關(guān)架構(gòu)

既然談了 API 網(wǎng)關(guān)的功能和定位，接下來說說它的架構(gòu)：

 

API 網(wǎng)關(guān)系統(tǒng)架構(gòu)圖

API 網(wǎng)關(guān)拆分成為 3 個(gè)系統(tǒng)：

• Gateway-Core(核心)
• Gateway-Admin(管理)
• Gateway-Monitor(監(jiān)控)

Gateway-Core 核心網(wǎng)關(guān)，負(fù)責(zé)接收客戶端請求，調(diào)度、加載和執(zhí)行組件，將請求路由到上游服務(wù)端，并處理其返回的結(jié)果。

大多數(shù)的功能都在這一層完成，例如：驗(yàn)證，鑒權(quán)，負(fù)載均衡，協(xié)議轉(zhuǎn)換，服務(wù)路由，數(shù)據(jù)緩存。如果沒有其他兩個(gè)子系統(tǒng)，它也是可以單獨(dú)運(yùn)行的。

Gateway-Admin 網(wǎng)關(guān)管理界面，可以進(jìn)行 API、組件等系統(tǒng)基礎(chǔ)信息的配置;例如：限流的策略，緩存配置，告警設(shè)置。

Gateway-Monitor 監(jiān)控日志、生成各種運(yùn)維管理報(bào)表、自動(dòng)告警等;管理和監(jiān)控系統(tǒng)主要是為核心系統(tǒng)服務(wù)的，起到支撐的作用。

API 網(wǎng)關(guān)技術(shù)原理

上面談到了網(wǎng)關(guān)的架構(gòu)思路，這里談幾點(diǎn)技術(shù)原理。平時(shí)我們在使用網(wǎng)關(guān)的時(shí)候，多注重其實(shí)現(xiàn)的功能。例如：路由，負(fù)載均衡，限流，緩存，日志，發(fā)布等等。

實(shí)際上這些功能的背后有一些原理我們可以了解，這樣在應(yīng)用功能的時(shí)候會(huì)更加篤定。下面是幾個(gè)原理分享給大家。

協(xié)議轉(zhuǎn)換

每個(gè)系統(tǒng)內(nèi)部服務(wù)之間的調(diào)用，可以統(tǒng)一使用一種協(xié)議，例如：HTTP，GRPC。

假設(shè)每個(gè)系統(tǒng)使用的協(xié)議不同，那么系統(tǒng)之間的調(diào)用或者數(shù)據(jù)傳輸，就存在協(xié)議轉(zhuǎn)換的問題了。如果解決這個(gè)問題呢?API 網(wǎng)關(guān)通過泛化調(diào)用的方式實(shí)現(xiàn)協(xié)議之間的轉(zhuǎn)化。

實(shí)際上就是將不同的協(xié)議轉(zhuǎn)換成“通用協(xié)議”，然后再將通用協(xié)議轉(zhuǎn)化成本地系統(tǒng)能夠識(shí)別的協(xié)議。

這一轉(zhuǎn)化工作通常在 API 網(wǎng)關(guān)完成。通用協(xié)議用得比較多的有 JSON，當(dāng)然也有使用 XML 或者自定義 JSON 文件的。

 

不同的協(xié)議需要轉(zhuǎn)化成共同語言進(jìn)行傳輸

鏈?zhǔn)教幚?/span>

設(shè)計(jì)模式中有一種責(zé)任鏈模式，它將“處理請求”和“處理步驟”分開。每個(gè)處理步驟，只關(guān)心這個(gè)步驟上需要做的處理操作，處理步驟存在先后順序。

消息從第一個(gè)“處理步驟”流入，從最后一個(gè)“處理步驟”流出，每個(gè)步驟對經(jīng)過的消息進(jìn)行處理，整個(gè)過程形成了一個(gè)鏈條。在 API 網(wǎng)關(guān)中也用到了類似的模式。

 

Zuul 網(wǎng)關(guān)過濾器鏈?zhǔn)教幚?/p>

下面以 Zuul 為例，當(dāng)消息出入網(wǎng)關(guān)需要經(jīng)歷一系列的過濾器。這些過濾器之間是有先后順序的，并且在每個(gè)過濾器需要進(jìn)行的工作也是各不一樣：

• PRE：前置過濾器，用來處理通用事務(wù)，比如鑒權(quán)，限流，熔斷降級，緩存。并且可以通過 Custom 過濾器進(jìn)行擴(kuò)展。
• ROUTING：路由過濾器，在這種過濾器中把用戶請求發(fā)送給 Origin Server。它主要負(fù)責(zé)：協(xié)議轉(zhuǎn)化和路由的工作。
• POST：后置過濾器，從 Origin Server 返回的響應(yīng)信息會(huì)經(jīng)過它，再返回給調(diào)用者。在返回的 Response 上加入 Response Header，同時(shí)可以做 Response 的統(tǒng)計(jì)和日志記錄。
• ERROR：錯(cuò)誤過濾器，當(dāng)上面三個(gè)過濾器發(fā)生異常時(shí)，錯(cuò)誤信息會(huì)進(jìn)到這里，并對錯(cuò)誤進(jìn)行處理。

異步請求

所有的請求通過 API 網(wǎng)關(guān)訪問應(yīng)用服務(wù)，一旦吞吐量上去了，如何高效地處理這些請求?

拿 Zuul 為例，Zuul1 采用：一個(gè)線程處理一個(gè)請求的方式。線程負(fù)責(zé)接受請求，然后調(diào)用應(yīng)用返回結(jié)果。

如果把網(wǎng)絡(luò)請求看成一次 IO 操作的話，處理請求的線程，從接受請求，到服務(wù)返回響應(yīng)，都是阻塞狀態(tài)。

同時(shí)，如果多個(gè)線程都處在這種狀態(tài)，會(huì)導(dǎo)致系統(tǒng)緩慢。因?yàn)槊總€(gè)網(wǎng)關(guān)能夠開啟的線程數(shù)量是有限的，特別是在訪問的高峰期。

 

每個(gè)線程處理一個(gè)請求

為了解決這個(gè)問題，Zuul2 啟動(dòng)了異步請求的機(jī)制。每個(gè)請求進(jìn)入網(wǎng)關(guān)的時(shí)候，會(huì)被包裝成一個(gè)事件，CPU 內(nèi)核會(huì)維持一個(gè)監(jiān)聽器，不斷輪詢“請求事件”。

一旦，發(fā)現(xiàn)請求事件，就會(huì)調(diào)用對應(yīng)的應(yīng)用。獲取應(yīng)用返回的信息以后，按照請求的要求把數(shù)據(jù)/文件放到指定的緩沖區(qū)，同時(shí)發(fā)送一個(gè)通知事件，告訴請求端數(shù)據(jù)已經(jīng)就緒，可以從這個(gè)緩沖獲取數(shù)據(jù)/文件。

這個(gè)過程是異步的，請求的線程不用一直等待數(shù)據(jù)的返回。它在請求完畢以后，就直接返回了，這時(shí)它可以做其他的事情。

當(dāng)請求數(shù)據(jù)被 CPU 內(nèi)核獲取，并且發(fā)送到指定的數(shù)據(jù)緩沖區(qū)時(shí)，請求的線程會(huì)接到“數(shù)據(jù)返回”的通知，然后就直接使用數(shù)據(jù)，不用自己去做取數(shù)據(jù)的操作。

 

異步請求處理，CPU 處理數(shù)據(jù)以后通知請求端

實(shí)現(xiàn)異步處理請求有兩種模式，分別是：

• Reactor
• Proactor

 

Reactor 工作原理流水圖

Reactor：通過 handle_events 事件循環(huán)處理請求。用戶線程注冊事件處理器之后，可以繼續(xù)執(zhí)行其他的工作(異步)，而 Reactor 線程負(fù)責(zé)調(diào)用內(nèi)核的 Select 函數(shù)檢查 Socket 狀態(tài)。

當(dāng)有 Socket 被激活時(shí)(獲取網(wǎng)絡(luò)數(shù)據(jù))，則通知相應(yīng)的用戶線程，執(zhí)行 handle_event 進(jìn)行數(shù)據(jù)讀取、處理的工作。

 

Proactor 工作原理流水圖

Proactor：用戶線程使用 CPU 內(nèi)核提供的異步 IO 發(fā)起請求，請求發(fā)起以后立即返回。CPU 內(nèi)核繼續(xù)執(zhí)行用戶請求線程代碼。

此時(shí)用戶線程已將 AsynchronousOperation(異步處理)和 CompletionHandler(完成獲取資源)注冊到內(nèi)核。之后操作系統(tǒng)開啟獨(dú)立的內(nèi)核線程去處理 IO 操作。

當(dāng)請求的數(shù)據(jù)到達(dá)時(shí)，由內(nèi)核負(fù)責(zé)讀取 Socket(網(wǎng)絡(luò)請求)中的數(shù)據(jù)，并寫入用戶指定的緩沖區(qū)中。

最后內(nèi)核將數(shù)據(jù)和用戶線程注冊的 CompletionHandler 分發(fā)給內(nèi)部 Proactor，Proactor 將 IO 完成的信息通知給用戶線程(一般通過調(diào)用用戶線程注冊的完成事件處理函數(shù))，完成異步 IO。

API 網(wǎng)關(guān)實(shí)現(xiàn)功能

說起對 API 網(wǎng)關(guān)的使用，我們還是對具體功能更加感興趣。讓我們一起來看看它實(shí)現(xiàn)了哪些功能。

負(fù)載均衡

當(dāng)網(wǎng)關(guān)后面掛接同一應(yīng)用的多個(gè)副本時(shí)，每次用戶的請求都會(huì)通過網(wǎng)關(guān)的負(fù)載均衡算法，路由到對應(yīng)的服務(wù)上面。例如：隨機(jī)算法，權(quán)重算法，Hash 算法等等。

如果上游服務(wù)采取微服務(wù)的架構(gòu)，也可以和注冊中心合作實(shí)現(xiàn)動(dòng)態(tài)的負(fù)載均衡。

當(dāng)微服務(wù)動(dòng)態(tài)掛載(動(dòng)態(tài)擴(kuò)容)的時(shí)候，可以通過服務(wù)注冊中心獲取微服務(wù)的注冊信息，從而實(shí)現(xiàn)負(fù)載均衡。

 Nginx+Lua+服務(wù)注冊中心實(shí)現(xiàn)動(dòng)態(tài)負(fù)載均衡

路由選擇

這個(gè)不言而喻，網(wǎng)關(guān)可以根據(jù)請求的 URL 地址解析，知道需要訪問的服務(wù)。再通過路由表把請求路由到目標(biāo)服務(wù)上去。

有時(shí)候因?yàn)榫W(wǎng)絡(luò)原因，服務(wù)可能會(huì)暫時(shí)的不可用，這個(gè)時(shí)候我們希望可以再次對服務(wù)進(jìn)行重試。

Zuul 作為 API 網(wǎng)關(guān)將請求路由到上游服務(wù)器

 

例如：Zuul 與 Spring Retry 合作完成路由重試。

#是否開啟重試功能 
zuul.retryable=true 
#對當(dāng)前服務(wù)的重試次數(shù) 
ribbon.MaxAutoRetries=2 

流量控制

限流是 API 網(wǎng)關(guān)常用的功能之一，當(dāng)上游服務(wù)超出請求承載范圍，或者服務(wù)因?yàn)槟撤N原因無法正常使用，都會(huì)導(dǎo)致服務(wù)處理能力下滑。

這個(gè)時(shí)候，API 網(wǎng)關(guān)作為“看門人”，就可以限制流入的請求，讓應(yīng)用服務(wù)器免受沖擊。

限流實(shí)際上就是限制流入請求的數(shù)量，其算法不少，有令牌桶算法，漏桶算法，連接數(shù)限制等等。這里我們就介紹三個(gè)常用的，一般通過 Nginx+Lua 來實(shí)現(xiàn)。

 

令牌桶限流

統(tǒng)一鑒權(quán)

訪問應(yīng)用服務(wù)器的請求都需要擁有一定權(quán)限，如果說每訪問一個(gè)服務(wù)都需要驗(yàn)證一次權(quán)限，這個(gè)對效率是很大的影響。可以把權(quán)限認(rèn)證放到 API 網(wǎng)關(guān)來進(jìn)行。

目前比較常見的做法是，用戶通過登錄服務(wù)獲取 Token，把它存放到客戶端，在每次請求的時(shí)候把這個(gè) Token 放入請求頭，一起發(fā)送給服務(wù)器。

API 網(wǎng)關(guān)要做的事情就是解析這個(gè) Token，知道訪問者是誰(鑒定)，他能做什么/訪問什么(權(quán)限)。

說白了就是看訪問者能夠訪問哪些 URL，這里根據(jù)權(quán)限/角色定義一個(gè)訪問列表。

如果要實(shí)現(xiàn)多個(gè)系統(tǒng)的 OSS(Single Sign On 單點(diǎn)登錄)，API 網(wǎng)關(guān)需要和 CAS(Central Authentication Service 中心鑒權(quán)服務(wù))做連接，來確定請求者的身份和權(quán)限。

熔斷降級

當(dāng)應(yīng)用服務(wù)出現(xiàn)異常，不能繼續(xù)提供服務(wù)的時(shí)候，也就是說應(yīng)用服務(wù)不可用了。作為 API 網(wǎng)關(guān)需要做出處理，把請求導(dǎo)入到其他服務(wù)上。

或者對服務(wù)進(jìn)行降級處理，例如：用兜底的服務(wù)數(shù)據(jù)返回客戶端，或者提示服務(wù)暫時(shí)不可用。

同時(shí)通過服務(wù)注冊中心，監(jiān)聽存在問題的服務(wù)，一旦服務(wù)恢復(fù)，隨即恢復(fù)路由請求到該服務(wù)。

例如：Zuul 中提供了 ZuulFallbackProvider 接口來實(shí)現(xiàn)熔斷，它提供兩個(gè)方法，一個(gè)指明熔斷攔截的服務(wù) getRoute，一個(gè)指定返回內(nèi)容 ClientHttpResponse。

public  interface ZuulFallbackProvider { 
   /** 
     * The route this fallback will be used  for. 
     * @return The route the fallback will be  used for. 
     */ 
    public String getRoute(); 
 
    /** 
     * Provides a fallback response. 
     * @return The fallback response. 
     */ 
    public  ClientHttpResponsefallbackResponse(); 
} 

我們通過自定義的 Fallback 方法，并且將其指定給某個(gè) Route 來實(shí)現(xiàn)該 Route 訪問出問題的熔斷處理。

主要繼承 ZuulFallbackProvider 接口來實(shí)現(xiàn)，ZuulFallbackProvider 默認(rèn)有兩個(gè)方法，一個(gè)用來指明熔斷攔截哪個(gè)服務(wù)，一個(gè)定制返回內(nèi)容。

 

API 網(wǎng)關(guān)熔斷降級

發(fā)布測試

在發(fā)布版本的時(shí)候會(huì)采用：金絲雀發(fā)布和藍(lán)綠發(fā)布。作為 API 網(wǎng)關(guān)可以使用路由選擇和流量切換來協(xié)助上述行為。這里以金絲雀發(fā)布為例，看看 API 網(wǎng)關(guān)如何做路由轉(zhuǎn)換的。

假設(shè)將 4 個(gè)服務(wù)從 V1 更新到 V2 版本，這 4 個(gè)服務(wù)的流量請求由 1 個(gè) API 網(wǎng)關(guān)管理。

 

那么先將一臺(tái)服務(wù)與 API 網(wǎng)關(guān)斷開，部署 V2 版本的服務(wù)，然后 API 網(wǎng)關(guān)再將流量導(dǎo)入到 V2 版本的服務(wù)上。

 

這里流量的導(dǎo)入可以是逐步進(jìn)行的，一旦 V2 版本的服務(wù)趨于穩(wěn)定。再如法炮制，將其他服務(wù)替換成 V2 版本。

 

金絲雀發(fā)布一般先發(fā) 1 臺(tái)，或者一個(gè)小比例，例如 2% 的服務(wù)器，主要做流量驗(yàn)證用，也稱為金絲雀(Canary)測試(灰度測試)。

其來歷是，曠工下礦洞前，先放一只金絲雀探查是否有毒氣，金絲雀發(fā)布由此得名。

金絲雀測試需要完善的監(jiān)控設(shè)施配合，通過監(jiān)控指標(biāo)反饋，觀察金絲雀的健康狀況，作為后續(xù)發(fā)布或回滾的依據(jù)。

如果金絲測試通過，則把剩余的 V1 版本全部升級為 V2 版本。如果金絲雀測試失敗，則直接回退金絲雀，發(fā)布失敗。

緩存數(shù)據(jù)

 

我們可以在 API 網(wǎng)關(guān)緩存一些修改頻率不高的數(shù)據(jù)。例如：用戶信息，配置信息，通過服務(wù)定期刷新這個(gè)緩存就行了：

• 用戶請求先訪問 API 網(wǎng)關(guān)，如果發(fā)現(xiàn)有緩存信息，直接返回給用戶。
• 如果沒有發(fā)現(xiàn)緩存信息，回源到應(yīng)用服務(wù)器獲取信息。
• 另外，有一個(gè)緩存更新服務(wù)，定期把應(yīng)用服務(wù)器中的信息更新到網(wǎng)關(guān)本地緩存中。

日志記錄

通過 API 網(wǎng)關(guān)上的過濾器我們可以加入日志服務(wù)，記錄請求和返回信息。同時(shí)可以建立一個(gè)管理員的界面去監(jiān)控這些數(shù)據(jù)。

 

日志服務(wù)簡圖

日志記錄了以后，可以做很多功能擴(kuò)展。我們整理了以下幾點(diǎn)供大家參考：

• 報(bào)表分析：針對服務(wù)訪問情況，提供可視化展示。
• 實(shí)時(shí)查詢：了解實(shí)時(shí)關(guān)鍵信息，例如：吞吐量，并發(fā)數(shù)。在秒殺活動(dòng)的時(shí)候，會(huì)特別關(guān)注。
• 異常告警：針對關(guān)鍵參數(shù)進(jìn)行監(jiān)控，對于統(tǒng)計(jì)結(jié)果支持閾值報(bào)警，對接阿里云通知中心、短信、釘釘進(jìn)行告警。
• 日志投遞：將日志進(jìn)行歸檔，存放到文件庫或者數(shù)據(jù)倉庫中，以便后期分析。

 

日志記錄衍生的功能

流行 API 網(wǎng)關(guān)對比

在介紹了 API 網(wǎng)關(guān)的功能以后，再來看看目前幾個(gè)流行的 API 網(wǎng)關(guān)項(xiàng)目。看看他們各自的特點(diǎn)，并且把他們做一個(gè)簡單的比較。這些網(wǎng)關(guān)目前都是開源的，大家可以有選擇地在項(xiàng)目中使用。

Kong

Kong 是 Mash ape 公司的開源項(xiàng)目，它是一個(gè)在 Nginx 中運(yùn)行的 Lua 應(yīng)用程序，并且可以通過 Lua-Nginx 模塊實(shí)現(xiàn)擴(kuò)展。

所以，可以通過插件集合的方式定制功能，例如：HTTP 基本認(rèn)證、密鑰認(rèn)證、CORS(Cross-origin Resource Sharing，跨域資源共享)、TCP、UDP、日志、API 限流、請求轉(zhuǎn)發(fā)以及監(jiān)控，都是目前已有的插件。

由于是基于 Nginx 的，所以可以對網(wǎng)關(guān)進(jìn)行水平擴(kuò)展，來應(yīng)對大批量的網(wǎng)絡(luò)請求。

 

Kong 架構(gòu)圖

Kong 主要有三個(gè)組件：

• KongServer ：基于 Nginx 的服務(wù)器，用來接收 API 請求。
• ApacheCassandra/PostgreSQL：用來存儲(chǔ)操作數(shù)據(jù)。
• Kongdashboard：UI 管理工具。

Traefik

 

Traefik 架構(gòu)圖

Traefik 是 HTTP 反向代理和負(fù)載均衡器，可以輕松部署微服務(wù)，可以與現(xiàn)有的組件(Docker、Swarm，Kubernetes，Marathon，Consul，Etcd)做集成。

因?yàn)橹С謩?dòng)態(tài)配置，所以它的伸縮性很好。不過它只支持 HTTP、HTTPS 和 GRPC。如果你需要 TCP 負(fù)載均衡，那么您需要選擇其他方案了。

Ambassador

 

Ambassador 架構(gòu)圖

Ambassador 是一個(gè)基于 Envoy Proxy 構(gòu)建的，Kubernetes 原生的開源微服務(wù)網(wǎng)關(guān)。

它在構(gòu)建之初就致力于支持多個(gè)獨(dú)立的團(tuán)隊(duì)，這些團(tuán)隊(duì)需要為最終用戶快速發(fā)布、監(jiān)控和更新服務(wù)。

Ambassador 還具有 Kubernetes Ingress 和負(fù)載均衡的能力。它支持處理 Kubernetes Ingress Controller 和負(fù)載均衡等功能，可以與 Istio 無縫集成。

Zuul

 

Zuul 2 結(jié)構(gòu)圖

Zuul 是 Spring Cloud 全家桶中的微服務(wù) API 網(wǎng)關(guān)。所有從設(shè)備或網(wǎng)站來的請求都會(huì)經(jīng)過 Zuul 到達(dá)后端的 Netflix 應(yīng)用程序。

作為一個(gè)邊界性質(zhì)的應(yīng)用程序，Zuul 提供了動(dòng)態(tài)路由、監(jiān)控、彈性負(fù)載和安全功能。包括 Zuul1 和 Zuul2 兩個(gè)版本。

介紹了幾個(gè)開源 API 網(wǎng)關(guān)的基本信息以后，我們從幾個(gè)維度對他們進(jìn)行比較：

 

從開源社區(qū)活躍度來說，Kong 和 Traefik 較好;從成熟度來看，較好的是 Kong、Traefik;從架構(gòu)優(yōu)勢的擴(kuò)展性來看，Kong 有豐富的插件，Ambassador 也有插件但不多，而 Zuul 是需要自研。

但 Zuul 由于與 Spring Cloud 集成，如果使用 Spring Cloud 的小伙伴可以考慮使用。

總結(jié)

API 網(wǎng)關(guān)是系統(tǒng)內(nèi)外通訊的中介者。從定位上來說它服務(wù) WebApp，MobileApp，合作伙伴 OpenAPI，企業(yè)內(nèi)部可擴(kuò)展 API，以及 IOT 設(shè)備。

從架構(gòu)設(shè)計(jì)角度來說，分為 Gateway-Core(核心)、Gateway-Admin(管理)、Gateway-Monitor(監(jiān)控)三部分。

API 網(wǎng)關(guān)需要注意的技術(shù)原理有，協(xié)議轉(zhuǎn)換，鏈?zhǔn)教幚硪约爱惒秸埱蟆Ｋ膽?yīng)用比較廣泛，例如：負(fù)載均衡，路由選擇，流量控制，統(tǒng)一鑒權(quán)，熔斷降級，發(fā)布測試，緩存數(shù)據(jù)，日志記錄等。

比較流行的開源 API網(wǎng)關(guān)有 Kong，Traefik，Ambassador，Zuul。從使用上來說他們各有千秋，可以根據(jù)項(xiàng)目的情況選取。

作者：崔皓

簡介：十六年開發(fā)和架構(gòu)經(jīng)驗(yàn)，曾擔(dān)任過惠普武漢交付中心技術(shù)專家，需求分析師，項(xiàng)目經(jīng)理，后在創(chuàng)業(yè)公司擔(dān)任技術(shù)/產(chǎn)品經(jīng)理。善于學(xué)習(xí)，樂于分享。目前專注于技術(shù)架構(gòu)與研發(fā)管理。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】