如何選擇適合你的微服務 API 網關：對比 Kong、APISIX、Trk、Apigee 和其餘網關

微服務 API 網關有什麼做用？

讓咱們先來看下微服務 API 網關的做用，下圖是一個簡要的說明：

API 網關並不是一個新興的概念，在十幾年前就已經存在了，它的做用主要是做爲流量的入口，統一的處理和業務相關的請求，讓請求更加安全、快速和準確的獲得處理。它有如下傳統的功能：

1. 反向代理和負載均衡，這和 Nginx 的定位和功能是一致的；
2. 動態上游、動態 SSL 證書和動態限流限速等運行時的動態功能，這是開源版本 Nginx 並不具有的功能；
3. 上游的主動和被動健康檢查，以及服務熔斷；
4. 在 API 網關的基礎之上進行擴展，成爲全生命週期的 API 管理平臺。

在最近幾年，業務相關的流量，再也不僅僅是由 PC 客戶端和瀏覽器發起，更多的來自手機、IoT 設備等，將來隨着 5G 的普及，這些流量會愈來愈多，同時，隨着微服務架構的結構變遷，服務之間的流量也開始爆發性的增加。在這種新的業務場景下，催生了API 網關更多、更高級的功能：

1. 雲原生友好，架構要變得輕巧，便於容器化；
2. 對接 Prometheus、Zipkin、Skywalking 等統計、監控組件；
3. 支持 gRPC 代理，以及 http 到 gRPC 之間的協議轉換，把用戶的 http 請求轉爲內部服務的 gPRC 請求；
4. 承擔 OpenID Relying Party 的角色，對接 Auth0、okta 等身份認證提供商的服務，把流量的安全做爲頭等大事來對待；
5. 經過運行時動態執行用戶函數的方式來實現 serverless，讓網關的邊緣節點更加靈活；
6. 不鎖定用戶，支持混合雲的部署架構；
7. 最後就是網關節點要狀態無關，能夠隨意的擴容和縮容。

一個微服務 API 網關具有了上述十幾項功能，就可讓用戶的服務只關心業務自己，而和業務實現無關的功能，好比服務發現、服務熔斷、身份認證、限流限速、統計、性能分析等，就能夠在獨立的網關層面來解決。從這個角度來看，API 網關既能夠替代 Nginx 的全部功能，來處理南北向的流量，也能夠完成 Istio 控制面和 Envoy 數據面的角色，來處理東西向的流量。

備選的 API 網關有哪些？

正由於微服務 API 網關的地位如此重要，因此它一直處於兵家必爭之地，傳統的 IT 巨頭在這個領域很早就都有佈局，好比谷歌、CA、IBM、紅帽、salesforce、以及 AWS、阿里雲等公有云廠商。

這些閉源的商業產品，它們的功能都很完善，覆蓋了 API 的設計、多語言 SDK、文檔、測試和發佈等全生命週期管理，而且提供 SaaS 服務，有些還與公有云作了集成，使用起來很是方便，但同時也帶來兩個痛點：

1. 平臺鎖定。API 網關是業務流量的入口，它不像圖片、視頻等 CDN 加速的這種非業務流量能夠隨意遷移，API 網關上會綁定很多業務相關的邏輯，一旦使用了閉源的方案，就很難平滑和低成本的遷移到其餘平臺。
2. 沒法二次開發。通常的大中型企業都會有本身獨特的需求，須要定製開發，這時候你就只能依靠廠商，而不能本身動手去作二次開發。

因此咱們更偏重於開源的 API 網關方案，好比 Kong、APISIX 和 Trk 等。這些 API 網關是從雲原生軟件基金會（CNCF）的全景圖中摘選的：

對比選型的依據

部署和維護成本

• 是能夠在單機就能完整部署，仍是須要多個節點配合才能使用？
• 是否有外部的數據庫依賴？好比 MySQL、Postgres？
• 是否有 web 控制檯能夠操做整個集羣？

開源仍是閉源

• 你是否能夠編寫本身的插件來擴展 API 網關的功能？
• 當你使用了某個 API 網關後，是否能夠平滑並且低成本的遷移到其餘 API 網關？
• 是否會被鎖定在特定的平臺上？

可否私有化部署

• 是否支持部署在用戶本身的內部服務器中？
• 是否支持多雲、混合雲的部署模式？

功能

• 是否支持動態上游、動態 SSL 證書、主動/被動健康檢查這些基本的功能
• 可否與 k8s 生態的系統聯動
• 是否能夠經過 HTTP REST API 和 yaml 配置文件這兩種方式，來控制網關配置

社區

• 使用者可否經過 Github、QQ 羣、Stack Overflow 等方式聯繫到社區的開發者？
• 開源許可證是否友好？
• 是否能夠方便的提交本身的修改到主線版本？
• 背後是否有商業公司支持？

商業支持和價格

• 開源版本和商業版本差別是否很大？
• 商業版本是按照 API 調用次數仍是訂閱方式收費？

API 網關對比

從中咱們能夠看出，Kong 和 APISIX 都是很不錯的選擇。