今天準備介紹下開源API網關Kong，在Gtihub搜索API網關類的開源產品，可以看到Kong網關常年都是排第一的位置，而且當前很多都有一定研發能力的企業在API網關產品選型的時候基本也會選擇Kong網關，並基於Kong網關進行二次開發和定製。

API網關概述

簡單來說API網關就是將所有的微服務提供的API介面服務能力全部匯聚進來，統一接入進行管理，也正是通過統一攔截，就可以通過網關實現對API介面的安全，日誌，限流熔斷等共性需求。如果再簡單說下，通過網關實現了幾個關鍵能力。

內部的微服務對外部訪問來說位置透明，外部應用只需和網關交互
統一攔截介面服務，實現安全，日誌，限流熔斷等需求

從這裡，我們就可以看到API網關和傳統架構裡面的ESB匯流排是類似的，這些關鍵能力本身也是ESB服務匯流排的能力，但是ESB服務匯流排由於要考慮遺留系統的接入，因此增加了：

大量適配器實現對遺留系統的遺留介面適配，多協議轉換能力
進行數據的複製映射，路由等能力

對於兩者，我原來做過一個簡單的對比，大家可以參考。

對於API網關進一步的功能介紹，可以我前面參考文章：

一文詳細講解API網關核心功能和API管理擴展

基於Openresty開發API網關

在談API網關前，我們先談下Openresty。在前面文章談到過，當前適合用於API網關的架構，一種是基於Openresty的，一種是基於Go語言的。

OpenResty® 是一個基於 Nginx 與 Lua 的高性能 Web 平台，其內部集成了大量精良的 Lua 庫、第三方模塊以及大多數的依賴項。用於方便地搭建能夠處理超高並發、擴展性極高的動態 Web 應用、Web 服務和動態網關。

OpenResty® 通過匯聚各種設計精良的 Nginx 模塊（主要由 OpenResty 團隊自主開發），從而將 Nginx 有效地變成一個強大的通用系統 Web 應用平台。這樣，Web 開發人員和系統工程師可以使用 Lua 腳本語言調動 Nginx 支持的各種 C 以及 Lua 模塊，快速構造出足以勝任 10K 乃至 1000K 以上單機並發連接的高性能 Web 應用系統。

OpenResty® 的目標是讓你的Web服務直接跑在 Nginx 服務內部，充分利用 Nginx 的非阻塞 I/O 模型，不僅僅對 HTTP 客戶端請求,甚至於對遠程後端諸如 MySQL、PostgreSQL、Memcached 以及 Redis 等都進行一致的高性能響應。

為何Openresty適合用於API網關開發？

對於API網關，有一個最基礎的核心功能即需要實現介面服務代理路由，而這個本身也是Nginx反向代理能夠提供的一個標準功能。

如果應用場景比較簡單，僅僅是實現統一介面對外暴露，可以看到很多企業實際並沒有採用API網關，而是直接採用了Nginx來替代API網關的服務代理路由功能。

其次，對於常規的API網關的中間件研發，在研發完成後本身還要依託一個Web容器進行部署，同時還需要自己去實現類似路由代理等各種能力。

在這種場景下可以看到，依託於Nginx，在其內部來擴展一個Web容器能力，既可以充分的利用Nginx本身的代理路由和性能優勢就是一個重要的選擇。而OpenResty本身可以看做是基於Nginx伺服器，在其worker裡面內嵌了一個LuaJVM，通過這種方式來實現了兩者的融合。同時又可以通過開發和定製各種Lua庫來進行快速的功能擴展。

也正是這樣原因，基於Openresty來擴展動態網關功能是一個很好的選擇。

OpenResty的安裝

在Centos下可以通過yum很方便的安裝OpenResty，具體如下：

//安裝yum-utils
# sudo yum install yum-utils
//添加 openresty 倉庫
sudo yum-config-manager --add-repo https://openresty.org/package/centos/openresty.repo
//安裝openresty
# sudo yum install openresty
//安裝命令行工具
# sudo yum install openresty-resty
//至此安裝成功，默認安裝在  /usr/local/openresty
//測試
# sudo /sbin/service openresty start
# sudo /sbin/service openresty stop

注意在安裝完成後如果通過瀏覽器訪問，需要先關閉防火牆或者打開放行80埠。

Kong網關概述

首先我們看下GitHub上對Kong網關的一些介紹

當我們決定對應用進行微服務改造時，應用客戶端如何與微服務交互的問題也隨之而來，畢竟服務數量的增加會直接導致部署授權、負載均衡、通信管理、分析和改變的難度增加。

面對以上問題，API GATEWAY是一個不錯的解決方案，其所提供的訪問限制、安全、流量控制、分析監控、日誌、請求轉發、合成和協議轉換功能，可以解放開發者去把精力集中在具體邏輯的代碼，而不是把時間花費在考慮如何解決應用和其他微服務鏈接的問題上。

Kong網關是一款基於OpenResty（Nginx + Lua模塊）編寫的高可用、易擴展的，由Mashape公司開源的API Gateway項目。Kong是基於NGINX和Apache Cassandra或PostgreSQL構建的，能提供易於使用的RESTful API來操作和配置API管理系統，所以它可以水平擴展多個Kong伺服器，通過前置的負載均衡配置把請求均勻地分發到各個Server，來應對大批量的網路請求。

KONG本身提供包括HTTP基本認證、密鑰認證、CORS、TCP、UDP、文件日誌、API請求限流、請求轉發及NGINX監控等基本功能。目前，Kong在Mashape管理了超過15,000個API，為200,000開發者提供了每月數十億的請求支持。

Kong網關核心組件

Kong Server ：基於nginx的伺服器，用來接收API請求。
Apache Cassandra/PostgreSQL ：用來存儲操作數據。
Kong dashboard：官方推薦UI管理工具，也可以使用開源的Konga平台

Kong採用插件機制進行功能定製，當前本身已經具備了類似安全，限流，日誌，認證，數據映射等基礎插件能力，同時也可以很方便的通過Lua定製自己的插件。插件完全是一種可以動態插拔的模式，通過插件可以方便的實現Kong網關能力的擴展。

Kong網關核心組件關鍵特性

Cloud-Native雲原生：與平台無關，Kong可以在從裸機到容器的任何平台上運行，並且可以在每個雲上本地運行。
Kubernetes集成能力：使用官方的Ingress Controller通過本地Kubernetes CRD聲明性地配置Kong，以路由和連接所有L4 + L7層網路流量。
動態負載均衡：在多個上游服務之間平衡流量。
基於哈希的負載均衡：具有一致的哈希/粘性會話的負載均衡。
斷路器：智能跟蹤不健康的上游服務。
健康檢查：主動和被動監視上游服務。
服務發現：在Consul之類的第三方DNS解析器中解析SRV記錄。
Serverless：直接從Kong調用和保護AWS Lambda或OpenWhisk功能。
WebSockets：通過WebSockets與您的上游服務進行通信。
gRPC：與gRPC服務進行通信，並通過日誌記錄和可觀察性插件觀察流量
OAuth2.0：輕鬆將OAuth2.0身份驗證添加到您的API。
日誌功能：通過HTTP，TCP，UDP或磁碟Log對系統的請求和響應。
安全性：ACL，殭屍程序檢測，允許/拒絕IP等…
Syslog：登錄到系統日誌。
SSL：為基礎服務或API設置特定的SSL證書。
監控：對關鍵負載和性能伺服器指標提供動態實時監控。
轉發代理：使Kong連接到透明的中介HTTP代理。
認證：HMAC，JWT，Basic等。
限流：基於許多變數的阻止和限制請求。
轉換：添加，刪除或處理HTTP請求和響應。
緩存：在代理層緩存並提供響應。
CLI：從命令行控制Kong群集。
開放API介面：Kong可以使用其RESTful API進行操作，以實現最大的靈活性。
跨區域複製：跨不同區域的配置始終是最新的。
故障檢測和恢復：如果您的Cassandra節點之一發生故障，則Kong不會受到影響。
群集：所有Kong節點自動加入群集，並在各個節點之間更新其配置。
可擴展性：Kong本質上分布，只需添加節點即可水平擴展。
性能：Kong通過擴展和使用NGINX作為核心輕鬆處理負載。
插件：可擴展的體系結構，用於向Kong和API添加功能。

Kong網關的主要功能分析

對於Kong網關本身基於OpenResty構建，因此前面介紹的OpenResty本身的特性也就成了Kong網關的特性，同時Kong網關本身天然和OpenResty融合在一起，不再需要依賴其他的中間件或Web容器進行部署。

其次就是Kong網關本身的插件化開發機制，通過插件對Http介面請求和響應進行攔截，在攔截處就可以實現各種API介面管控和治理的要求。插件通過Lua語言開發，可以動態插拔。

要實現和Kong網關本身的集成和管理本身也很簡單，Kong網關提供各類的Rest API介面，可以很方便的實現和Kong網關能力的對接。也就是說你完全可以自己開發要給API管控治理平台，而底層引擎用Kong網關。

支持高可用集群，節點之間的發現採用的gossip協議，當Kong節點啟動後，會將自己的IP信息加入到node列表，廣播給任何其他的Kong節點，當另一個Kong節點啟動後，會去讀取資料庫中的node列表，並將自己的信息加入到列表中。

另外再來看下Kong API網關提供的一些基本功能：

API註冊和服務代理

對於原始的API介面進行註冊，並提供服務代理能力，即不同的API介面註冊到網關後，網關可以提供一個統一的訪問地址和介面。這和ESB匯流排的代理服務道理是一致的，在服務註冊到API網關後，所有的內部服務對外界都是透明的，外部的服務訪問必須要通過API網關進行。

該部分對應到Kong API網關的服務註冊和Routing部分的功能和能力上。

負載均衡

由於Kong API網關本身底層也是基於Nginx的，因此對應負載均衡的能力實際上是通過底層的Nginx來完成的。要在Kong上面實現負載均衡和API註冊代理實際上需要分開為兩個步驟進行。

即首先是要配置負載均衡能力，建立Upstream組，並添加多個Target，其次才是進行API註冊。

AUTHENTICATION實現

通過OAuth 2.0 Authentication插件實現user埠的用戶訪問限制。其具體步驟如下：

註冊Oauth2插件，配置參考
添加Consumer及Consumer對應的credentials
申請accesstoken並訪問，如果不帶token訪問將被拒絕

安全和訪問控制

支持最基本的基於IP的安全訪問控制和黑白名單設置。即為相應的埠添加IP Restriction插件擴展，並設置白名單（只有名單內的IP可以訪問API）。

這和我們當前ESB的基於IP的訪問控制和授權是一個道理。但是我們的ESB更加靈活，多了業務系統這一層，即可以直接對業務系統這層統一進行授權。

如果沒有授權，在進行訪問的時候將返回Your IP address is not allowed的訪問錯誤。

流量控制-Traffic Control

流量控制在當前Kong網關上，從GitHub上的參考來看，主要是實現了可以基於單位時間內的訪問次數進行流量控制，如果超過了這個訪問次數，則直接提示流控約束且無法訪問的提示。當前的流量控制，暫時不支持基於數據量的流控。

當前的流控暫時沒有看到微服務網關常用的熔斷操作，即服務並發或服務響應時間大過某個臨界值的時候，直接對服務進行熔斷和下線操作。

日誌Logging實現

通過File-log插件實現對於每次訪問日誌的獲取，需要注意為日誌文件寫許可權，日誌格式參考Log Format。具體包括兩個步驟。

為埠添加File-log插件，並設置為日誌文件路徑設為:/tmp/file.log
添加日誌插件後，每次訪問都會被記錄

當前Kong網關日誌都是寫入到文件系統中，但是這塊可以很方便的定製日誌插件將日誌寫入到緩存庫，時序資料庫或分散式資料庫。另外當前的日誌LOGGING是沒有提供日誌查詢的前端功能界面的，如果需要的話還需要自己開發對應的日誌查詢功能。

這個日誌功能和我們當前的ESB匯流排的日誌Log完全是類似的。但是我們ESB這塊的能力更加強，包括後續的服務運行日誌的統計分析和報表查看等。

Kong網關插件說明

從上圖可以看到，Kong網關是基於OpenResty應用伺服器，OpenResty是一個基於 Nginx 與 Lua 的高性能 Web 平台，其內部集成了大量精良的 Lua 庫、第三方模塊以及大多數的依賴項。用於方便地搭建能夠處理超高並發、擴展性極高的動態 Web 應用、Web 服務和動態網關。而Kong 核心基於OpenResty構建，並且擁有強大的插件擴展功能。

在Http請求到達Kong網關後，轉發給後端應用之前，可以通過網關的各種插件對請求進行流量控制，安全，日誌等各方面的處理能力。當前Kong的插件分為開源版和社區版，社區版還有更多的定製功能，但是社區版是要收費的。

目前，KONG開源版本一共開放28個插件，如下：

acl、aws-lambda、basic-auth、bot-detection、correlation-id、cors、datadog、file-log、galileo、hmac-auth、http-log、ip-restriction、jwt、key-auth、ldap-auth、loggly、oauth2、rate-limiting、request-size-limiting、request-termination、request-transformer、response-ratelimiting、response-transformer、runscope、statsd、syslog、tcp-log、udp-log。

以上這些插件主要分五大類，Authentication認證，Security安全，Traffic Control流量控制，Analytics & Monitoring分析&監控，Logging日誌，其他還有請求報文處理類。插件類似AOP開發中的橫切功能，可以靈活的配置進行攔截控制，下面選擇一些關鍵性的插件進行簡單的說明。

黑白名單控制能力-ip-restriction

Kong提供的IP黑白名單控制能力還算相當強，從配置項裡面可以看到主要可以針對兩個維度進行配置，一個是針對所有的API介面還是針對特定的API介面，一個是針對所有的消費方還是特定的某個消費方。

對於IP配置可以是一個區段，也可以是特定的IP地址。但是黑白名單不能同時配置，其次當前沒有一個功能是針對某一個系統提供的所有服務都啟用黑名單或白名單功能。

日誌記錄能力-syslog, file-log，http-log

這裡主要日誌的插件比較多，一個是sysLog在配置後可以直接將Kong產生的日誌寫入到應用伺服器的系統日誌文件中。如果配置了file-log則是單獨寫入到你指定的file文件中。對於http-log則是對於http服務請求，可以詳細的記錄請求的輸入和輸出報文信息，但是具體是記錄到哪裡，需要通過config.http_endpoint配置。

如果需要將API介面調用消息報文日誌寫入到分散式存儲或資料庫中，則需要自己定義相應的日誌插件來接入寫入問題。

熔斷插件-request-termination

該插件用來定義指定請求或服務不進行上層服務，而直接返回指定的內容，用來為指定的請求或指定的服務進行熔斷。注意Kong的熔斷插件感覺是臨時對服務的禁用，而不是說當達到某一種監控閾值的時候自動觸發熔斷。從官方文檔的應用場景也可以看到這點。

如果僅僅是這種方式的熔斷話，實際上意義並不是很大。但是可用的地方就在於當某個業務系統進行發版部署的時候我們可以對該業務系統或該業務系統所提供的所有服務進行熔斷。

限流插件-rate-limiting

Kong當前提供的限流相對來說還是比較弱，即主要是控制某一個API介面服務在單位時間內最多只能夠調用多少次，如果超過這個次數那麼網關就直接拒絕訪問並返回錯誤提示信息。而在前面我講限流和流量控制的時候經常會說到，就是限流實際上一個是根據服務調用次數，一個是根據服務調用數據量，需要在這兩個方面進行限流。而裡面更加重要的反而是數據量的限流，因為大數據量報文往往更加容易造成內存溢出異常。

安全認證類插件

當前Kong網關提供basic-auth，key-auth、ldap-auth，hmac-auth多種認證插件。

Basic-auth基本認證插件，即我們根據用戶名和密碼來生成一個base64編碼，同時將該編碼和目標服務綁定，這樣在消費目標服務的時候就需要在報文頭填寫這個Base64編碼信息。

Key-auth認證插件則是利用提前預設好的關鍵字名稱，如下面設置的keynote = apices，然後為consumer設置一個key-auth 密鑰，假如key-auth=test@keyauth。在請求api的時候，將apikey=test@keyauth，作為一個參數附加到請求url後，或者放置到headers中。

Hmac-auth插件是設置綁定的service和rout，以啟動hmac驗證。然後在Consumers頁面中Hmac credentials of Consumer設置中添加一個username和secret。

請求報文容量限制-request-size-limiting

該插件用於限制請求報文的數據量大小，可以限制單個服務，也可以顯示所有的API介面服務。這個實際上是很有用的一個功能，可以防止大消息報文調用導致整個API網關內存溢出。

支持OAuth2.0身份認證-oauth2

Kong網關支持OAuth2.0身份認證，OAuth2.0 協議根據使用不同的適用場景，定義了用於四種授權模式。即Authorization code（授權碼模式），Implicit Grant（隱式模式），Resource Owner Password Credentials（密碼模式），Client Credentials（客戶端模式）。

在四種方式中經常採用的還是授權碼這種標準的 Server 授權模式，非常適合 Server 端的 Web 應用。一旦資源的擁有者授權訪問他們的數據之後，他們將會被重定向到 Web 應用並在 URL 的查詢參數中附帶一個授權碼（code）。

在客戶端里， code 用於請求訪問令牌（access_token）。並且該令牌交換的過程是兩個服務端之前完成的，防止其他人甚至是資源擁有者本人得到該令牌。另外，在該授權模式下可以通過 refresh_token 來刷新令牌以延長訪問授權時間，也是最為複雜的一種方式。

簡單轉換能力

對於簡單轉換能力通過request-transformer 和 response transformer兩個插件來完成。Kong網關提供對輸入和輸出報文簡單轉換的能力，這部分內容後續再詳細展開介紹。從當前配置來看，主要是對消息報文提供了Add, Replace,Rename,Append等各種簡單操作能力。

Kong網關和其它網關對比

對於開源的Kong網關和其它網關的對比如下。

從上面對比圖也可以看到，Kong網關在功能，性能，插件可擴展性各方面都能夠更好的滿足企業API網關的需求。因此我們也是基於Konga來進一步定製對Kong網關的管控治理平台。

在整個定製中增加了基於DB適配的Http Rest API介面的自動發布，API服務自動化註冊，服務日誌採集和服務日誌查詢，常見映射模板定製，介面服務的自動化測試等方面的能力。

Kong網關的安裝

在這裡以在Centos7下安裝Kong2.2版本說明。注意centos7安裝Postgresql不再列出，可以參考網上的文章進行安裝。

# 安裝kong-yum源
$wget https://bintray.com/kong/kong-rpm/rpm -O bintray-kong-kong-rpm.repo
$export major_version=`grep -oE '[0-9]+.[0-9]+' /etc/redhat-release | cut -d "." -f1`
$sed -i -e 's/baseurl.*/&/centos/'$major_version''/ bintray-kong-kong-rpm.repo
$mv bintray-kong-kong-rpm.repo /etc/yum.repos.d/
  
# 清空緩存，重新生成緩存
$yum clean all && yum makecache
# 查看yum源信息
$yum repolist
# 更新yum源
$yum update -y

#############################
#通過yum安裝kong
#注意如果出現和openresty不兼容，需要先下載老版本的openresty
$yum install -y kong
# 查看配置文件位置
$whereis kong
$kong: /etc/kong /usr/local/bin/kong /usr/local/kong

#############################
#安裝postgresql資料庫（略）
#############################

#資料庫創建kong用戶
$su - postgres
$psql -U postgres
 CREATE USER kong; 
 CREATE DATABASE kong OWNER kong;
 ALTER USER kong with encrypted password 'kong';  
#修改kong,postgresql連接配置
$cp -r /etc/kong/kong.conf.default /etc/kong/kong.conf
$vi /etc/kong/kong.conf
    database = postgres
    pg_host = 172.28.102.62
    pg_port = 5432
    pg_timeout = 5000
    pg_user = kong
    pg_password = kong
    pg_database = kong
    
# 初始化資料庫
$kong migrations bootstrap [-c /etc/kong/kong.conf]
注意執行過程如遇到 failed to retrieve PostgreSQL server_version_num: FATAL: Ident authentication failed for user "kong",請給該用戶設定密碼，並修改postgres的授權方式為MD5，操作如下:
$alter user kong with password  'kong';
# 啟動kong
$kong start [-c /etc/to/kong.conf]
#檢查 KONG 是否正確運行
$curl -i http://localhost:8001/
或者
$kong health
#停止 KONG
$ kong stop

Kong-Dashboard安裝

對於Kong網關本身也提供了Kong Dashboard管理頁面，下面再看下Dashboard的安裝。在安裝Dashboard前需要首先安裝node.js，具體如下：

#解壓安裝包
$wget http://nodejs.org/dist/v8.1.0/node-v8.1.0.tar.gz 
$tar zxvf node-v8.1.0.tar.gz 
$cd node-v8.1.0

#進行編譯和安裝（注意編譯需要很長時間）
$./configure –prefix=/usr/local/node/*
$make
$make install

ln -s /usr/local/node/bin/* /usr/sbin/  

#npm 配置
npm set prefix /usr/local
echo -e 'nexport PATH=/usr/local/lib/node_modules:$PATH' >> ~/.bashrc
source ~/.bashrc

在node.js安裝完成後可以安裝Dashboard

#從git庫克隆
git clone https://github.com/PGBI/kong-dashboard

#安裝Kong Dashboard:
npm install -g kong-dashboard@v2

#啟動kong-dashboard，注意和老版本有變化
#啟動時候可以自己指定埠號如9001
kong-dashboard start -p 9001

#訪問kong-dashboard
http://localhost:9001

在啟動後再配置Dashboard需要綁定的Kong Server，如下：