在團隊規模尚小，業務尚較為簡單的前提條件下，我們常常將多個功能集中在一個應用中，進行統一化的部署和測試。隨着業務的發展，功能模塊日益增多。如需更新單一模塊，都會需要對整個程序進行更新，如此下來，長期以往系統維護將會變得愈發費時費力。
針對以上問題，我們將單體應用進行拆分，變成多個自成一體的模塊，每個模塊有各自自成體系的發布和運維等功能，由此解決了單體應用的弊端，將應用微服務化。當我們拆分出多個模塊之后，各個模塊需要統一的出入口，這里我們需要使用網關解決統一調用和接入問題。
在這樣的背景之下，我們通過利用Kong這一開源API網關，將請求轉發到上游服務之前，進行一系列的管理。
本文針對其核心應用，首先簡要闡明Nginx、Openresty與Kong三者只間的關系，然后實際介紹如何使用Kong的插件機制來添加一個自定義插件。
1. 基本概念
Kong是一個開源的API網關，它是一個針對API的一個管理工具。你可以在那些上游服務之前，額外地實現一些功能。
Kong本身是一款基於OpenResty（Nginx + Lua模塊）編寫的高可用、易擴展的，由Mashape公司開源的API Gateway項目。Kong是基於NGINX和Apache Cassandra或PostgreSQL構建的，能提供易於使用的RESTful API來操作和配置API管理系統，所以它可以水平擴展多個Kong服務器，通過前置的負載均衡配置把請求均勻地分發到各個Server，來應對大批量的網絡請求。
1.1 Nginx
Nginx是模塊化設計的反向代理軟件，由C語言開發，是多進程（單線程） & 多路IO復用模型（高並發）。
多進程
Nginx 在啟動后，會有一個 master 進程和多個相互獨立的 worker 進程。接收來自外界的信號，向各worker進程發送信號，每個進程都有可能來處理這個連接。
master 進程能監控 worker 進程的運行狀態，當 worker 進程退出后(異常情況下)，會自動啟動新的 worker 進程。一個請求，完全由 worker 進程來處理，而且只能在一個 worker 進程中處理請求。
多路復用模型
epoll通過在Linux內核中申請一個簡易的文件系統，只要有 fd 上事件發生，epoll_wait() 就能檢測到並返回給用戶，用戶就能”非阻塞“地進行 I/O 了。
在內核，select中采用輪訓的方法來查看是由有fd文件描述符准備好。在內核，epoll根據每個sockfd上面與設備趨同程序建立站起來的回調函數，當某個sockfd上的時間發生，與之對應的回調函數就會被調用。
1.2 Openresty
OpenResty是一個基於 Nginx 與 Lua 的高性能 Web 平台，其內部集成了大量精良的 Lua 庫、第三方模塊以及大多數的依賴項。Openresty中的 Ngx_Lua_Module 使得開發人員能夠使用 Lua 腳本調動 Nginx 支持的各種模塊，讓 web 服務直接跑在 Nginx 內部。
Ngx_Lua_Module
把 Lua5.1 的解釋器 或 LuaJIT 2.0/2.1 的解釋器嵌入到 nginx 中，將強大的 Lua 線程（Lua threads）與 nginx 事務模型（Nginx event model）相結合，就可以更改變子請求（subrequests）的處理過程。
在 nginx 的一個 worker 里，所有請求共享一個Lua 解釋器或 LuaJIT 實例，即一個 nginx worker，一個 Lua 解釋器或 LuaJIT 實例。每個請求的上下文（context）是通過輕量級的 Lua 協程（coroutines）相互隔離的。
1.3 Kong
Kong 可以認為是一個 OpenResty 應用程序，而OpenResty 運行在 Nginx 之上，使用 Lua 擴展了 Nginx。Kong = OpenResty + Nginx + Lua
我們可以通過 HTTP Restful API 來動態管理 Kong 的配置，8001是默認的管理端口，8000/8443則分別是 Http 和 Https 的轉發端口，我們可以通過 HTTP Restful 來動態管理Kong配置。
# 配置一個上游服務
curl -X POST http://localhost:8001/upstreams --data "name=helloUpstream"
Kong插件機制
Kong具有極高的可擴展性，而它的高擴展性便來源於他的插件機制。
首先，先介紹如何在Kong中添加插件。
插件的作用范圍非常靈活，可作用於一個服務或者路由之上，也可作用於整個Kong服務。我們可以為一個服務添加50次/秒的官方限流插件，通過如下所示的Restful API方式:
curl -X POST http://localhost:8001/services/hello/plugins \
--data "name=rate-limiting" \
--data "config.second=50"
2. 開發Kong自定義插件
這里用添加一個名為key-auth-redis的自定義插件為例，詳細介紹如何在kong開發一個自定義插件。
├── kong_components
│ └── kong_plugins
│ └── key-auth-redis
│ ├── handler.lua # 請求生命周期
│ ├── access.lua # 邏輯實現部分
│ ├── schema.lua # 插件配置參數定義，或自定義校驗函數
│ ├── migrations
│ │ ├── 000_base_qingke-auth.lua # 數據庫結構信息
│ │ └── init.lua # 初始化數據結構信息
首先，進入Kong_plugins目錄，新建key-auth-redis的文件夾，並創建handler.lua文件和schema.lua文件，handler.lua文件中是插件主要的邏輯，需要繼承baseplugin，根據不同階段完成需要的邏輯。
Handler.lua 文件
local BasePlugin = require 'kong.plugins.base_plugin'
local access = require 'kong.plugins.key-auth-redis.access'
local AuthNotEncryption = BasePlugin:extend()
function AuthNotEncryption:access(conf)
access.execute(conf)
end
AuthNotEncryption.PRIORITY = 1000
AuthNotEncryption.VERSION = '1.0.0'
return AuthNotEncryption
這里注意AuthNotEncryption.PRIORITY 是插件執行的順序。
AuthNotEncryption.VERSION是插件的版本。local AuthNotEncryption= BasePlugin:extend()，Kong 的插件使用了一個叫 Classic 的 class 機制。所有的插件都是從 base_plugin.lua 基類上繼承而來。base_plugin.lua 定義了插件在各個階段被執行的方法名，我們在這里自定義變量AuthNotEncryption並繼承baseplugin，定義了這個Kong插件在執行中調用方法順序，最后return自定義變量。
Access.lua 文件
key-auth-redis這個插件需要訪問redis數據庫，進行訪問用戶鑒權，因此，我們只需要在訪問上游服務器前執行該插件。為了達到這個操作，我們需要重寫BasePlugin在訪問上有服務之前的生命周期函數，完成對應的邏輯。
下表這里為Kong各個生命周期函數的具體描述。
| 函數名 | 運行上下文函數 | 描述 |
|---|---|---|
| :init_worker | init_worker_by_lua_block | 在nginx worker啟動時執行 |
| :certificate | ssl_certificate_by_lua_block | 在SSL握手時證書階段執行該句柄 |
| :access | access_by_lua_block | 訪問上游服務器前執行 |
| :rewrite | rewrite_by_lua_block | 請求的rewrite階段執行 |
| :header_filter | header_filter_by_lua_block | 接收上游服務的所有Response header信息 |
| :body_filter | body_filter_by_lua_block | 從上游服務接收的響應主體的每個塊時執行。 由於響應被流回客戶端，因此它可以超過緩沖區大小並按塊進行流式傳輸。 因此,如果響應很大，則會多次調用此方法 |
| :log | log_by_lua_block | 響應字節結束后執行 |
通過此表，我們可以定位到想要實現key-auth-redis的功能，我們需要復寫access方法。完成插件的大致邏輯如下。
function _M.execute(conf)
local params
local method = kong.request.get_method()
if method == 'POST' then
params = kong.request.get_body()
else
return Response.exit(100010, params.data_id)
end
if (params == nil) then
return Response.exit(201500, "")
end
validate_params(params, conf)
do_authentication(conf, cache, params)
end
return _M
這里通過kong.request.get_body()獲取訪問帶有參數，然后調用access.lua中帶有的訪問校驗函數do_authentication。
Schema.lua 文件
schema.lua是插件在使用自定義配置參數的主要腳本。在schema文件中，我們可以進行對key-auth-redis插件中訪問redis數據庫的配置。
local typedefs = require 'kong.db.schema.typedefs'
local utils = require "kong.tools.utils"
return {
name = 'key-auth-redis',
fields = {
{consumer = typedefs.no_consumer},
{run_on = typedefs.run_on_first},
{protocols = typedefs.protocols_http},
{
config = {
type = 'record',
fields = {
{redis_host = {type = 'string', default = '0.0.0.0'}},
{redis_port = {type = 'number', default = 6379}},
{redis_password = {type = 'string', default = ''}},
{redis_timeout = {type = 'number', default = 200000}},
{redis_connections = {type = 'number', default = 1000}},
{fault_tolerant = {type = 'boolean', default = true}},
{redis_database = {type = 'number', default = 0}},
{clock_skew = {type = 'number', default = 300, gt = 0}}
}
}
}
}
}
在field中，成員類型可以是string、boolean、array、number、timestamp，我們可以根據插件所需要的參數類型，進行參數配置。
到此為止，key-auth-redis的插件代碼部分已經介紹完畢。在完成代碼修改之后需要重啟Kong，重啟命令。
kong restart -c kong.conf --vv
然后，通過如下命令重啟啟動kong。
kong start
PS：
我們是行者AI，我們在“AI＋游戲”中不斷前行。
如果你也對游戲感興趣，對AI充滿好奇，那就快來加入我們（hr@xingzhe.ai）。