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

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

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

請(qǐng)求是否合法，比如是否來(lái)自被禁止訪問(wèn)的用戶列表中；

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

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

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

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

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

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

比如說(shuō)一位乘客前往車站出行，進(jìn)入車站之前會(huì)使用身份證進(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ù)的所有請(qǐng)求都是經(jīng)過(guò)認(rèn)證和授權(quán)的，不會(huì)出現(xiàn)非法請(qǐng)求。并且訪問(wèn)的都是權(quán)限范圍內(nèi)的資源。比較常用的策略有下面幾種：

Basic Auth

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

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

Key Auth

Key Auth 策略通過(guò)在 API 中添加 Key 來(lái)限制 API 調(diào)用，并識(shí)別請(qǐng)求攜帶的 Key 來(lái)進(jìn)行訪問(wèn)資源的控制。只有攜帶了正確的 Key 之后的請(qǐng)求才能正常訪問(wèn)，可以在請(qǐng)求頭中或 Query 中攜帶。通常還可以通過(guò)這個(gè) Key 來(lái)區(qū)分不同的 API 調(diào)用方，從而可以針對(duì)不同的調(diào)用方實(shí)施不同的其他策略或資源控制。同樣的 Key 在 HTTP 中是明文傳輸?shù)模_保請(qǐng)求使用了 HTTPS 以保證安全。 以 APISIX 的 key-auth 插件為例，插件需要通過(guò) Admin API 創(chuàng)建一個(gè)具有唯一 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" } } }'這一請(qǐng)求創(chuàng)建了一個(gè)名字為jack的 Consumer，它的 key 值為jack-key。在路由中啟用插件時(shí)需要配置網(wǎng)關(guān)從請(qǐng)求中讀取 Key 值的位置和字段名稱。默認(rèn)的配置位置為header，字段名稱為apikey， 那么正確的請(qǐng)求這個(gè)路由的示例為：curl -i http://127.0.0.1:8080/hello -H 'apikey: jack-key'APISIX 在收到這一請(qǐng)求后會(huì)從請(qǐng)求中解析出 Key，然后從配置的所有 Key 中找到和這個(gè)請(qǐng)求匹配的 Consumerjack，這樣網(wǎng)關(guān)就清楚這個(gè)請(qǐng)求是jack發(fā)出的。如果沒(méi)有找到匹配的 Key 即可判定為非法請(qǐng)求。

JSON Web Token

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

OpenID Connect

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

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

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

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

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

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

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

通過(guò)這一流程可以將認(rèn)證和鑒權(quán)從業(yè)務(wù)中獨(dú)立出來(lái)放置于網(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èn)，允許正常請(qǐng)求被網(wǎng)關(guān)轉(zhuǎn)發(fā)并在網(wǎng)關(guān)上攔截非法請(qǐng)求。根據(jù) OWASP API Security Project，在 API 的調(diào)用者中存在著大量可能的威脅和攻擊。使用 API 網(wǎng)關(guān)安全策略可以對(duì)所有的 API 請(qǐng)求進(jìn)行安全驗(yàn)證，在 API 免于遭受這些安全威脅上起到了重要作用。

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

IP 訪問(wèn)限制

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

URI 攔截

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

CORS

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

CSRF

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

流量處理策略

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

限流限速

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

熔斷

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

流量拆分

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

請(qǐng)求重寫

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

故障注入

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

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

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

可觀測(cè)性策略

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

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

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

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

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

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

Tracing

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

Metrics

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

Logging

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

總結(jié)

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