前言
在微服務架構中，由於系統和服務的細分，導致系統結構變得非常複雜， 為了跨平臺，為了統一集中管理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。
- 可對出入流量進行管制。
- 提供了可視化的流量檢查、監視分析Api。
- 能夠及時的轉換請求和相應。
- 提供log解決方案
- 可通過api調用Serverless 函數。
業務網關與流量網關
對於具體的後端業務應用或者是服務和業務有一定關聯性的策略網關就是上圖左邊的架構模型——業務網關。 業務網關針對具體的業務需要提供特定的流控策略、緩存策略、鑑權認證策略等等。
與業務網關相反，定義全局性的、跟具體的後端業務應用和服務完全無關的策略網關就是上圖右邊所示的架構模型——流量網關。流量網關通常只專注於全局的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停止維護，gateway還在完善之中的情況下，Kong也是值得關注的網關技術選型之一。
閱讀更多 java互聯網架構 的文章
