1. 背景

API網(wǎng)關 并非一個新興的概念，在十幾年前就已經(jīng)存在，它的作用主要是作為流量的入口放钦，統(tǒng)一的處理和業(yè)務相關的請求，讓請求更加安全各薇、快速和準確的得到處理。是所有流量請求響應出入流量的必經(jīng)之路，它除了可以做最基礎的反向代理之外峭判，還可以處理通用的公共服務邏輯开缎，如負載均衡、灰度發(fā)布林螃、限流熔斷奕删、統(tǒng)一認證授權、可觀測性疗认、動態(tài)路由完残、協(xié)議轉(zhuǎn)換、服務編排横漏、流量鏡像谨设、健康檢查、監(jiān)控報警绊茧、安全防御等铝宵。以下為 API網(wǎng)關 常見的具體的特性，雖然開源領域網(wǎng)關并不都全部滿足华畏，但是這些都可以納入網(wǎng)關上來實現(xiàn)的。它有以下傳統(tǒng)的功能：

微服務網(wǎng)關

• 反向代理和負載均衡尊蚁，這和 Nginx 的定位是一致的亡笑；即當服務器負載上升時候，網(wǎng)關需要對系統(tǒng)資源進行容量評估横朋，適當增加服務器資源仑乌，讓每個應用節(jié)點可以平均處理請求，一般使用的負載策略有輪詢琴锭、IP哈希晰甚、隨機分發(fā)、標記權重等
• 動態(tài)上游决帖、動態(tài) SSL 證書和動態(tài)限流限速等運行時的動態(tài)功能厕九，這是開源版本 Nginx 并不具備的功能；
• 上游的主動和被動健康檢查地回，以及服務熔斷扁远；在實際生產(chǎn)中發(fā)現(xiàn)某應用系統(tǒng)不健康或者處理超定義的上限，為了保護整個服務鏈刻像，主動觸發(fā)限流現(xiàn)頻和熔斷機制畅买，引導請求到預定義的處理方式，并產(chǎn)生告警信息细睡，避免因服務不可用進一步造成整個服務鏈發(fā)生雪崩
• 在 API網(wǎng)關 的基礎之上進行擴展谷羞，成為全生命周期的 API 管理平臺。

在最近幾年溜徙，隨著微服務架構的結構變遷湃缎，服務之間的流量也開始爆發(fā)性的增長犀填。在這種新的業(yè)務場景下，催生了 API網(wǎng)關 更多雁歌、更高級的功能：

1.1. 容器化支持

云原生友好宏浩，架構要變得輕巧，便于容器化靠瞎。

1.2. 灰度發(fā)布

相比較于傳統(tǒng)發(fā)布比庄，灰度發(fā)布可以在入口處可以設置對新功能的請求流量可按照定義分配，從而在一定時間內(nèi)在試用過程中乏盐，發(fā)現(xiàn)和解決問題佳窑，從而使得產(chǎn)品在大面積推廣過程中更加成熟。

1.3. 統(tǒng)一身份鑒權

當前很多企業(yè)的系統(tǒng)權限鑒權邏輯散落在各站點服務中父能，可以將當前基于角色的認證邏輯和對外開放平臺所使用的 OAuth 授權認證完全抽離出來神凑，統(tǒng)一挪移至網(wǎng)關。

承擔 OpenID Relying Party 的角色何吝，對接 OAuth 溉委、Okta 等身份認證提供商的服務，把流量的安全作為頭等大事來對待爱榕；

1.4. 可觀測

承接集群流量瓣喊，就需要掌握每個接入站點的流量分布情況；以及每個API接口的處理時長黔酥；響應的狀態(tài)藻三，再細分的話可以觀察到業(yè)務響應異常的分布情況；監(jiān)控往來的短信業(yè)務與郵件業(yè)務跪者，統(tǒng)一處理告警規(guī)則與策略棵帽，最終匯聚為統(tǒng)一的網(wǎng)關業(yè)務看板。對接 Prometheus渣玲、Zipkin逗概、Skywalking 等統(tǒng)計、監(jiān)控組件柜蜈；

1.5. 協(xié)議代理和轉(zhuǎn)換

支持 gRPC 代理仗谆，以及 HTTP 到 gRPC 之間的協(xié)議轉(zhuǎn)換，把用戶的 HTTP 請求轉(zhuǎn)為內(nèi)部服務的 gRPC 請求淑履；

API網(wǎng)關 除具備上述特性隶垮，還應該具備在通過運行時動態(tài)執(zhí)行用戶函數(shù)的方式來實現(xiàn) Serverless，讓網(wǎng)關的邊緣節(jié)點更加靈活秘噪；不鎖定用戶狸吞，支持混合云的部署架構；網(wǎng)關節(jié)點要狀態(tài)無關，可以隨意的擴容和縮容等蹋偏，這樣的網(wǎng)關才就可以讓用戶的服務只關心業(yè)務本身便斥，而和業(yè)務實現(xiàn)無關的功能，比如服務發(fā)現(xiàn)威始、服務熔斷枢纠、身份認證、限流限速黎棠、統(tǒng)計晋渺、性能分析等，就可以在獨立的網(wǎng)關層面來解決脓斩。從這個角度來看木西，API網(wǎng)關 既可以替代 Nginx 的所有功能，來處理南北向的流量随静，也可以完成 Istio 控制面和 Envoy 數(shù)據(jù)面的角色八千，來處理東西向的流量。

2. 如何設計微服務網(wǎng)關

上述是一些對微服務網(wǎng)關的認識燎猛，在有了明確目標和需要解決的問題恋捆，后面就是針對性選擇響應技術，這里大致提供六個關鍵性因素重绷，供參考鸠信。

功能架構

2.1. 高性能

作為集群流量入口，性能首先要保證的论寨，包括吞吐量和延遲，二者是衡量一個高性能網(wǎng)關的關鍵要素爽茴。所以性能自然要求越高越好葬凳，要滿足對性能要求最苛刻的那一個業(yè)務方的需求。

還有一點室奏，所謂高性能火焰，不一定是吞吐量和延遲達到某個固定標準，很多時候只要滿足業(yè)務方的實際需求就是高性能網(wǎng)關胧沫，在此之前昌简，沒有必要過早優(yōu)化。很多時候绒怨，網(wǎng)關的開銷只有幾毫秒纯赎，而業(yè)務本身開銷幾十毫秒，瓶頸不在網(wǎng)關南蹂。

2.2. 穩(wěn)定性

網(wǎng)關穩(wěn)定性的保證是一個同高性能一樣重要問題犬金，一般除軟件的質(zhì)量之外，更多的還是要依賴流程的控制以及針對性的技術方案，比如灰度發(fā)布晚顷、金絲雀發(fā)布之類的峰伙。但是總體來說，就是要經(jīng)歷實際生產(chǎn)上大規(guī)模该默、多場景的的業(yè)務考驗和流量驗證瞳氓。

2.3. 豐富治理能力

它作為整個集群入口，常用的治理能力如身份鑒權栓袖、限流匣摘、降級、熔斷叽赊、監(jiān)控報警/調(diào)用鏈追蹤恋沃、黑白名單、灰度發(fā)布必指、請求分發(fā)囊咏、條件路由、API管理 等塔橡。舉個例子梅割，現(xiàn)在乘坐高鐵檢票，都會對人像和證件進行匹配葛家，一人一閘户辞。網(wǎng)關也類似，被要求做越來越多的與業(yè)務邏輯無關的額外治理功能癞谒。

2.4. 可擴展性

和治理能力非常相關的一個關鍵特性就是 可擴展性 底燎，因為業(yè)務方的需求總是在無窮無盡的變，很多場景下甚至會有一些非常定制化的需求弹砚，網(wǎng)關也難以覆蓋所有需求双仍，所以 可擴展性 就非常關鍵。

• 良好的 可擴展性 可以幫助網(wǎng)關快速迭代新功能桌吃，對網(wǎng)關來說可以降低擴展新的治理能力的成本和開銷朱沃；
• 降低網(wǎng)關開發(fā)的門檻，對于具有一定技術能力的團隊茅诱，業(yè)務可以根據(jù)自身需求特點實現(xiàn)最合適的功能擴展逗物，可以提高自身的自主能力；

2.5. 可觀察

可觀察性在微服務架構當中非常重要瑟俭。因為業(yè)務不再是單體翎卓，為排障監(jiān)控帶來了新的復雜度，所以需要可觀察性的支持尔当。

• 輔助排障：日志指標也會包含業(yè)務的一些特征情況莲祸，可以幫助業(yè)務方快速定位出問題所在蹂安。
• 觀察趨勢：最后，作為流量統(tǒng)一入口锐帜，網(wǎng)關的可觀察性可以讓用戶了解到集群內(nèi)的流量現(xiàn)狀田盈、趨勢，并且形成長效的監(jiān)控告警系統(tǒng)缴阎，提前發(fā)現(xiàn)問題允瞧。
• 自證清白：實踐得來的一個經(jīng)驗是，一旦集群內(nèi)流量產(chǎn)生了一些業(yè)務層面的波動蛮拔，作為入口的微服務網(wǎng)關幾乎總是第一個被懷疑的對象述暂。明確的可觀察數(shù)據(jù)比如說日志、指標可以有說服力的證明網(wǎng)關的清白建炫；

2.6. 可視化管理

一個友好畦韭、易用的可視化管理控制臺，可以實現(xiàn)對網(wǎng)關的 路由配置肛跌、 服務管理 艺配、 監(jiān)控審計 的可視化。要求可視化管理控制臺必須滿足以下三點要求：

• 簡化操作：通過平臺產(chǎn)品的封裝衍慎，簡化網(wǎng)關的操作流程和配置過程转唉，隱藏或者減少底層技術的復雜性，降低 API 網(wǎng)關的使用門檻稳捆。
• 實現(xiàn)約束：實現(xiàn)約束赠法，通過產(chǎn)品的封裝和合理的提示，降低在使用 API 網(wǎng)關的過程中乔夯，用戶犯錯的風險砖织，讓用戶以一種更加正確的姿勢使用網(wǎng)關。
• 監(jiān)控報警可視化末荐。

3. 常見主流API網(wǎng)關

微服務 API網(wǎng)關 如此重要镶苞，所以傳統(tǒng)的 IT 巨頭在這個領域很早就都有布局，比如谷歌鞠评、CA、IBM壕鹉、紅帽剃幌、salesforce、以及 AWS晾浴、阿里云等公有云廠商负乡。這些閉源的商業(yè)產(chǎn)品，它們的功能都很完善脊凰，覆蓋了 API 的設計抖棘、多語言 SDK茂腥、文檔、測試和發(fā)布等全生命周期管理切省，并且提供 SaaS 服務最岗，有些還與公有云做了集成，使用起來非常方便朝捆，但同時也帶來兩個痛點：

3.1. 平臺鎖定

API網(wǎng)關 是業(yè)務流量的入口般渡，它不像圖片、視頻等 CDN 加速的這種非業(yè)務流量可以隨意遷移芙盘，API 網(wǎng)關上會綁定不少業(yè)務相關的邏輯驯用，一旦使用了閉源的方案，就很難平滑和低成本的遷移到其他平臺儒老。

3.2. 無法二次開發(fā)

一般的大中型企業(yè)都會有自己獨特的需求蝴乔，需要定制開發(fā)，這時候你就只能依靠廠商驮樊，而不能自己動手去做二次開發(fā)薇正。

鑒于以上這些閉源產(chǎn)品的 平臺鎖定、無法二次開發(fā) 巩剖，所以我們在產(chǎn)品選擇過程中更偏重于開源 API網(wǎng)關 铝穷， Kong 、Apigee佳魔、akana 等曙聂，此類網(wǎng)關在設計之初，帶有一定局限性鞠鲜，比如容器化支撐能力不足宁脊；因為他們是應用型網(wǎng)關，先天性的缺點就是的性能比較差贤姆，滿足不了對快速增長的流量進行處理榆苞；而同時它們的治理能力也是一塊短板。下圖從 云原生計算基金會Github 中截取的一部分霞捡。（想了解更多關于 云原生計算基金會）

云原生計算基金會-API網(wǎng)關

4. 如何選型

在使用 API網(wǎng)關 過程中坐漏，我們主要應該考慮部署和維護成本、功能是否滿足當下和未來可能出現(xiàn)會出現(xiàn)需求以及社區(qū)的支持是否豐富碧信，這將決定你的 API網(wǎng)關 是否能更好的契合自身產(chǎn)品需要赊琳。

5. 主流API網(wǎng)關對比

6. 鳴謝

Apache APISIX

感謝 APISIX 無私奉獻，也希望這些總結可以給正在為網(wǎng)關如何做的你帶來一些幫助