前言

在微服務架構中，由於系統和服務的細分，導致系統結構變得非常複雜， 為了跨平臺，為了統一集中管理api，同時為了不暴露後置服務。甚至有時候需要對請求進行一些安全、負載均衡、限流、熔斷、灰度等中間操作，基於此類種種的客觀需求一個類似綜合前置的系統就產生了，這就是API閘道器（API Gateway）。API閘道器作為分散在各個業務系統微服務的API聚合點和統一接入點，外部請求通過訪問這個接入點，即可訪問內部所有的REST API服務。目前常用的微服務閘道器有zuul、gateway，今天來簡單介紹一下另一種選擇——Kong 。說到Kong可能對大家有點陌生，我們來先了解下另一種不陌生的中介軟體——OpenResty。

OpenResty

OpenResty® 是一個基於 Nginx 與 Lua 的高效能 Web 平臺，其內部集成了大量精良的 Lua 庫、第三方模組以及大多數的依賴項。用於方便地搭建能夠處理超高併發、擴充套件性極高的動態 Web 應用、Web 服務和動態閘道器。因此，我們可以做出各種符合我們需要的閘道器策略的Lua指令碼，以其為基礎構建高效能的網關係統。

Kong

Kong基於OpenResty，是一個雲原生、快速、可擴充套件、分散式的Api 閘道器。繼承了OpenResty的高效能、易擴充套件性等特點。Kong通過簡單的增加機器節點，可以很容易的水平擴充套件。同時功能外掛化，可通過外掛來擴充套件其能力。而且在任何基礎架構上都可以執行。具有以下特性：

業務閘道器與流量閘道器

對於具體的後端業務應用或者是服務和業務有一定關聯性的策略閘道器就是上圖左邊的架構模型——業務閘道器。 業務閘道器針對具體的業務需要提供特定的流控策略、快取策略、鑑權認證策略等等。

與業務閘道器相反，定義全域性性的、跟具體的後端業務應用和服務完全無關的策略閘道器就是上圖右邊所示的架構模型——流量閘道器。流量閘道器通常只專注於全域性的Api管理策略，比如全域性流量監控、日誌記錄、全侷限流、黑白名單控制、接入請求到業務系統的負載均衡等，有點類似防火牆。Kong 就是典型的流量閘道器。

這裡需要補充一點的是，業務閘道器一般部署在流量閘道器之後、業務系統之前，比流量閘道器更靠近業務系統。通常API閘道器指的是業務閘道器。 有時候我們也會模糊流量閘道器和業務閘道器，讓一個閘道器承擔所有的工作,所以這兩者之間並沒有嚴格的界線。

Kong 的架構

請求流程

每個客戶請求都會先到達Kong 閘道器，然後再代理到最終的API。在請求和響應之間，Kong將執行已安裝配置的外掛，從而擴充套件AP的I功能集。

外掛

外掛作為Kong的一大特色這裡不得不簡單提一下，目前Kong的外掛有免費、有收費（企業版）、還有社群（github）提供的，有能力也可以通過Kong官方提供的模板使用lua指令碼來開發自己定製的外掛。現階段提供有8類外掛功能涉及身份驗證、許可權安全、流量控制、Serverless、分析與監控、資料轉換、日誌資訊、部署釋出。可通過官方外掛庫或者github搜尋來獲取。

上手難度

Kong 提供了在各個平臺的安裝包。目前最新版本提供了無資料庫依賴和資料庫依賴兩種模式，安裝並不複雜。如果從現有的Kong提供的功能來說，全部基於配置。可通過配置檔案或者Restful Admin Api 進行配置管理。而且有很多第三方視覺化UI，如Konga 。如果需要對Kong進行定製化開發，需要深度掌握OpenResty、Nginx、lua指令碼等相關的知識，所以一般建議Kong作為流量閘道器使用。

總結

今天大體簡單介紹了Kong閘道器，在zuul停止維護，Spring Cloud Gateway還在完善之中的情況下，Kong也是值得關注的閘道器技術選型之一。今後也會在https://www.spring4all.com 分享相關的使用心得。 也可以關注社群公眾號：SpringForAll社群 和我進行直接的探討交流。