Kong 的官方有很多详细的参考说明，比如配置文件、命令行、Admin API、代理、负载均衡，接下来我们简单看一下，都提供什么内容。
本文主要基于 Kong 1.3 版本进行描述，如有更新，请查看最新文档。
配置文件
通过对配置文件的 深入理解，可以优化 Kong 集群、使用的数据库、配置 Nginx ，
官方的参考资料是 Configuration Reference
Kong 在启动时，可以通过 -c 或者 --conf参数来指定配置文件，比如：
kong start -c /path/to/kong.conf可以使用 check 命令来校验配置文件的语法正确性，
$ kong check <path/to/kong.conf>
configuration at <path/to/kong.conf>
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 的配置文件、命令行、代理、负载均衡等内容。
