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

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

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

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

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

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

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

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

認(rèn)證和授權(quán)策略

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

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

Basic Auth

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

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

Key Auth

Key Auth 策略通過在 API 中添加 Key 來限制 API 調(diào)用，并識別請求攜帶的 Key 來進(jìn)行訪問資源的控制。只有攜帶了正確的 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)關(guān)從請求中讀取 Key 值的位置和字段名稱。默認(rèn)的配置位置為header，字段名稱為apikey， 那么正確的請求這個路由的示例為：curl -i http://127.0.0.1:8080/hello -H 'apikey: jack-key'APISIX 在收到這一請求后會從請求中解析出 Key，然后從配置的所有 Key 中找到和這個請求匹配的 Consumerjack，這樣網(wǎng)關(guān)就清楚這個請求是jack發(fā)出的。如果沒有找到匹配的 Key 即可判定為非法請求。

JSON Web Token

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

OpenID Connect

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

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

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

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

IdP 重定向到網(wǎng)關(guān)并攜帶認(rèn)證 code

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

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

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

安全策略

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

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

IP 訪問限制

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

URI 攔截

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

CORS

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

CSRF

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

流量處理策略

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

限流限速

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

熔斷

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

流量拆分

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

請求重寫

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

故障注入

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

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

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

可觀測性策略

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

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

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

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

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

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

Tracing

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

Metrics

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

Logging

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

總結(jié)

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