Kong 插件加载机制概述

概述

插件可以认为是 Kong 管理 API 的核心，其模块化和可扩张性做得很好，尤其是其灵活的加载机制使得 Kong 能够针对不同 API 启用、组合任意插件。Kong 默认自带的插件集，按照功能的不同大致可以分为六大类： Authentication 认证、Security 安全、Traffic Control 流量控制、Analytics & Monitoring 分析监控、Transformations 请求报文处理、Logging 日志等 。

无论是为了理解这些插件的工作原理，亦或者是定制开发属于自己的插件，熟悉插件的加载机制无疑都是一个关键的前提。

Kong 从 0.11.0 版本开始区分了社区版和商业版，节点之间的消息通信也改为了数据库轮训机制（原先是通过 serf 实现的），通过最终一致性实现了节点的无状态，任何时候节点只需连上数据库即可工作。之前的版本都相对来说太重，部署过于复杂。所以我这里将基于 Kong 0.12.3 版本分析其插件加载机制。

我一般研究一门新技术，倾向于研究更新更早期的代码。 因为非常成熟有名的代码往往已经过度设计，对于阅读代码入门不一定是好的选择。而一些出于项目早期的代码，倒是更容易阅读理解其核心原理。

---

1. 插件的应用方式

Kong 按照插件的不同应用方式，大致可以分为 两大类四小类 ：

• 全局插件 → GLOBAL 既不独自应用于 API，又不独自应用于 Consumer 的插件，而是应用于所有 API 和 Consumer 的插件。
• 局部插件 → LOCAL
  • 仅仅应用于 API 的插件 → api
    1. 应用于 API 且指定 Consumer 的插件 → api & consumer 特定用户且特定 API 需要执行的插件。这个貌似不太好理解，我这里来举个例子： 假设现在有两个 API: /foo, /bar; 两个 Consumer: c1, c2