Kong 的官方有很多详细的参考说明，比如配置文件、命令行、Admin API、代理、负载均衡，接下来我们简单看一下，都提供什么内容。

本文主要基于 Kong 1.3 版本进行描述，如有更新，请查看最新文档。

配置文件

通过对配置文件的 深入理解，可以优化 Kong 集群、使用的数据库、配置 Nginx ，
官方的参考资料是 Configuration Reference

Kong 在启动时，可以通过 -c 或者 --conf参数来指定配置文件，比如：

kong start -c /path/to/kong.conf

可以使用 check 命令来校验配置文件的语法正确性，

$ kong check 
configuration at 
 is valid 

Kong 的配置在加载的时候也会去找同名的环境变量，所有也可以通过环境变量来配置 Kong，而且环境变量的优先级高于配置文件。可以通过环境变量来配置 Kong 这样方便了基于容器的部署和运行。如果要使用环境变量，需要以 KONG_ 字段开头。

命令行参考

所提供的CLI(命令行接口)允许您启动、停止和管理 Kong 实例。CLI 可以管理本地节点(如在当前机器上)。可以参考官网文档
CLI Reference

主要由如下命令

全局标记

所有的命令都可以使用如下参数

• --help ： 打印命令的帮助信息
• --v ： 打开详情模式
• --vv ： 打开 debug 模式

可用的命令

• kong check 检查配置文件语法等等
• kong config 使用申明式配置文件。
• kong health 检查该节点上的 kong 是否在运行
• kong migration 管理 Kong 的数据库
• kong prepare 此命令准备Kong前缀文件夹及其子文件夹和文件。
• kong quit 优雅的退出 Kong 实例
• kong reload 重载 kong 实例配置
• kong restart 重启 kong 实例
• kong start 启动 kong 实例
• kong stop 停止 kong 实例
• kong version 打印版本信息

Admin API 参考

Admin API 的说明可以参考官网文档：
Admin API Reference

Admin API 接受 2 两种连接类型在每个终端。
分别是

• application/x-www-from-urlencoded
• application/json

共有 9 个对象，分别是：

• Service Object
• Route Object
• Consumer Object
• Plugin Object-Precedence
• Certificate Object
• CA Certificate Object
• SNI Object
• Upstream Object
• Target Object

Proxy 参考

在本文档中，我们将通过详细解释Kong的路由功能和内部工作原理来介绍它的代理功能。

Kong 公开了几个接口，可以通过两个配置属性进行调整:

• proxy_listen，它定义了一个地址/端口列表，Kong将在这些地址/端口上接受来自客户机的公共通信，并将其代理到您的上游服务(默认为8000)。
• admin_listen，它还定义了一个地址和端口列表，但是这些应该被限制为只能由管理员访问，因为它们公开了Kong的配置功能:Admin API(默认情况下为8001)。
  Proxy Reference

Kong 经常用到的术语有：

• client : 指下游客户向 Kong 代理端口发出请求。
• upstream service ：指自己位于 Kong 后面的 API/Service，客户端请求被转发到这些API/Service。
• Service : 顾名思义，服务实体是上游服务的抽象。服务的示例包括数据转换微服务、计费API等。
• Route : 这是指 Kong 路由实体。Route 是进入 Kong 的入口点，并为要匹配的请求定义规则，然后路由到给定的服务。
• Plugin : 指 Kong 的 “plugins”，它是在代理生命周期中运行的业务逻辑片段。插件可以通过管理 API 进行配置——可以是全局的(所有传入的流量)，也可以是在特定的路由和服务上配置。

负载均衡参考

Kong 为多个后端服务提供了多种负载平衡请求的方法: 一种简单的基于 DNS 的方法，另一种是更动态的环形平衡器，该平衡器还允许在不需要DNS服务器的情况下进行服务注册。

负载均衡可以参考官网文档
Load Balancing Reference 来了解。

基于 DNS 的负载均衡

当使用基于 DNS 的负载平衡时，后端服务的注册是在 Kong 之外完成的，而 Kong 只接收来自 DNS 服务器的更新。

如果主机名没有解析为上游名称或 DNS 主机文件中的名称，则使用包含主机名(而不是IP地址)的主机定义的每个服务都将自动使用基于 DNS 的负载平衡。

DNS 记录 ttl 设置(生存时间)决定信息刷新的频率。当使用 ttl 为 0 时，每个请求都将使用自己的 DNS 查询进行解析。这将带来性能损失，但是更新/更改的延迟将非常低。

A 记录

一个 A 记录对应一个或者多个 IP 地址，因此，当主机名解析为 A 记录时，每个后端服务必须有自己的IP地址。

因为没有权重信息，所以所有条目在负载平衡器中都将被视为同等权重，并且平衡器将进行直接的循环。

SRV 记录
SRV记录包含所有IP地址的权重和端口信息。后端服务可以通过IP地址和端口号的唯一组合来标识。因此，一个IP地址可以在不同的端口上承载相同服务的多个实例。

因为权重信息是可用的，所以每个条目将在负载平衡器中获得自己的权重，并执行加权循环。

DNS 的优先级

1、前面解析的最后一个成功类型
2、SRV 记录
3、A记录
4、CNAME 记录

这些可以在配置文件的 dns_order 进行配置。

基于 Ring-balancer 的负载均衡

使用 Ring-balancer 时，后端服务的添加和删除将由 Kong 处理，不需要 DNS 更新。Kong 将作为服务注册处。节点可以通过一个HTTP请求添加/删除，并将立即启动/停止接收流量。

配置 Ring-balancer 工作需要有 Upstream 和 target 两个实体。

• target ： 带有后端服务所在端口号的IP地址或主机名，例如。“192.168.100.12:80”。每个目标都获得一个额外的权重，以指示它获得的相对负载。IP地址可以是IPv4和IPv6格式。
• upstream ： 一个 virtual hostname，可用于路由的 host 字段，例如一个 upstream 是 weather.v2 会收到服务 host=weather.v2.service 的所有请求。

小结

本来大致讲述了 Kong 的配置文件、命令行、代理、负载均衡等内容。