1 - 由來
應用編程接口（Application Programming Interface，簡稱：API），就是軟件系統不同組成部分銜接的約定。
隨着 API 的整體趨勢發展， 架構也隨之變化：從最原始的“傳輸協議通訊” -> “簡單的接口集成” -> “消息中間件” -> “標準 REST”， API 的發展更趨向於簡潔， 集成，規範化。
隨着微服務的流行，採用微服務後，所有的服務都變成了一個個細小的API，與之帶來了API管理的一些問題：
- 如何有效地管理服務API？
- API認證授權如何實現？
- 如何實現服務的負載均衡，熔斷，灰度發佈，限流流控？
在微服務的應用程序中，客戶端和微服務之間的交互，也存在着挑戰：
- 微服務提供的 API 粒度通常與客戶端的需求不同，微服務一般提供細粒度的 API，也就是說客戶端需要與多個服務進行交互。
- 不同的客戶端需要不同的數據，不同類型客戶端的網絡性能不同。
- 服務的劃分可能會隨時間而變化，因此需要對客戶端隱藏細節。
API 網關作爲微服務整體架構的重要組件，針對性地解決了如何合理地治理服務API的問題。
抽象了微服務中都需要的公共功能，同時提供了客戶端負載均衡，服務自動熔斷，灰度發佈，統一認證，限流流控，日誌統計等豐富的功能。
2 - 定義與特徵
- 是一個服務器，是系統的唯一入口
- 封裝了系統內部架構，所有的客戶端和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能
- 爲每個客戶端提供REST/HTTP方式訪問的定製API
- 服務端通過API-Gateway註冊和管理服務
- 承擔身份驗證、監控、負載均衡、緩存、流控、反向代理、健康檢查等其它職責
更多的功能
- 對接Prometheus、Zipkin等統計、監控組件
- 對接Auth0、okta等身份認證提供商
- 支持多雲和混合雲的架構，與雲廠商無關，動態地切換和分發
3 - 一些優點
API Gateway做爲系統統一入口，實現了對各個微服務間的整合，同時又做到了對客戶端友好，屏蔽系統的複雜性和差異性，讓 API請求更安全、更高效的得到處理。
- 可以與微服務註冊中心連接，實現微服務無感知動態擴容。
- 對於無法訪問的服務，可以做到自動熔斷，無需人工參與。
- 可以方便的實現藍綠部署，金絲雀發佈或A/B發佈。
- 做爲系統統一入口，可以將各個微服務公共功能放在API Gateway中實現，以儘可能減少各服務的職責。
- 幫助實現客戶端的負載均衡策略。
- 雲原生友好，架構輕巧，便於容器化
4 - 全生命週期管理
API 的全生命週期管理：除了反向代理、負載均衡、限流限速的插件外，還包括了 API 的設計、文檔以及測試等，也就是說，從項目設計到測試上線，所有的東西都在整個 API 網關的功能範疇內。
5 - 對比
閉源的商業API網關產品，功能都很完善，覆蓋了API的設計、多語言SDK、文檔、測試和發佈等全生命週期管理，並且提供SaaS服務，有些還與公有云做了集成，使用起來非常方便。
但同時也存在“平臺鎖定”和無法二次開發的問題。
因爲一旦使用了“閉源”的方案，就很難平滑和低成本地遷移到其他平臺，並且只能依靠廠商來定製開發需求。
因此一般的選型原則：雲原生友好的、高性能的、開源的 API 網關。
6 - 參考信息
- 雲原生軟件基金會全景圖CNCF： https://landscape.cncf.io/
- https://segmentfault.com/a/1190000020303778