日韩人妻熟女中文字幕aⅴ春菜,人妻(高h),人妻蜜と1～4中文字幕月野定规

-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)求匹配的 Consumer?jack，這樣網(wǎng)關(guān)就清楚這個(gè)請(qǐng)求是?jack?發(fā)出的。如果沒有找到匹配的 Key 即可判定為非法請(qǐng)求。

JSON Web Token（JWT）?

JSON Web Token (JWT) 是一個(gè)開放的標(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)中可以通過 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 過期時(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)證通過后該請(qǐng)求才能被轉(zhuǎn)發(fā)至上游服務(wù)。

相較于前兩種策略，JWT 策略包含了過期時(shí)間選項(xiàng)，簽發(fā)的 Token 隨著時(shí)間流逝是可以過期的，但是 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 安全。常見的身份提供者有 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)通過 code 向 IdP 請(qǐng)求 Access Token 從而獲取用戶信息
網(wǎng)關(guān)向上游轉(zhuǎn)發(fā)請(qǐng)求時(shí)即可攜帶用戶信息

通過這一流程可以將認(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 安全訪問，允許正常請(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 訪問限制?

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

URI 攔截?

URI 攔截策略主要通過設(shè)置 URI 的一些規(guī)則來(lái)阻止?jié)撛诘奈ｋU(xiǎn) API 請(qǐng)求。比如一些安全攻擊通過嗅探 URI 路徑從而發(fā)現(xiàn)潛在的安全漏洞進(jìn)而攻擊。

Apache APISIX 提供了?uri-blocker?插件來(lái)提供這一能力。通過?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é)（通過電子郵件向攻擊者發(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)行按需改寫。這一類型的策略主要圍繞限流限速、熔斷、緩存、重寫等功能展開。

限流限速?

在資源有限的情況下，API 可以提供的服務(wù)能力是有一定限度的，如果調(diào)用超過了這一限制可能會(huì)使上游服務(wù)崩潰繼而引起一些連鎖反應(yīng)。限流限速可以防范這種情況的發(fā)生，另一方面也可以有效防止 API 遭受 DDOS 攻擊。

在限流限速策略中可以設(shè)置一個(gè)時(shí)間窗口和可允許最大的請(qǐng)求數(shù)量，在時(shí)間窗口內(nèi)超過這個(gè)數(shù)量的請(qǐng)求會(huì)被拒絕并返回設(shè)置的信息，直到請(qǐng)求數(shù)量低于設(shè)定的值或到下一個(gè)時(shí)間窗口后會(huì)允許繼續(xù)訪問。

請(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ù)。超過這一時(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ù)，在這期間用戶訪問的還是藍(lán)色系統(tǒng)。之后可以使用某些負(fù)載均衡策略將請(qǐng)求重定向到綠色環(huán)境中。藍(lán)色環(huán)境即可保持待機(jī)作為災(zāi)難恢復(fù)選項(xiàng)或者用作下一次更新。

APISIX 的?traffic-split?插件通過流量拆分對(duì)上述提到的兩種發(fā)布類型都進(jìn)行了很好的支持，使得業(yè)務(wù)部署更加便捷可靠。

請(qǐng)求重寫?

在現(xiàn)代微服務(wù)架構(gòu)中，尤其是服務(wù)端與服務(wù)、服務(wù)與服務(wù)之間充斥各種不同的協(xié)議，或著請(qǐng)求數(shù)據(jù)格式不統(tǒng)一，這些問題如果單獨(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è)試方法，通過在系統(tǒng)中故意引入錯(cuò)誤來(lái)確保系統(tǒng)的行為正常。通常在部署之前進(jìn)行測(cè)試以保證在生產(chǎn)環(huán)境中沒有潛在的故障。在一些混沌測(cè)試場(chǎng)景下，需要對(duì)服務(wù)注入一些錯(cuò)誤來(lái)驗(yàn)證服務(wù)的可靠性。

軟件的故障注入可以分為編譯時(shí)注入和運(yùn)行時(shí)注入。編譯時(shí)注入指在編寫軟件的過程中通過改變某些代碼或邏輯來(lái)實(shí)現(xiàn)；運(yùn)行時(shí)注入通過向正在運(yùn)行的軟件環(huán)境中設(shè)置錯(cuò)誤來(lái)測(cè)試軟件的行為。故障注入策略可以在網(wǎng)關(guān)中以運(yùn)行時(shí)注入的方式，模擬應(yīng)用網(wǎng)絡(luò)請(qǐng)求中的故障。通過在策略中設(shè)置一個(gè)比例，命中這個(gè)比例內(nèi)的請(qǐng)求會(huì)執(zhí)行設(shè)置好的故障邏輯，比如延遲時(shí)間返回，或直接返回設(shè)置的錯(cuò)誤碼和錯(cuò)誤信息給調(diào)用方。

通過這種方式可以增加軟件的適應(yīng)性，讓開發(fā)人員提前看到可能出現(xiàn)的一些錯(cuò)誤情況，在發(fā)布之前針對(duì)問題做出適應(yīng)性修改。

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

協(xié)議轉(zhuǎn)換類的策略可以做一些常見協(xié)議之間的轉(zhuǎ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)中通過系統(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)問題時(shí)可以通過分析各個(gè)組件狀態(tài)得到答案。但是在大型分布式系統(tǒng)中，各種微服務(wù)組件數(shù)量非常大，對(duì)組件一一進(jìn)行排查顯然是不現(xiàn)實(shí)的，這個(gè)時(shí)候就需要系統(tǒng)具備可觀測(cè)性。可觀測(cè)性提供了對(duì)分布式系統(tǒng)的“可見性”，當(dāng)系統(tǒng)出現(xiàn)問題時(shí)它可以提供工程師所需的控制能力，準(zhǔ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 問題；
產(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)問題時(shí)可以幫助工程師確定排查范圍和位置。

Tracing 策略可以在 API 網(wǎng)關(guān)上集成一些其他的分布式調(diào)用鏈路追蹤系統(tǒng)，收集信息并記錄。常見的服務(wù)比如 Zipkin、SkyWalking 等。通過 Tracing 策略將這些服務(wù)集成到 API 網(wǎng)關(guān)中，實(shí)現(xiàn)在網(wǎng)關(guān)上數(shù)據(jù)收集和與這些服務(wù)之間的通信，可以幫助工程師解決諸如這個(gè)請(qǐng)求接觸了什么服務(wù)以及引入了多少延遲等問題。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)查詢和可視化。通過對(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)警等能力。這一策略通過 API 網(wǎng)關(guān)中的各種接口收集網(wǎng)關(guān)運(yùn)行過程中的數(shù)據(jù)，并將數(shù)據(jù)上報(bào)至上述服務(wù)中。通過將這些數(shù)據(jù)可視化后開發(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)問題時(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)求記錄，通過這些記錄工程師可以掌握 API 訪問情況，及時(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í)可以作為排查問題的重要依據(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)策略決定。

文章來(lái)源：In depth analysis of API gateway policies: authentication, authorization, security, traffic processing, and observability