隨著互聯網技術的飛速發展，各類線上業務蓬勃發展，軟件系統如雨后春筍般呈現在我們面前。
圖片來自 Pexels
為了提高系統的性能和可靠性，將應用服務進行拆分微服務化。作為系統入口的 API 網關也逐漸成為了標配。
今天我們一起來看看 API 網關的設計思路，需要承載了哪些功能?以及如何選擇流行的 API 網關?
什么是 API 網關
既然需要 API 網關為我所用，首先就讓我們來了解一下什么是 API 網關。
什么是 API 網關
網關一詞最早出現在網絡設備，比如兩個相互獨立的局域網之間通過路由器進行通信，中間的路由被稱之為網關。
任何一個應用系統如果需要被其他系統調用，就需要暴露 API，這些 API 代表著一個一個的功能點。
如果兩個系統中間通信，在系統之間加上一個中介者協助 API 的調用，這個中介者就是 API 網關。
對接兩個系統的 API 網關
當然，API 網關可以放在兩個系統之間，同時也可以放在客戶端與服務端之間。
對接客戶端和服務端的 API 網關
知道了 API 網關的基本定義，再來看看為什么我們要使用它。
為何要使用 API 網關
網關作為系統的唯一入口，也就是說，進入系統的所有請求都需要經過 API 網關。
當系統外部的應用或者客戶端訪問系統的時候，都會遇到這樣的情況：
- 系統要判斷它們的權限
- 如果傳輸協議不一致，需要對協議進行轉換
- 如果調用水平擴展的服務，需要做負載均衡
- 一旦請求流量超出系統承受的范圍，需要做限流操作
- 針對每個請求以及回復，系統會記錄響應的日志
也就是說，只要是涉及到對系統的請求，并且能夠從業務中抽離出來的功能，都有可能在網關上實現。
例如：協議轉換，負載均衡，請求路由，流量控制等等。后面我們會一一給大家介紹這些功能。
在了解 API 網關有哪些基本功能以后，來看看它可以服務于哪些系統或者客戶端。
API 網關服務定位
API 網關擁有處理請求的能力，從定位來看分為 5 類：
①面向 WebApp，這部分的系統以網站和 H5 應用為主。通過前后端分離的設計，將大部分的業務功能都放在了后端，前面的 Web App 只展示頁面的內容。
②MobileApp，這里的 Mobile 指的是 IOS 和 Android，設計思路和 WebApp 基本相同。
區別是 API 網關需要做一些移動設備管理的工作(MDM)。例如：設備的注冊，激活，使用，淘汰等，全生命周期的管理。
由于移動設備的特殊性，導致了我們在考慮移動設備請求的時候，需要考慮請求，設備，使用者之間的關系。
③面向合作伙伴的 OpenAPI，通常系統會給合作伙伴提供接口。這些接口會全部開放或者部分開發，在有條件限制(時間，流量)的情況下給合作伙伴訪問。因此需要更多考慮 API 網關的流量和安全以及協議轉換的管理。
④企業內部可擴展 API，給企業內部的其他部門或者項目使用，也可以作為中臺輸出的一部分，支持其他系統。這里需要更多地考慮劃分功能邊界，認證和授權問題。
⑤面向 IOT 設備，會接收來自 IOT 設備的請求，特別是工業傳感器等設備。這里需要考慮協議轉換和數據過濾。
API 網關架構
既然談了 API 網關的功能和定位，接下來說說它的架構：
API 網關系統架構圖
API 網關拆分成為 3 個系統：
- Gateway-Core(核心)
- Gateway-Admin(管理)
- Gateway-Monitor(監控)
Gateway-Core 核心網關，負責接收客戶端請求，調度、加載和執行組件，將請求路由到上游服務端，并處理其返回的結果。
大多數的功能都在這一層完成，例如：驗證，鑒權，負載均衡，協議轉換，服務路由，數據緩存。如果沒有其他兩個子系統，它也是可以單獨運行的。
Gateway-Admin 網關管理界面，可以進行 API、組件等系統基礎信息的配置;例如：限流的策略，緩存配置，告警設置。
Gateway-Monitor 監控日志、生成各種運維管理報表、自動告警等;管理和監控系統主要是為核心系統服務的，起到支撐的作用。
API 網關技術原理
上面談到了網關的架構思路，這里談幾點技術原理。平時我們在使用網關的時候，多注重其實現的功能。例如：路由，負載均衡，限流，緩存，日志，發布等等。
實際上這些功能的背后有一些原理我們可以了解，這樣在應用功能的時候會更加篤定。下面是幾個原理分享給大家。
協議轉換
每個系統內部服務之間的調用，可以統一使用一種協議，例如：HTTP，GRPC。
假設每個系統使用的協議不同，那么系統之間的調用或者數據傳輸，就存在協議轉換的問題了。如果解決這個問題呢?API 網關通過泛化調用的方式實現協議之間的轉化。
實際上就是將不同的協議轉換成“通用協議”，然后再將通用協議轉化成本地系統能夠識別的協議。
這一轉化工作通常在 API 網關完成。通用協議用得比較多的有 JSON，當然也有使用 XML 或者自定義 JSON 文件的。
不同的協議需要轉化成共同語言進行傳輸
鏈式處理
設計模式中有一種責任鏈模式，它將“處理請求”和“處理步驟”分開。每個處理步驟，只關心這個步驟上需要做的處理操作，處理步驟存在先后順序。
消息從第一個“處理步驟”流入，從最后一個“處理步驟”流出，每個步驟對經過的消息進行處理，整個過程形成了一個鏈條。在 API 網關中也用到了類似的模式。
Zuul 網關過濾器鏈式處理
下面以 Zuul 為例，當消息出入網關需要經歷一系列的過濾器。這些過濾器之間是有先后順序的，并且在每個過濾器需要進行的工作也是各不一樣：
- PRE：前置過濾器，用來處理通用事務，比如鑒權，限流，熔斷降級，緩存。并且可以通過 Custom 過濾器進行擴展。
- ROUTING：路由過濾器，在這種過濾器中把用戶請求發送給 Origin Server。它主要負責：協議轉化和路由的工作。
- POST：后置過濾器，從 Origin Server 返回的響應信息會經過它，再返回給調用者。在返回的 Response 上加入 Response Header，同時可以做 Response 的統計和日志記錄。
- ERROR：錯誤過濾器，當上面三個過濾器發生異常時，錯誤信息會進到這里，并對錯誤進行處理。
異步請求
所有的請求通過 API 網關訪問應用服務，一旦吞吐量上去了，如何高效地處理這些請求?
拿 Zuul 為例，Zuul1 采用：一個線程處理一個請求的方式。線程負責接受請求，然后調用應用返回結果。
如果把網絡請求看成一次 IO 操作的話，處理請求的線程，從接受請求，到服務返回響應，都是阻塞狀態。
同時，如果多個線程都處在這種狀態，會導致系統緩慢。因為每個網關能夠開啟的線程數量是有限的，特別是在訪問的高峰期。
每個線程處理一個請求
為了解決這個問題，Zuul2 啟動了異步請求的機制。每個請求進入網關的時候，會被包裝成一個事件，CPU 內核會維持一個監聽器，不斷輪詢“請求事件”。
一旦，發現請求事件，就會調用對應的應用。獲取應用返回的信息以后，按照請求的要求把數據/文件放到指定的緩沖區，同時發送一個通知事件，告訴請求端數據已經就緒，可以從這個緩沖獲取數據/文件。
這個過程是異步的，請求的線程不用一直等待數據的返回。它在請求完畢以后，就直接返回了，這時它可以做其他的事情。
當請求數據被 CPU 內核獲取，并且發送到指定的數據緩沖區時，請求的線程會接到“數據返回”的通知，然后就直接使用數據，不用自己去做取數據的操作。
異步請求處理，CPU 處理數據以后通知請求端
實現異步處理請求有兩種模式，分別是：
- Reactor
- Proactor
Reactor 工作原理流水圖
Reactor：通過 handle_events 事件循環處理請求。用戶線程注冊事件處理器之后，可以繼續執行其他的工作(異步)，而 Reactor 線程負責調用內核的 Select 函數檢查 Socket 狀態。
當有 Socket 被激活時(獲取網絡數據)，則通知相應的用戶線程，執行 handle_event 進行數據讀取、處理的工作。
Proactor 工作原理流水圖
Proactor：用戶線程使用 CPU 內核提供的異步 IO 發起請求，請求發起以后立即返回。CPU 內核繼續執行用戶請求線程代碼。
此時用戶線程已將 AsynchronousOperation(異步處理)和 CompletionHandler(完成獲取資源)注冊到內核。之后操作系統開啟獨立的內核線程去處理 IO 操作。
當請求的數據到達時，由內核負責讀取 Socket(網絡請求)中的數據，并寫入用戶指定的緩沖區中。
最后內核將數據和用戶線程注冊的 CompletionHandler 分發給內部 Proactor，Proactor 將 IO 完成的信息通知給用戶線程(一般通過調用用戶線程注冊的完成事件處理函數)，完成異步 IO。
API 網關實現功能
說起對 API 網關的使用，我們還是對具體功能更加感興趣。讓我們一起來看看它實現了哪些功能。
負載均衡
當網關后面掛接同一應用的多個副本時，每次用戶的請求都會通過網關的負載均衡算法，路由到對應的服務上面。例如：隨機算法，權重算法，Hash 算法等等。
如果上游服務采取微服務的架構，也可以和注冊中心合作實現動態的負載均衡。
當微服務動態掛載(動態擴容)的時候，可以通過服務注冊中心獲取微服務的注冊信息，從而實現負載均衡。
Nginx+Lua+服務注冊中心實現動態負載均衡
路由選擇
這個不言而喻，網關可以根據請求的 URL 地址解析，知道需要訪問的服務。再通過路由表把請求路由到目標服務上去。
有時候因為網絡原因，服務可能會暫時的不可用，這個時候我們希望可以再次對服務進行重試。
Zuul 作為 API 網關將請求路由到上游服務器
例如：Zuul 與 Spring Retry 合作完成路由重試。
#是否開啟重試功能 zuul.retryable=true #對當前服務的重試次數 ribbon.MaxAutoRetries=2
流量控制
限流是 API 網關常用的功能之一，當上游服務超出請求承載范圍，或者服務因為某種原因無法正常使用，都會導致服務處理能力下滑。
這個時候，API 網關作為“看門人”，就可以限制流入的請求，讓應用服務器免受沖擊。
限流實際上就是限制流入請求的數量，其算法不少，有令牌桶算法，漏桶算法，連接數限制等等。這里我們就介紹三個常用的，一般通過 Nginx+Lua 來實現。
令牌桶限流
統一鑒權
訪問應用服務器的請求都需要擁有一定權限，如果說每訪問一個服務都需要驗證一次權限，這個對效率是很大的影響?？梢园褭嘞拚J證放到 API 網關來進行。
目前比較常見的做法是，用戶通過登錄服務獲取 Token，把它存放到客戶端，在每次請求的時候把這個 Token 放入請求頭，一起發送給服務器。
API 網關要做的事情就是解析這個 Token，知道訪問者是誰(鑒定)，他能做什么/訪問什么(權限)。
說白了就是看訪問者能夠訪問哪些 URL，這里根據權限/角色定義一個訪問列表。
如果要實現多個系統的 OSS(Single Sign On 單點登錄)，API 網關需要和 CAS(Central Authentication Service 中心鑒權服務)做連接，來確定請求者的身份和權限。
熔斷降級
當應用服務出現異常，不能繼續提供服務的時候，也就是說應用服務不可用了。作為 API 網關需要做出處理，把請求導入到其他服務上。
或者對服務進行降級處理，例如：用兜底的服務數據返回客戶端，或者提示服務暫時不可用。
同時通過服務注冊中心，監聽存在問題的服務，一旦服務恢復，隨即恢復路由請求到該服務。
例如：Zuul 中提供了 ZuulFallbackProvider 接口來實現熔斷，它提供兩個方法，一個指明熔斷攔截的服務 getRoute，一個指定返回內容 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 方法，并且將其指定給某個 Route 來實現該 Route 訪問出問題的熔斷處理。
主要繼承 ZuulFallbackProvider 接口來實現，ZuulFallbackProvider 默認有兩個方法，一個用來指明熔斷攔截哪個服務，一個定制返回內容。
API 網關熔斷降級
發布測試
在發布版本的時候會采用：金絲雀發布和藍綠發布。作為 API 網關可以使用路由選擇和流量切換來協助上述行為。這里以金絲雀發布為例，看看 API 網關如何做路由轉換的。
假設將 4 個服務從 V1 更新到 V2 版本，這 4 個服務的流量請求由 1 個 API 網關管理。
那么先將一臺服務與 API 網關斷開，部署 V2 版本的服務，然后 API 網關再將流量導入到 V2 版本的服務上。
這里流量的導入可以是逐步進行的，一旦 V2 版本的服務趨于穩定。再如法炮制，將其他服務替換成 V2 版本。
金絲雀發布一般先發 1 臺，或者一個小比例，例如 2% 的服務器，主要做流量驗證用，也稱為金絲雀(Canary)測試(灰度測試)。
其來歷是，曠工下礦洞前，先放一只金絲雀探查是否有毒氣，金絲雀發布由此得名。
金絲雀測試需要完善的監控設施配合，通過監控指標反饋，觀察金絲雀的健康狀況，作為后續發布或回滾的依據。
如果金絲測試通過，則把剩余的 V1 版本全部升級為 V2 版本。如果金絲雀測試失敗，則直接回退金絲雀，發布失敗。
緩存數據
我們可以在 API 網關緩存一些修改頻率不高的數據。例如：用戶信息，配置信息，通過服務定期刷新這個緩存就行了：
- 用戶請求先訪問 API 網關，如果發現有緩存信息，直接返回給用戶。
- 如果沒有發現緩存信息，回源到應用服務器獲取信息。
- 另外，有一個緩存更新服務，定期把應用服務器中的信息更新到網關本地緩存中。
日志記錄
通過 API 網關上的過濾器我們可以加入日志服務，記錄請求和返回信息。同時可以建立一個管理員的界面去監控這些數據。
日志服務簡圖
日志記錄了以后，可以做很多功能擴展。我們整理了以下幾點供大家參考：
- 報表分析：針對服務訪問情況，提供可視化展示。
- 實時查詢：了解實時關鍵信息，例如：吞吐量，并發數。在秒殺活動的時候，會特別關注。
- 異常告警：針對關鍵參數進行監控，對于統計結果支持閾值報警，對接阿里云通知中心、短信、釘釘進行告警。
- 日志投遞：將日志進行歸檔，存放到文件庫或者數據倉庫中，以便后期分析。
日志記錄衍生的功能
流行 API 網關對比
在介紹了 API 網關的功能以后，再來看看目前幾個流行的 API 網關項目?？纯此麄兏髯缘奶攸c，并且把他們做一個簡單的比較。這些網關目前都是開源的，大家可以有選擇地在項目中使用。
Kong
Kong 是 Mash ape 公司的開源項目，它是一個在 Nginx 中運行的 Lua 應用程序，并且可以通過 Lua-Nginx 模塊實現擴展。
所以，可以通過插件集合的方式定制功能，例如：HTTP 基本認證、密鑰認證、CORS(Cross-origin Resource Sharing，跨域資源共享)、TCP、UDP、日志、API 限流、請求轉發以及監控，都是目前已有的插件。
由于是基于 Nginx 的，所以可以對網關進行水平擴展，來應對大批量的網絡請求。
Kong 架構圖
Kong 主要有三個組件：
- KongServer ：基于 Nginx 的服務器，用來接收 API 請求。
- ApacheCassandra/PostgreSQL：用來存儲操作數據。
- Kongdashboard：UI 管理工具。
Traefik
Traefik 架構圖
Traefik 是 HTTP 反向代理和負載均衡器，可以輕松部署微服務，可以與現有的組件(Docker、Swarm，Kubernetes，Marathon，Consul，Etcd)做集成。
因為支持動態配置，所以它的伸縮性很好。不過它只支持 HTTP、HTTPS 和 GRPC。如果你需要 TCP 負載均衡，那么您需要選擇其他方案了。
Ambassador
Ambassador 架構圖
Ambassador 是一個基于 Envoy Proxy 構建的，Kubernetes 原生的開源微服務網關。
它在構建之初就致力于支持多個獨立的團隊，這些團隊需要為最終用戶快速發布、監控和更新服務。
Ambassador 還具有 Kubernetes Ingress 和負載均衡的能力。它支持處理 Kubernetes Ingress Controller 和負載均衡等功能，可以與 Istio 無縫集成。
Zuul
Zuul 2 結構圖
Zuul 是 Spring Cloud 全家桶中的微服務 API 網關。所有從設備或網站來的請求都會經過 Zuul 到達后端的 Netflix 應用程序。
作為一個邊界性質的應用程序，Zuul 提供了動態路由、監控、彈性負載和安全功能。包括 Zuul1 和 Zuul2 兩個版本。
介紹了幾個開源 API 網關的基本信息以后，我們從幾個維度對他們進行比較：
從開源社區活躍度來說，Kong 和 Traefik 較好;從成熟度來看，較好的是 Kong、Traefik;從架構優勢的擴展性來看，Kong 有豐富的插件，Ambassador 也有插件但不多，而 Zuul 是需要自研。
但 Zuul 由于與 Spring Cloud 集成，如果使用 Spring Cloud 的小伙伴可以考慮使用。
總結
API 網關是系統內外通訊的中介者。從定位上來說它服務 WebApp，MobileApp，合作伙伴 OpenAPI，企業內部可擴展 API，以及 IOT 設備。
從架構設計角度來說，分為 Gateway-Core(核心)、Gateway-Admin(管理)、Gateway-Monitor(監控)三部分。
API 網關需要注意的技術原理有，協議轉換，鏈式處理以及異步請求。它的應用比較廣泛，例如：負載均衡，路由選擇，流量控制，統一鑒權，熔斷降級，發布測試，緩存數據，日志記錄等。
比較流行的開源 API網關有 Kong，Traefik，Ambassador，Zuul。從使用上來說他們各有千秋，可以根據項目的情況選取。
作者：崔皓
簡介：十六年開發和架構經驗，曾擔任過惠普武漢交付中心技術專家，需求分析師，項目經理，后在創業公司擔任技術/產品經理。善于學習，樂于分享。目前專注于技術架構與研發管理。
【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】
