ProgrammableWeb?的 API 目錄自 2005 年以來(lái)一直在跟蹤外部可用的 API，這個(gè)數(shù)字在 2019 年 6 月突破了 22,000 大關(guān)。在此之前的 4 年里，發(fā)布的 API 數(shù)量增長(zhǎng)了近 60%，這表明 API 經(jīng)濟(jì)不僅增長(zhǎng)強(qiáng)勁，而且還將持續(xù)下去。

API 是許多業(yè)務(wù)的核心，能夠創(chuàng)造巨大的價(jià)值和收入。現(xiàn)在，IT 組織要想保持領(lǐng)先，就必須找到一種管理和控制 API 訪問(wèn)的方法，而且這一需求比以往任何時(shí)候都迫切。

API 管理的重要性

隨著企業(yè)開(kāi)始從單體應(yīng)用過(guò)渡到基于微服務(wù)的應(yīng)用，他們還意識(shí)到 API 不僅可以促進(jìn)高效的數(shù)字化通信，還可以成為新的收入來(lái)源。例如，Salesforce.com 有一半以上的年收入來(lái)自其 API，而 Expedia.com 有近 90% 的收入依賴(lài)于 API 經(jīng)濟(jì)。

茲事體大，企業(yè)不能容忍其 API 架構(gòu)出現(xiàn)任何閃失，他們必須要確保 API 具備出色的性能、可控性和安全性。

API 網(wǎng)關(guān) ≠ API 管理

雖然 “API 網(wǎng)關(guān)” 和 “API 管理” 這兩個(gè)詞語(yǔ)有時(shí)被互換使用，但要注意其中的區(qū)別。

API 網(wǎng)關(guān)是 API 訪問(wèn)權(quán)限的 “門(mén)衛(wèi)”，負(fù)責(zé)保護(hù)和管理 API 使用者與暴露這些 API 的應(yīng)用之間的流量。API 網(wǎng)關(guān)通常負(fù)責(zé)處理身份驗(yàn)證和授權(quán)、請(qǐng)求路由、速率限制以避免系統(tǒng)過(guò)載、防護(hù) DDoS 攻擊、卸載 SSL/TLS 流量以提高性能以及處理錯(cuò)誤或異常。

而?API 管理是指在 API 的整個(gè)生命周期內(nèi)管理 API 的過(guò)程，包括定義和發(fā)布 API、監(jiān)控 API 性能、分析使用模式以創(chuàng)造最大業(yè)務(wù)價(jià)值等。

常見(jiàn)的 API 網(wǎng)關(guān)部署模式

那么，如何才能有效交付 API 呢？

作為全球首屈一指的 API 網(wǎng)關(guān)，NGINX 交付了當(dāng)今網(wǎng)絡(luò)上超過(guò)一半的 API 流量。雖然模式?jīng)]有對(duì)錯(cuò)之分，但有一些 API 網(wǎng)關(guān)模式是最常用的，我們?cè)诖诉M(jìn)行了總結(jié)。

集中式邊緣網(wǎng)關(guān)

這是最常見(jiàn)的 API 網(wǎng)關(guān)模式，采用了傳統(tǒng)的應(yīng)用交付控制器 (ADC) 架構(gòu)。在這種模式下，網(wǎng)關(guān)幾乎可以處理所有事情，包括：

• SSL/TLS 卸載

• 身份驗(yàn)證

• 授權(quán)

• 請(qǐng)求路由

• 速率限制

• 請(qǐng)求 / 響應(yīng)操作

• Facade 路由

當(dāng)從集中治理的單體應(yīng)用暴露應(yīng)用服務(wù)時(shí)，這種方法非常合適，但對(duì)于微服務(wù)架構(gòu)或是總有頻繁更改的情況就差點(diǎn)意思了 —— 傳統(tǒng)邊緣網(wǎng)關(guān)都是針對(duì)南北向流量進(jìn)行優(yōu)化，并不能高效處理分布式微服務(wù)環(huán)境中產(chǎn)生的大量東西向流量。

雙層網(wǎng)關(guān)

隨著服務(wù)逐漸變得小型化和分散化，許多企業(yè)轉(zhuǎn)向了雙層（多層）網(wǎng)關(guān)模式，將多個(gè)網(wǎng)關(guān)的角色分離開(kāi)來(lái)。

這種方法將安全網(wǎng)關(guān)作為第一層，以管理：

• SSL/TLS 卸載

• 身份驗(yàn)證

• 集中式連接和請(qǐng)求日志記錄

• 跟蹤注入

將路由網(wǎng)關(guān)作為第二層，以處理：

• 授權(quán)

• 服務(wù)發(fā)現(xiàn)

• 負(fù)載均衡

在一些情況下，我們需要考慮分散的 service 的靈活性和功能獨(dú)立擴(kuò)展的需求。雙層網(wǎng)關(guān)模式最適合這樣的情況。但是，當(dāng)有多個(gè)團(tuán)隊(duì)管理不同的環(huán)境和應(yīng)用時(shí)，這種方法可能會(huì)帶來(lái)問(wèn)題，因?yàn)樗恢С址植际娇刂啤?/p>

微網(wǎng)關(guān)

微網(wǎng)關(guān)模式建立在雙層網(wǎng)關(guān)方法之上，為各個(gè) DevOps 團(tuán)隊(duì)提供了專(zhuān)用網(wǎng)關(guān)，這不僅可以幫助他們管理 service 之間的流量（東西向流量），而且還支持在不影響其他應(yīng)用的情況下進(jìn)行變更。

此模式在邊緣提供了以下功能：

• SSL/TLS 卸載

• 路由

• 速率限制

然后企業(yè)再為每個(gè) service 添加獨(dú)立的微網(wǎng)關(guān)，以管理：

• 負(fù)載均衡

• 服務(wù)發(fā)現(xiàn)

• 每個(gè) API 的身份驗(yàn)證

盡管微網(wǎng)關(guān)的設(shè)計(jì)初衷是與微服務(wù)協(xié)同工作，但它們也為實(shí)現(xiàn)一致性和可控性增加了阻力。每個(gè)微網(wǎng)關(guān)可能都有一組不同的策略和安全規(guī)則，并且需要整合多個(gè) service 的監(jiān)控信息和指標(biāo)。微網(wǎng)關(guān)很容易適得其反 —— 原本是為了盡量 “小”，結(jié)果卻往往需要根據(jù)業(yè)務(wù)目標(biāo)實(shí)施全量的 API 配置。

per-pod 網(wǎng)關(guān)

per-pod 網(wǎng)關(guān)模式將代理網(wǎng)關(guān)嵌入到了各個(gè) pod 或容器中，從而完善了微網(wǎng)關(guān)模式。網(wǎng)關(guān)負(fù)責(zé)管理到 pod 的入向流量，應(yīng)用了身份驗(yàn)證和速率限制等策略，然后將請(qǐng)求傳遞到本地微服務(wù)。

per-pod 網(wǎng)關(guān)模式不執(zhí)行任何路由或負(fù)載均衡，因此通常與上文提到的任一模式結(jié)合部署。具體來(lái)說(shuō)，您可能會(huì)使用 per-pod 網(wǎng)關(guān)執(zhí)行以下部分或全部功能：

• pod 中應(yīng)用的 SSL/TLS 卸載

• 跟蹤和指標(biāo)生成

• 身份驗(yàn)證

• 速率限制和隊(duì)列

• 錯(cuò)誤處理，包括斷路器式的錯(cuò)誤消息

per-pod 網(wǎng)關(guān)通常是輕量級(jí)的，并且其配置是靜態(tài)的。它僅將流量轉(zhuǎn)發(fā)到本地微服務(wù)實(shí)例，因此當(dāng)應(yīng)用拓?fù)浒l(fā)生變化時(shí)不需要進(jìn)行重新配置。如果需要更改其中一項(xiàng)策略，則可以使用新的代理配置重新部署微服務(wù) pod。

Sidecar（邊車(chē)）網(wǎng)關(guān)和 service mesh（服務(wù)網(wǎng)格）

Sidecar 網(wǎng)關(guān)模式將網(wǎng)關(guān)部署為微服務(wù)的出入向代理，這允許 service 直接進(jìn)行相互通信，sidecar 代理則負(fù)責(zé)處理和路由入站和出站的通信。

此模式使用邊緣網(wǎng)關(guān)管理：

更多學(xué)習(xí)資料盡在有軟官網(wǎng)

https://www.jiaruvip.com
https://www.jiaruvip.com/software
https://www.jiaruvip.com/hacker
https://www.jiaruvip.com/phone
https://www.jiaruvip.com/game
https://www.jiaruvip.com/technical
https://www.jiaruvip.com/news
https://www.jiaruvip.com/author