今天的一个重点就是要加强对 Kong API Gateway 网关的研究，对于 Kong 网关之前写过两篇文章，今天重点谈下 Kong 网关的插件支持能力。

从上面图可以看到，Kong 网关是基于 OpenResty 应用服务器，OpenResty 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。而 Kong 核心基于 OpenResty 构建，并且拥有强大的插件扩展功能。

在 Http 请求到达 Kong 网关后，转发给后端应用之前，可以通过网关的各种插件对请求进行流量控制，安全，日志等各方面的处理能力。当前 Kong 的插件分为开源版和社区版，社区版还有更多的定制功能，但是社区版是要收费的。

目前，Kong 开源版本一共开放 28 个插件，主要分为五大类，Authentication认证，Security安全，Traffic Control流量控制，Analytics & Monitoring分析&监控，Logging日志，其他还有请求报文处理类。插件类似 AOP 开发中的横切功能，可以灵活的配置进行拦截控制。

附上：
Kong 官网：https://konghq.com/
Kong GitHub地址：https://github.com/kong/kong

下面选择一些关键性的插件进行简单的说明。

黑白名单控制能力（ip-restriction）

Kong 提供的 IP 黑白名单控制能力还算相当强，从配置项里面可以看到主要可以针对两个维度进行配置，是针对所有的 API 接口还是针对特定的 API 接口，一个是针对所有的消费方还是特定的某个消费方。对于 IP 配置可以是一个区段，也可以是特定的 IP 地址。但是黑白名单不能同时配置，其次当前没有一个功能是针对某一个系统提供的所有服务都启用黑名单或白名单功能。

日志记录能力（syslog、file-log、http-log）

这里主要日志的插件比较多，一个是 sysLog 在配置后可以直接将 Kong 产生的日志写入到应用服务器的系统日志文件中。如果配置了 file-log 则是单独写入到你指定的 file 文件中。对于 http-log 则是对于 http 服务请求，可以详细的记录请求的输入和输出报文信息，但是具体是记录到哪里，需要通过 config.http_endpoint 配置。具体关键的配置参数信息如下：

• consumer_id: 可选参数，消费者 id(启用了消费者认证可以使用，根据 id 识别发出请求的消费者)
• config.http_endpoint: 日志接收服务器(包括使用的协议，http or https)
• config.method: 可选参数，默认POST，访问日志服务器的请求方式(可选值:PUT，PATCH，POST);
• config.timeout: 可选参数，默认10000毫秒，请求超时时间
• config.keepalive: 可选参数，默认60000毫秒，连接在关闭之前可存活时间

熔断插件（request-termination）

该插件用来定义指定请求或服务不进行上层服务，而直接返回指定的内容。用来为指定的请求或指定的服务进行熔断。注意 Kong 的熔断插件感觉是临时对服务的禁用，而不是说当达到某一种监控阈值的时候自动触发熔断，或者相关内容还没有了解到。从官方文档的应用场景也可以看到这点。

如果仅仅是这种方式的熔断话，实际上意义并不是很大。但是可用的地方就在于当某个业务系统进行发版部署的时候我们可以对该业务系统或该业务系统所提供的所有服务进行熔断。

限流插件（rate-limiting）

Kong 当前提供的限流相对来说还是比较弱，即主要是控制某一个 API 接口服务在单位时间内最多只能够调用多少次，如果超过这个次数那么网关就直接拒绝访问并返回错误提示信息。限流实际上一个是根据服务调用次数，一个是根据服务调用数据量，需要在这两个方面进行限流。而里面更加重要的反而是数据量的限流，因为大数据量报文往往更加容易造成内存溢出异常。

安全认证类插件

当前 Kong 网关提供 basic-auth，key-auth，oauth2，hmac-auth，jwt，ldap-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 和 routte，以启动 hmac 验证。然后在 Consumers 页面中 Hmac credentials of Consumer 设置中添加一个 username 和 secret。

请求报文容量限制（request-size-limiting）

该插件用于限制请求报文的数据量大小，可以限制单个服务，也可以限制所有的 API 接口服务。

支持Oauth2.0身份认证（oauth2）

Kong 网关支持 Oauth2.0身份认证，Oauth2.0 协议根据使用不同的适用场景，定义了用于四种授权模式。

Authorization code（授权码模式）：标准的 Server 授权模式，非常适合 Server 端的 Web 应用。一旦资源的拥有者授权访问他们的数据之后，他们将会被重定向到 Web 应用并在 URL 的查询参数中附带一个授权码（code）。在客户端里，该 code 用于请求访问令牌（access_token）。并且该令牌交换的过程是两个服务端之前完成的，防止其他人甚至是资源拥有者本人得到该令牌。另外，在该授权模式下可以通过 refresh_token 来刷新令牌以延长访问授权时间，也是最为复杂的一种方式。

Implicit Grant（隐式模式）：该模式是所有授权模式中最简单的一种，并为运行于浏览器中的脚本应用做了优化。当用户访问该应用时，服务端会立即生成一个新的访问令牌（access_token）并通过 URL 的 #hash 段传回客户端。这时，客户端就可以利用 JavaScript 等将其取出然后请求 API 接口。该模式不需要授权码（code），当然也不会提供 refresh token 以获得长期访问的入口。

Resource Owner Password Credentials（密码模式）：自己有一套用户体系，这种模式要求用户提供用户名和密码来交换访问令牌（access_token）。该模式仅用于非常值得信任的用户，例如 API 提供者本人所写的移动应用。虽然用户也要求提供密码，但并不需要存储在设备上。因为初始验证之后，只需将 OAuth 的令牌记录下来即可。如果用户希望取消授权，因为其真实密码并没有被记录，因此无需修改密码就可以立即取消授权。token 本身也只是得到有限的授权，因此相比最传统的 username/password 授权，该模式依然更为安全。

Client Credentials（客户端模式）：没有用户的概念，一种基于 APP 的密钥直接进行授权，因此 APP 的权限非常大。它适合像数据库或存储服务器这种对 API 的访问需求。

简单转换能力（request-transformer、response transformer）

Kong 网关提供对输入和输出报文简单转换的能力，这部分内容后续再详细展开介绍。从当前配置来看，主要是对消息报文提供了Add，Replace，Rename，Append 等各种简单操作能力。