近些年隨著云原生和微服務架構(gòu)的日趨發(fā)展，API 網(wǎng)關以流量入口的角色在技術架構(gòu)中扮演著越來越重要的作用。API 網(wǎng)關主要負責接收所有請求的流量并進行處理轉(zhuǎn)發(fā)至上游服務，API 網(wǎng)關的策略決定了 API 網(wǎng)關處理這些流量的邏輯與規(guī)則，直接決定了實際的業(yè)務流量行為。

什么是 API 網(wǎng)關策略？

API 網(wǎng)關一般位于所有的上游服務之前，當用戶向服務發(fā)送請求后請求會先到 API 網(wǎng)關，API 網(wǎng)關接收到請求之后一般會判斷幾件事情：

請求是否合法，比如是否來自被禁止訪問的用戶列表中；

這個請求是否通過認證，訪問的內(nèi)容是否是經(jīng)過授權的；

請求是否觸發(fā)了某些限制規(guī)則，比如限流限速等；

請求應該轉(zhuǎn)發(fā)給哪個上游服務。

經(jīng)過這一系列步驟，這個請求要么不符合預設的規(guī)則被拒絕，要么經(jīng)過了層層處理正確到達指定的上游服務中。我們將這些處理規(guī)則稱之為 API 網(wǎng)關的策略。這些規(guī)則由網(wǎng)關的管理員在網(wǎng)關運行時不斷添加至網(wǎng)關中，網(wǎng)關接受這些規(guī)則并根據(jù)這些規(guī)則作出正確的流量處理行為。 以 API 網(wǎng)關 Apache APISIX 為例，APISIX 的配置信息有兩種：網(wǎng)關啟動用的配置文件，比如config.yaml，這個文件決定了網(wǎng)關正常啟動所必須的一些配置。另外在運行時管理員可以通過 Admin API 動態(tài)創(chuàng)建各種規(guī)則與配置，比如 Route、Consumer、Plugin 等等。API 網(wǎng)關的策略就是管理員通過 Admin API 動態(tài)創(chuàng)建的各種規(guī)則與配置。 本文不再額外描述基本常用場景，而是針對認證授權、安全、流量處理與可觀測性這四類 API 網(wǎng)關中重要的場景進行闡述，介紹每種場景下包含的一些 API 網(wǎng)關策略的作用以及使用方法。

認證和授權策略

認證可以確認 API 調(diào)用者的身份，授權主要限制調(diào)用者僅能訪問權限內(nèi)的資源。

比如說一位乘客前往車站出行，進入車站之前會使用身份證進行 “認證” 確認身份，在進入車站后出示車票，經(jīng)工作人員確認后被 “授權” 進入某班列車。 認證授權類策略主要目的是保證網(wǎng)關轉(zhuǎn)發(fā)到上游服務的所有請求都是經(jīng)過認證和授權的，不會出現(xiàn)非法請求。并且訪問的都是權限范圍內(nèi)的資源。比較常用的策略有下面幾種：

Basic Auth

基本訪問認證策略，這是一種最簡單的訪問控制技術。一般由用戶的 HTTP 代理在發(fā)出請求時攜帶用于認證的請求頭，一般為：Authorization: Basic ，credentials 中即包含了用戶認證需要的用戶 ID 和密碼，使用:隔離。這種方式不需要登陸頁面、cookie 等繁雜的設置，僅僅基于請求頭中的簡單憑據(jù)信息進行認證，一般為用戶名和密碼，配置使用起來較為簡單。 攜帶基本認證的cURL請求的示例如下，用戶名為username，密碼為password：

curl -i -u 'username:password' http://127.0.0.1:8080/hello需要注意的是credentials中的信息在傳輸過程中并不會被加密，僅僅做 Base64 編碼，所以通常需要和 HTTPS 一起使用來保證密碼的安全性。 在網(wǎng)關中實施這一策略后，未攜帶憑據(jù)的請求將無法正常通過網(wǎng)關轉(zhuǎn)發(fā)，除非在請求中攜帶了正確的認證信息，實現(xiàn)了最小成本下為 API 添加了訪問驗證。

Key Auth

Key Auth 策略通過在 API 中添加 Key 來限制 API 調(diào)用，并識別請求攜帶的 Key 來進行訪問資源的控制。只有攜帶了正確的 Key 之后的請求才能正常訪問，可以在請求頭中或 Query 中攜帶。通常還可以通過這個 Key 來區(qū)分不同的 API 調(diào)用方，從而可以針對不同的調(diào)用方實施不同的其他策略或資源控制。同樣的 Key 在 HTTP 中是明文傳輸?shù)?，確保請求使用了 HTTPS 以保證安全。 以 APISIX 的 key-auth 插件為例，插件需要通過 Admin API 創(chuàng)建一個具有唯一 key 值的 Consumer：

curl http://127.0.0.1:9180/apisix/admin/consumers -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d ' { "username": "jack", "plugins": { "key-auth": { "key": "jack-key" } } }'這一請求創(chuàng)建了一個名字為jack的 Consumer，它的 key 值為jack-key。在路由中啟用插件時需要配置網(wǎng)關從請求中讀取 Key 值的位置和字段名稱。默認的配置位置為header，字段名稱為apikey， 那么正確的請求這個路由的示例為：curl -i http://127.0.0.1:8080/hello -H 'apikey: jack-key'APISIX 在收到這一請求后會從請求中解析出 Key，然后從配置的所有 Key 中找到和這個請求匹配的 Consumerjack，這樣網(wǎng)關就清楚這個請求是jack發(fā)出的。如果沒有找到匹配的 Key 即可判定為非法請求。

JSON Web Token

JSON Web Token (JWT) 是一個開放的標準，它定義了一種以 json 對象形式在各方之間安全傳遞信息的方式。JWT 策略可以集認證和授權于一身，在用戶取得授權后會向用戶傳輸一個 JWT Token，在后面的所有請求中調(diào)用方都會攜帶這個 Token 從而保證請求是被授權的。 在 API 網(wǎng)關中可以通過 JWT 策略將 JWT 身份驗證能力添加到網(wǎng)關中，從而把這層邏輯從業(yè)務中抽離出來，業(yè)務實現(xiàn)者可以更加專注實現(xiàn)業(yè)務邏輯。以 APISIX 的 jwt-auth 插件為例，插件需要在 Consumer 中啟用并配置唯一的 Key、加密用的公私鑰、加密算法、Token 過期時間等。同時還需要在路由中啟用這一插件并配置網(wǎng)關讀取 Token 的位置和字段，比如 header、query、cookie 等。該插件會在 API 網(wǎng)關中添加一個 API 用于簽發(fā) Token。在發(fā)送請求之前需要請求簽發(fā) token 的 API 獲得 Token，發(fā)送請求時需要根據(jù)配置信息在指定的位置上攜帶這一 Token。在請求到達網(wǎng)關后網(wǎng)關會按照配置信息從請求的指定位置讀取 Token 并驗證 Token 的有效性，驗證通過后該請求才能被轉(zhuǎn)發(fā)至上游服務。 相較于前兩種策略，JWT 策略包含了過期時間選項，簽發(fā)的 Token 隨著時間流逝是可以過期的，但是 Basic Auth 和 Key Auth 的有效期是永久的，除非服務端更換了密碼或 Key。除此之外 JWT 策略可以在多個服務之間公用，尤其是針對單點登錄場景下很有用。

OpenID Connect

OpenID Connect 是建立在 OAuth2.0 協(xié)議之上的身份認證方法，為應用的授權提供了比較完整的方案，API 網(wǎng)關中的 OpenID Connect 策略將允許上游服務從身份提供者（IdP）中獲取請求中的用戶信息，從而保護 API 安全。常見的身份提供者有 Keycloak、Ory Hydra、Okta、Auth0 等等。以 Apache APISIX 為例網(wǎng)關中的 OpenID Connect 策略工作流程如下：

客戶端向網(wǎng)關發(fā)出請求

網(wǎng)關收到請求后向 IdP 發(fā)出認證請求

用戶將被重定向到 IdP 提供的頁面完成登陸認證

IdP 重定向到網(wǎng)關并攜帶認證 code

網(wǎng)關通過 code 向 IdP 請求 Access Token 從而獲取用戶信息

網(wǎng)關向上游轉(zhuǎn)發(fā)請求時即可攜帶用戶信息

通過這一流程可以將認證和鑒權從業(yè)務中獨立出來放置于網(wǎng)關中解決，使架構(gòu)更加清晰。關于更多 APISIX 的認證授權方法可以參考 API Gateway Authentication。

安全策略

API 網(wǎng)關安全策略像門衛(wèi)一樣保證 API 安全訪問，允許正常請求被網(wǎng)關轉(zhuǎn)發(fā)并在網(wǎng)關上攔截非法請求。根據(jù) OWASP API Security Project，在 API 的調(diào)用者中存在著大量可能的威脅和攻擊。使用 API 網(wǎng)關安全策略可以對所有的 API 請求進行安全驗證，在 API 免于遭受這些安全威脅上起到了重要作用。

以下是幾種比較重要的 API 網(wǎng)關安全策略。

IP 訪問限制

IP 限制策略通過將某些 IP 或 CIDR 設置為白名單或者黑名單來限制某些客戶端對 API 的訪問，確保重要數(shù)據(jù)不會被隨意訪問。正確配置這一策略很大程度上提高了 API 的安全性，實現(xiàn)了更高的 API 安全治理。

URI 攔截

URI 攔截策略主要通過設置 URI 的一些規(guī)則來阻止?jié)撛诘奈ｋU API 請求。比如一些安全攻擊通過嗅探 URI 路徑從而發(fā)現(xiàn)潛在的安全漏洞進而攻擊。 Apache APISIX 提供了uri-blocker插件來提供這一能力。通過 uri-blocker 插件可以設置一些正則規(guī)則，如果請求命中規(guī)則就可以攔截當前用戶的請求，例如設置root.exe、admin，這一插件就可以阻止*/root.exe和*/admin這種類似的請求，進一步保護 API 安全。

CORS

CORS 即瀏覽器針對跨域請求作出的安全策略。一般情況下在瀏覽器中發(fā)出 xhr 請求前瀏覽器會驗證請求地址和當前地址是否為同一域，如果在同一域下請求可以直接發(fā)出，否則瀏覽器會先出發(fā)一個 OPTION 類型的跨域預檢請求，然后在該請求的響應頭中會有 CORS 相關的設置，例如允許跨域請求的方法、允許請求攜帶的憑據(jù)等。瀏覽器會根據(jù)這些信息決定是否發(fā)出正式的請求，詳細可以參考 CORS。 一般情況下包含 CORS 設置的響應是由后端服務設置的，但是如果服務數(shù)量很多，在網(wǎng)關層面針對不同服務統(tǒng)一處理會更加便捷安全。CORS 策略可以在不同的 API 上設置不同的跨域解決策略，上游服務無需再處理這些邏輯。

CSRF

CSRF 即跨站請求偽造攻擊，通常情況下會使終端用戶在他們已經(jīng)認證的站點中執(zhí)行非自愿的動作。這種攻擊通常伴隨著社會工程學（通過電子郵件向攻擊者發(fā)送攻擊鏈接），當用戶點擊這一鏈接后利用攻擊者在網(wǎng)站中已登陸認證的身份執(zhí)行攻擊操作。在網(wǎng)站看來因為用戶已經(jīng)登陸，所以所做的任何操作都是正常的。 通常網(wǎng)站的后端服務需要添加額外的中間件處理這部分邏輯，防范的方法也都有統(tǒng)一的標準。使用 CSRF 策略可以為網(wǎng)關提供防范這一攻擊的能力，在網(wǎng)關層統(tǒng)一做 CSRF 安全處理，簡化上游服務邏輯復雜度。

流量處理策略

流量處理策略主要保證 API 網(wǎng)關進行流量轉(zhuǎn)發(fā)的上游負載都在健康范圍內(nèi)，同時在請求轉(zhuǎn)發(fā)前或者返回給調(diào)用者前對請求進行按需改寫。這一類型的策略主要圍繞限流限速、熔斷、緩存、重寫等功能展開。

限流限速

在資源有限的情況下，API 可以提供的服務能力是有一定限度的，如果調(diào)用超過了這一限制可能會使上游服務崩潰繼而引起一些連鎖反應。限流限速可以防范這種情況的發(fā)生，另一方面也可以有效防止 API 遭受 DDOS 攻擊。 在限流限速策略中可以設置一個時間窗口和可允許最大的請求數(shù)量，在時間窗口內(nèi)超過這個數(shù)量的請求會被拒絕并返回設置的信息，直到請求數(shù)量低于設定的值或到下一個時間窗口后會允許繼續(xù)訪問。 請求計數(shù)的憑據(jù)可以設置為請求中的變量或著某一個請求頭等，例如根據(jù)不同的 IP 設置相應的限速策略。實現(xiàn)更加靈活的控制。

熔斷

API 熔斷策略可以為上游服務提供熔斷能力，使用這一策略時需要設置上游服務健康和不健康的狀態(tài)碼，用于網(wǎng)關判斷上游服務狀態(tài)。另外還需要設置觸發(fā)熔斷或者恢復健康的請求次數(shù)，連續(xù)達到這一次數(shù)后即判定為對應的狀態(tài)。當上游服務連續(xù)向網(wǎng)關返回一定次數(shù)的不健康狀態(tài)碼后，網(wǎng)關就會熔斷該上游服務一段時間，在這段時間內(nèi)不再向該上游轉(zhuǎn)發(fā)請求而是由網(wǎng)關直接返回錯誤?？梢苑乐股嫌畏找驗殄e誤后繼續(xù)接收請求出現(xiàn) “雪崩”，保護業(yè)務服務。超過這一時間后網(wǎng)關會再次嘗試向上游轉(zhuǎn)發(fā)請求，如果還是返回不健康的狀態(tài)碼，網(wǎng)關就會繼續(xù)熔斷更長的時間（加倍）。直到轉(zhuǎn)發(fā)請求后上游連續(xù)返回了一定次數(shù)的健康狀態(tài)碼，則網(wǎng)關認為上游服務恢復健康，后續(xù)會繼續(xù)往該上游節(jié)點轉(zhuǎn)發(fā)流量。 在這個策略中還需要設置當不健康后需要返回的狀態(tài)碼和信息，當上游服務不健康后請求在網(wǎng)關層面直接返回，保護業(yè)務服務穩(wěn)定。

流量拆分

流量拆分策略可以動態(tài)控制將流量按比例轉(zhuǎn)發(fā)給不同的上游服務，這在灰度發(fā)布或藍綠發(fā)布中非常有用。 灰度發(fā)布又名金絲雀發(fā)布，當服務發(fā)布新功能時可以僅讓一部分請求使用新的服務，另一部分仍然停留在舊的服務中。如果新服務保持穩(wěn)定，則可以增加比例逐步將所有請求轉(zhuǎn)移到新的服務中，直至比例完全切換，完成服務升級。 藍綠發(fā)布則是另一種發(fā)布模式，可以做到在用戶使用的高峰期進行發(fā)布，同時不會中斷服務。服務的舊版本和新版本會同時共存。一般會將生產(chǎn)環(huán)境（藍色）復制到一個相同但是單獨的容器中（綠色）。在綠色環(huán)境中發(fā)布新的更新，之后將綠色和藍色一同發(fā)布至生產(chǎn)環(huán)境。之后就可以在綠色環(huán)境中進行測試和修復，在這期間用戶訪問的還是藍色系統(tǒng)。之后可以使用某些負載均衡策略將請求重定向到綠色環(huán)境中。藍色環(huán)境即可保持待機作為災難恢復選項或者用作下一次更新。 APISIX 的 traffic-split 插件通過流量拆分對上述提到的兩種發(fā)布類型都進行了很好的支持，使得業(yè)務部署更加便捷可靠。

請求重寫

在現(xiàn)代微服務架構(gòu)中，尤其是服務端與服務、服務與服務之間充斥各種不同的協(xié)議，或著請求數(shù)據(jù)格式不統(tǒng)一，這些問題如果單獨在各自服務之間實現(xiàn)轉(zhuǎn)換處理會產(chǎn)生很多冗余的邏輯代碼并且難以管理。一些請求重寫策略可以處理一些協(xié)議轉(zhuǎn)換、請求體改寫等邏輯。 APISIX 提供了 response-rewrite 插件可以用來修改上游服務返回的 Body 或者 Header 信息內(nèi)容，支持添加或者刪除響應頭，設置規(guī)則修改響應體等。這在設置 CORS 響應頭實現(xiàn)跨域請求設置或者設置 Location 實現(xiàn)重定向等場景中很有用。 另一方面，對于請求重寫 APISIX 則提供了 proxy-rewrite 插件也可以處理代理到上游服務的請求內(nèi)容，可以對請求的 URI、方法、請求頭等重寫，在很多場景下為業(yè)務處理提供了便捷。

故障注入

故障注入測試是一種軟件測試方法，通過在系統(tǒng)中故意引入錯誤來確保系統(tǒng)的行為正常。通常在部署之前進行測試以保證在生產(chǎn)環(huán)境中沒有潛在的故障。在一些混沌測試場景下，需要對服務注入一些錯誤來驗證服務的可靠性。 軟件的故障注入可以分為編譯時注入和運行時注入。編譯時注入指在編寫軟件的過程中通過改變某些代碼或邏輯來實現(xiàn)；運行時注入通過向正在運行的軟件環(huán)境中設置錯誤來測試軟件的行為。故障注入策略可以在網(wǎng)關中以運行時注入的方式，模擬應用網(wǎng)絡請求中的故障。通過在策略中設置一個比例，命中這個比例內(nèi)的請求會執(zhí)行設置好的故障邏輯，比如延遲時間返回，或直接返回設置的錯誤碼和錯誤信息給調(diào)用方。 通過這種方式可以增加軟件的適應性，讓開發(fā)人員提前看到可能出現(xiàn)的一些錯誤情況，在發(fā)布之前針對問題做出適應性修改。

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

協(xié)議轉(zhuǎn)換類的策略可以做一些常見協(xié)議之間的轉(zhuǎn)換。比如常見的 HTTP 請求和 gRPC 之間的轉(zhuǎn)換。Apache APISIX 提供了 grpc-transcode 插件可以實現(xiàn)在網(wǎng)關接收到 HTTP 請求之后，將請求轉(zhuǎn)碼并轉(zhuǎn)發(fā)給 gRPC 類型的服務，接收到響應后以 HTTP 的格式返回給客戶端。這樣客戶端無需關注上游 gRPC 的類型，只處理 HTTP 即可。

可觀測性策略

可觀測性指在一個系統(tǒng)中通過系統(tǒng)的輸出數(shù)據(jù)來衡量這個系統(tǒng)運行狀態(tài)的能力。在一些簡單的系統(tǒng)中，因為系統(tǒng)組件數(shù)量相對較少，出現(xiàn)問題時可以通過分析各個組件狀態(tài)得到答案。但是在大型分布式系統(tǒng)中，各種微服務組件數(shù)量非常大，對組件一一進行排查顯然是不現(xiàn)實的，這個時候就需要系統(tǒng)具備可觀測性。可觀測性提供了對分布式系統(tǒng)的 “可見性”，當系統(tǒng)出現(xiàn)問題時它可以提供工程師所需的控制能力，準確定位問題。

可觀測性的數(shù)據(jù)收集可以在應用程序組件內(nèi)實現(xiàn)，也可以在其他位置實現(xiàn)。API 網(wǎng)關作為所有流量的入口，在 API 網(wǎng)關中實現(xiàn)系統(tǒng)的可觀測性，可以清晰反映出系統(tǒng) API 的使用情況。API 網(wǎng)關的可觀測性策略可以幫助到公司的每個團隊：

工程師團隊可以監(jiān)控并解決 API 問題；

產(chǎn)品團隊可以了解 API 的使用情況以挖掘背后的商業(yè)價值；

銷售和增長團隊可以監(jiān)控 API 使用情況，觀察商業(yè)機會并確保 API 提供正確的數(shù)據(jù)。

可觀測性策略根據(jù)輸出的數(shù)據(jù)類型一般分為三類：Tracing，Metrics 和 Logging。

Tracing

在大型分布式系統(tǒng)中服務之間的調(diào)用關系錯綜復雜，Tracing（鏈路追蹤）可以在分布式應用中追蹤完整的調(diào)用鏈路、應用之間的依賴分析以及請求統(tǒng)計等內(nèi)容。在系統(tǒng)出現(xiàn)問題時可以幫助工程師確定排查范圍和位置。 Tracing 策略可以在 API 網(wǎng)關上集成一些其他的分布式調(diào)用鏈路追蹤系統(tǒng)，收集信息并記錄。常見的服務比如 Zipkin、SkyWalking 等。通過 Tracing 策略將這些服務集成到 API 網(wǎng)關中，實現(xiàn)在網(wǎng)關上數(shù)據(jù)收集和與這些服務之間的通信，可以幫助工程師解決諸如這個請求接觸了什么服務以及引入了多少延遲等問題。Tracing 策略使工程師能夠進一步確認在特定的會話或相關的 API 調(diào)用中要看哪些日志，確認排查范圍。

Metrics

Metrics 指在服務運行期間收集到的一個時間間隔內(nèi)軟件自己的各種觀測數(shù)據(jù)，這些數(shù)據(jù)默認是結(jié)構(gòu)化的，可以更好地實現(xiàn)查詢和可視化。通過對這些數(shù)據(jù)分析可以掌握系統(tǒng)當下的運行狀態(tài)和行為。 Metrics 策略可以在 API 網(wǎng)關中集成 Prometheus 或 Datadog 這一類服務，為系統(tǒng)提供監(jiān)控、報警等能力。這一策略通過 API 網(wǎng)關中的各種接口收集網(wǎng)關運行過程中的數(shù)據(jù)，并將數(shù)據(jù)上報至上述服務中。通過將這些數(shù)據(jù)可視化后開發(fā)者可以清晰看到網(wǎng)關的運行狀態(tài)，API 請求的統(tǒng)計信息等數(shù)據(jù)統(tǒng)計圖。

Logging

日志是在某個特定時間系統(tǒng)事件的文本記錄，當系統(tǒng)出現(xiàn)問題時日志是首要排查的地方。當服務出現(xiàn)一些意外情況時工程師依賴日志內(nèi)容查看系統(tǒng) “發(fā)生了什么” 從而找出對應的解決方法。日志內(nèi)容一般分為兩類：API 請求日志和網(wǎng)關自身的運行日志。API 請求日志記錄了 API 網(wǎng)關在運行期間所有的 API 請求記錄，通過這些記錄工程師可以掌握 API 訪問情況，及時發(fā)現(xiàn)并排查異常請求。網(wǎng)關自身的運行日志則包含了網(wǎng)關在工作期間發(fā)生的所有事件的記錄，當 API 網(wǎng)關自身出現(xiàn)異常時可以作為排查問題的重要依據(jù)。 Logging 策略可以將 API 網(wǎng)關中的日志存儲在服務器磁盤中或是推送到一些其他的日志服務器中，比如 HTTP 日志服務器、TCP 日志服務器、UDP 日志服務器等，或者是其他的日志系統(tǒng)比如 Apache Kafka、Apache RocketMQ、Clickhouse 等。

總結(jié)

這篇文章介紹了什么是 API 網(wǎng)關策略，并針對認證授權、安全、流量處理與可觀測性這四類 API 網(wǎng)關中常用的策略進行描述。API 網(wǎng)關在所有上游服務之前接收請求的流量，控制一個請求是否要轉(zhuǎn)發(fā)以及如何進行轉(zhuǎn)發(fā)，對不安全的、未授權的請求直接拒絕或進行限制，這些行為都可以由 API 網(wǎng)關策略決定。