简介
Kong为后台服务提供了多种负载均衡策略，一种是简单的基于 DNS 的方法，还有一种更加动态的 ring-balancer，无需 DNS 服务器就可以实现服务注册
基于 DNS 的负载均衡
当使用基于 DNS 的负载均衡时，后端服务的注册是在Kong之外完成的，Kong只接收来自 DNS 服务器的更新，所有 host 属性里包含 hostname （而不是ip地址）的服务都会自动使用基于 DNS 的负载均衡策略，前提是 hostname 不能解析为 upstream 名或者 hostname 在 DNS hosts 文件里
DNS记录中的 ttl 决定了信息的更新频率，如果 ttl 设置为0，每个请求都会发起DNS查询，显然这会造成性能问题，但是DNS的更新、改变延迟会相对非常低
A records
A record 包含一个或多个IP地址，因此当主机名解析为 A record 时，每个后端服务必须有自己的 IP 地址，因为没有附加权重信息，所以此时负载平衡策略就是简单的轮询策略
SRV records
SRV record 中包含了所有 IP 地址的权重和端口信息，单个后端服务通过IP地址和端口组合标识，所以一个 IP 地址可以在不同端口上启动同一个服务的不同实例，并且由于有权重信息，用户可以将负载均衡配置成加权轮询策略
同样，端口信息都会被 DNS 服务器的端口所覆盖，如果服务的属性为 attributes host=myhost.com 和 port=123，myhost.com 解析为 SRV 记录为 127.0.0.1:456，请求会代理到 http://127.0.0.1:456/somepath，123 端口会被覆盖成 456 端口
DNS 优先级
DNS解析器按顺序解析以下记录类型：
- 上一个解析成功的类型
- SRV 记录 - 添加服务记录服务器服务记录时会添加此项，SRV记录了哪台计算机提供了哪个服务，格式为：服务的名字.协议的类型（例如：_example-server._tcp）
- A记录 - 将域名指向一个IPv4地址（例如：100.100.100.100），需要增加A记录
- CNAME 记录 - 如果将域名指向一个域名，实现与被指向域名相同的访问效果，需要增加CNAME记录
这个顺序可以通过dns_order属性配置
DNS 注意项
- 每当DNS记录刷新时，Kong会生成一份列表正确处理权重信息，计算方式是将权重保持为彼此的倍数，比如17和31的权重配比会生成527条条目，16和32（对应为1和2）的权重配比会生成3条条目，即使
ttl属性为0，Kong也会更新这份列表 - 不是所有的 nameserver 都会返回所有条目（因为UDP包大小的限制，比如Consul只会最多返回3条），这样Kong只会使用 nameserver 提供给它的极少量的 upstream service，这种情况下，upstream service 可能会加载不一致，因为Kong没有有效感知到这些服务存在，想要避免这种情况可以换一类 nameserver，或者使用 IP 地址，而不是名称，或者确保使用足够多的Kong节点可以使用所有的 upstream service
- 当 nameserver 返回
3 name error，这对于Kong是有效响应，如果不想收到这个响应，先检查名称是否正确，再检查 nameserver 的配置是否正确 - 从 DNS 记录中首次挑选 IP 地址不是随机的，所以当
ttl设置为0时，nameserver 会随机记录条目
ring-balancer
当使用 ring-balancer 时，Kong会处理服务的加载和解绑，就不需要DNS更新了，Kong相当于一个服务注册中心，此时可以在节点上添加或删除单个Http请求，以快速接入和断开流量，用户可以通过 upstream 和 target 实体配置 ring-balancer：
-
target：后端服务所在的 IP 地址或者主机名加上端口号，例如192.168.100.12:80，每个target都有一个额外的weight属性标识它的相对负载，IP地址支持 IPv4 和 IPv6 两种格式 -
upstream：虚拟主机名，例如weather.v2.service
Upstream
每个 upstream 都有自己的 ring-balancer，每个 upstream 上可以绑定很多 target 条目，当请求代理到虚拟主机名后会负载均衡到这些 target 上，ring-balancer 有预定数量的槽，并且基于 target 的权重，这些槽会分配给对应的 target
用户可以调用 Admin API 请求添加或者删除 target，这个操作比较轻量，相对来说更改 upstream 本身操作比较重量级，因为 ring-balancer 需要重新构建
只有当清理历史 target 记录时，ring-balancer 会自动构建，除此之外就是收到更改请求
每个 target 使用的插槽数量应该至少大于100，以确保插槽正确分布，例如如果预期最多有8个 target，那么 upstream 至少定义 slots=800，即使最初仅设置两个 target，这里需要权衡的是，插槽数越多，随机分布越好，但修改（增加、删除 target）的成本也变高
更多信息参考 Admin API 的 upstream 章节
Target
因为 upstream 会保留历史的变化，所以只能添加 target，不能修改和删除，如果想要修改 target，只要为此 target 增加一个条目，并且修改权重值，系统将会使用最新添加的条目，如果想将 target 从 ring-balancer 中删除，只需要将其权重设置为0，有关添加和操作 target 的详细信息可以参考 Admin API 的 target 章节
当非活动条目数比活动条目数多10倍时，将自动清除 target，清除将涉及重建 ring-balancer，这比新添加一个 target 条目消耗更高
target 可以是主机名而不是 IP 地址，在这种情况下，Kong会解析主机名，并将所有的条目单独添加到 ring-balancer 中，比如，用户添加主机名为api.host.com:123的条目，权重是100，api.host.com:123主机名可以解析成两个ip地址，那么这两个ip地址对应的条目都会添加到 target 中，并且每个权重均为100
如果主机名解析为 SRV 记录，那么Kong会拾取 DNS 记录对应的端口和权重，并将其覆盖成123端口，且权重为100
ring-balancer 会保留 DNS 记录的 ttl 设置，当它过期后会重新请求并更新 ring-balancer，例外情况：如果一个 DNS 记录的 ttl=0，主机名会被作为单独的 target 配置，当路由到该 target 后，Kong会重新寻找 nameserver
负载均衡策略
默认情况下，ring-balancer 使用加权轮询策略，同时也支持基于哈希算法路由，哈希的输入值可以是 none，consumer，ip，header 或者 cookie，当输入为 none 时，会启用加权轮询策略，哈希策略将失效
一般一组哈希策略会有两个属性值，主属性和 fallback 属性（当主属性不可用时），不同的哈希策略包括：
-
none：不使用哈希策略，使用加权轮询策略（默认） -
consumer：使用消费者Id作为哈希输入，如果没有消费者Id，则降级到使用凭证Id（外部验证比如Idap） -
ip：远程 IP 地址作为哈希输入，使用此选项时，需要确认实际 IP 的配置设置 -
header：使用特定的请求头作为哈希输入，一般为hash_on_header或hash_fallback_header -
cookie：使用特定路径下（hash_on_cookie_path属性，默认是"/"）的特定 cookie 名（hash_on_cookie属性）作为哈希输入，如果请求中不存在 cookie，会在响应中设置，如果cookie作为哈希策略主属性，那么hash_fallback设置将不生效
哈希算法基于散列一致（ketama 原理），当用户修改 target 时（增加、删除、使失效或者更改权重等操作），它会确保修改 ring-balancer 本身修改，保证尽量击中 upstream service，更多信息参考 Admin API 的 upstream 章节
负载均衡注意项
ring-balancer 可用于单节点，也适用于集群，使用加权轮询算法时两者没有太大区别，但使用哈希算法时需要确保所有的节点都使用了完全相同 ring-balancer，为此必须以相同的方式构建 ring-balancer
- 在Kong集群中使用哈希算法时，target 的条目只能添加 IP 地址，不能使用 nameserver
- 在对输入使用哈希算法时，确保输入的值足够多样以获得均匀分布的哈希，哈希值可以通过CRC-32算法计算，比如用户的系统有成千上万的用户，但是仅定义了少量消费者（比如三个消费者：Web，IOS和Android），那么通过消费者定义来计算哈希值是不够的，选择远程
ip地址作为哈希值会得到更好的效果；同理，如果所有的客户端都集中在同一个 NAT 网关下，使用cookie会比使用ip效果更好
蓝绿发布
使用 ring-balancer 可以轻松为服务编排蓝绿部署，仅需发送 PATCH 指令修改 host 就能动态切换 target ，设置蓝色环境，启动服务版本1：
# 创建upstream
curl -X POST http://kong:8001/upstreams --data "name=address.v1.service"
# 在upstream上创建两个target
curl -X POST http://kong:8001/upstreams/address.v1.service/targets --data "target=192.168.34.15:80" --data "weight=100"
curl -X POST http://kong:8001/upstreams/address.v1.service/targets --data "target=192.168.34.16:80" --data "weight=50"
# 创建一个服务指向绿色环境
curl -X POST http://kong:8001/services/ --data "name=address-service" --data "host=address.v1.service" --data "path=/address"
# 最后创建一个路由作为这个服务的端点
curl -X POST http://kong:8001/services/address-service/routes/ --data "hosts[]=address.mydomain.com"
此时，主机名为 address.mydomain.com 的请求会代理到定义的 target，2/3的流量代理到 http://192.168.34.15:80/address（权重为100），1/3的流量代理到 http://192.168.34.16:80/address（权重为50）
在发布服务版本2前，先设置绿色环境：
# 创建绿色环境的upstream
curl -X POST http://kong:8001/upstreams --data "name=address.v2.service"
# 在upstream上创建两个target
curl -X POST http://kong:8001/upstreams/address.v2.service/targets --data "target=192.168.34.17:80" --data "weight=100"
curl -X POST http://kong:8001/upstreams/address.v2.service/targets --data "target=192.168.34.18:80" --data "weight=100"
用户可以更新服务，激活蓝/绿开关：
curl -X PATCH http://kong:8001/services/address-service --data "host=address.v2.service"
现在主机名为 address.mydomain.com 的请求会代理到新的 target，一半的流量代理到 http://192.168.34.17:80/address（权重为100），一半的流量代理到 http://192.168.34.18:80/address（权重为100）
与往常一样，通过Kong Admin API修改权重变化是动态的，并会立即生效，不需要重启也不需要重新加载，也不会丢弃正在进行中的请求
金丝雀发布
使用 ring-balancer 可以精准调节 target 的权重，从而实现平稳、受控的金丝雀发布，这是一个非常简单的调控2个 target的示例：
# Target1 权重为1000
curl -X POST http://kong:8001/upstreams/address.v2.service/targets --data "target=192.168.34.17:80" --data "weight=1000"
# Target2 权重为0
curl -X POST http://kong:8001/upstreams/address.v2.service/targets --data "target=192.168.34.18:80" --data "weight=0"
通过重复这些请求，但每次改变权重，流量将慢慢路由到另一个 target，此处将其设置为10%：
# Target1 权重为900
curl -X POST http://kong:8001/upstreams/address.v2.service/targets --data "target=192.168.34.17:80" --data "weight=900"
# Target2 权重为100
curl -X POST http://kong:8001/upstreams/address.v2.service/targets --data "target=192.168.34.18:80" --data "weight=100"
通过Kong Admin API修改权重变化是动态的，并会立即生效，不需要重启也不需要重新加载，也不会丢弃正在进行中的请求
