微服務最強開源流量網關Kong

前言

在微服務架構中，因爲系統和服務的細分，致使系統結構變得很是複雜， 爲了跨平臺，爲了統一集中管理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也是值得關注的網關技術選型之一。從此也會在https://felord.cn 分享相關的使用心得。 也能夠關注個人公衆號：Felordcn 和我進行直接的探討交流。

關注公衆號：碼農小胖哥 獲取更多資訊