实现自定义逻辑
本文原文链接:https://docs.konghq.com/1.1.x/plugin-development/custom-logic/
简介
Kong插件允许您在 request/response 的生命周期中的几个入口点注入自定义逻辑(使用 Lua 语言),因为它由Kong代理。为此,必须实现base_plugin.lua 接口的一个或多个方法。这些方法将在命名空间下的模块中实现:kong.plugins。<plugin_name> .handler。
Module
kong.plugins.<plugin_name>.handler
可用的请求上下文
插件接口允许您覆盖handler.lua文件中的以下任何方法,以在Kong的执行生命周期的各个入口点实现自定义逻辑:
| 函数名 | LUA-NGINX-MODULE Context | 描述 |
|---|---|---|
:init_worker() |
init_worker_by_lua | 在每个 Nginx 工作进程启动时执行 |
:certificate() |
ssl_certificate_by_lua | 在SSL握手阶段的SSL证书服务阶段执行 |
:rewrite() |
rewrite_by_lua | 从客户端接收作为重写阶段处理程序的每个请求执行。在这个阶段,无论是API还是消费者都没有被识别,因此这个处理器只在插件被配置为全局插件时执行 |
:access() |
access_by_lua | 为客户的每一个请求而执行,并在它被代理到上游服务之前执行 |
:header_filter() |
header_filter_by_lua | 从上游服务接收到所有响应头字节时执行 |
:body_filter() |
body_filter_by_lua | 从上游服务接收的响应体的每个块时执行。由于响应流回客户端,它可以超过缓冲区大小,因此,如果响应较大,该方法可以被多次调用 |
:log() |
log_by_lua | 当最后一个响应字节已经发送到客户端时执行 |
所有这些函数都使用一个参数,该参数由Kong在调用时给出:插件的配置。此参数是Lua表,并包含用户根据插件的架构(在schema.lua模块中描述)定义的值。有关插件模式的更多信息将在下一章中介绍。
handler.lua规范
handler.lua文件必须返回一个表,该表实现了您希望执行的函数。为简洁起见,这里有一个注释示例模块,它实现了所有可用的方法:
-- 扩展基本插件处理程序是可选的,因为Lua中没有真正的接口概念,-- 但是基本插件处理程序的方法可以从子实现中调用,-- 并将在“error.log”中打印日志(其中打印所有日志)。local BasePlugin = require "kong.plugins.base_plugin"local CustomHandler = BasePlugin:extend()-- 你的插件处理程序的构造函数。-- 如果要扩展基本插件处理程序,它的唯一作用就是用名称实例化自己。-- 该名称是您的插件名称,因为它将打印在日志中function CustomHandler:new()CustomHandler.super.new(self, "my-custom-plugin")endfunction CustomHandler:init_worker()-- 最终,执行父实现-- (将记录您的插件正在进入此上下文)CustomHandler.super.init_worker(self)-- 在此实现任何自定义逻辑endfunction CustomHandler:certificate(config)-- 最终,执行父实现-- (将记录您的插件正在进入此上下文)CustomHandler.super.certificate(self)-- Implement any custom logic hereendfunction CustomHandler:rewrite(config)-- Eventually, execute the parent implementation-- (will log that your plugin is entering this context)CustomHandler.super.rewrite(self)-- Implement any custom logic hereendfunction CustomHandler:access(config)-- Eventually, execute the parent implementation-- (will log that your plugin is entering this context)CustomHandler.super.access(self)-- Implement any custom logic hereendfunction CustomHandler:header_filter(config)-- Eventually, execute the parent implementation-- (will log that your plugin is entering this context)CustomHandler.super.header_filter(self)-- Implement any custom logic hereendfunction CustomHandler:body_filter(config)-- Eventually, execute the parent implementation-- (will log that your plugin is entering this context)CustomHandler.super.body_filter(self)-- Implement any custom logic hereendfunction CustomHandler:log(config)-- Eventually, execute the parent implementation-- (will log that your plugin is entering this context)CustomHandler.super.log(self)-- Implement any custom logic hereend-- 该模块需要返回创建的表-- 让Kong 可以执行这些功能。return CustomHandler
当然,插件本身的逻辑可以抽象到另一个模块中,并从处理程序模块调用。许多现有的插件在逻辑冗长时已经选择了这种模式,但它是完全可选的:
local BasePlugin = require "kong.plugins.base_plugin"-- 实际的逻辑是在这些模块中实现的local access = require "kong.plugins.my-custom-plugin.access"local body_filter = require "kong.plugins.my-custom-plugin.body_filter"local CustomHandler = BasePlugin:extend()function CustomHandler:new()CustomHandler.super.new(self, "my-custom-plugin")endfunction CustomHandler:access(config)CustomHandler.super.access(self)-- 从“access”中加载的模块执行任何函数,-- 例如,`execute()`并将插件的配置传递给它。access.execute(config)endfunction CustomHandler:body_filter(config)CustomHandler.super.body_filter(self)-- Execute any function from the module loaded in `body_filter`,-- for example, `execute()` and passing it the plugin's configuration.body_filter.execute(config)endreturn CustomHandler
有关实际处理程序代码的示例,请参阅Key-Auth插件的源代码。
插件开发套件
在这些阶段中实现的逻辑很可能必须与请求/响应对象或核心组件交互(例如访问缓存、数据库……)。Kong提供了一个插件开发套件(简称PSK),一组Lua函数和变量,插件可以使用这些Lua函数和变量来执行各种网关操作,确保它们与将来的Kong版本向前兼容。
当您试图实现一些需要与Kong交互的逻辑时(例如检索请求头、从插件生成响应、记录一些错误或调试信息……),您应该参考插件开发工具包。
插件执行顺序
一些插件可能依赖于其他插件的执行来执行一些操作。例如,依赖于消费者身份的插件必须在身份验证插件之后运行。考虑到这一点,Kong定义了插件执行之间的优先级,以确保顺序得到遵守。
你的插件的优先级可以通过一个属性来配置,在返回的handler table 中一个数字:
CustomHandler.PRIORITY = 10
优先级越高,相对于其他插件的阶段(如:access()、:log()等),插件的阶段执行得越快。 已有捆绑插件的当前执行顺序为:
| 插件 | 优先级 |
|---|---|
| pre-function | +inf |
| zipkin | 100000 |
| ip-restriction | 3000 |
| bot-detection | 2500 |
| cors | 25000 |
| jwt | 1005 |
| oauth2 | 1004 |
| key-auth | 1003 |
| ldap-auth | 1002 |
| basic-auth | 1001 |
| hmac-auth | 1000 |
| request-size-limiting | 951 |
| acl | 950 |
| rate-limiting | 901 |
| response-ratelimiting | 900 |
| request-transformer | 801 |
| response-transformer | 800 |
| aws-lambda | 750 |
| azure-functions | 749 |
| prometheus | 13 |
| http-log | 12 |
| statsd | 11 |
| datadog | 10 |
| file-log | 9 |
| udp-log | 8 |
| tcp-log | 7 |
| loggly | 6 |
| syslog | 4 |
| galileo | 3 |
| request-termination | 2 |
| correlation-id | 1 |
| post-function | -1000 |
