微服务Kong（十）——负载均衡参考

　　KONG为请求多个后端服务提供了多种负载均衡方案：一种是简单的基于DNS，另一种是更加动态的环形均衡器，他在不需要DNS服务器的情况下也允许服务注册。

一、基于DNS的负载均衡

　　当使用基于DNS的负载平衡时，后端服务的注册是在Kong之外完成，而Kong只接收来自DNS服务器的更新。如果请求的API被解析为多个IP地址，则已使用包含主机名（而不是IP地址）的upstream_url定义的每个API将自动使用基于DNS的负载平衡，前提是主机名未被解析为upstream名称或你的localhosts文件中的名称。DNS记录ttl设置（生存时间）确定刷新信息的频率。当设置ttl为0时，每个请求将使用自己的dns查询进行解析。显然这会带来性能损失，但更新/更改的延迟将非常低。

1. A记录

　　A记录包含一个或多个IP地址。因此，当主机名解析为A记录时，每个后端服务都必须有自己的IP地址。因为没有 weight 信息，所有条目在负载平衡器中将被视为同样的权重，平衡器将进行直线循环。来自DNS记录的IP地址的初始选择是随机的。这是为了确保即使当ttl为0时，负载也正确分配。

2. SRV记录　　

　　SRV记录包含所有IP地址的权重和端口信息。可以通过唯一的IP端口号的组合来标识后端服务。因此，单个IP地址可以托管不同端口上相同服务的多个实例。因为权重信息可用，每个条目将在负载平衡器中获得自己的权重，并且它将执行加权循环。

　　类似地，任何给定的端口信息将被来自DNS服务器的端口信息覆盖。如果一个API的 upstream_url=http://myhost.com:1234/path 并且 myhost.com 被解析为 SRV 记录中的 127.0.0.1:5678，此时的API将会被代理到 http://127.0.0.1:5678/path，之前的 1234 端口会被重写为 5678 端口。IP地址+端口组合在初始时是随机选择的，这是为了确保服务能被正确分配，即使ttl设置为0。

　　tip：每当刷新DNS记录时，都会生成列表以正确处理加权。建议将权重保持为彼此的倍数以保证系统的性能。

3. DNS的优先级

　　DNS解析器按顺序开始解析以下记录类型：

　　> 1. 最后一个成功的类型优先解析；

　　> 2. SRV记录

　　> 3. A记录

　　> 4. CNAME记录

　　所以，如果你使用的主机名称中同时含有SRV记录和A记录时，将仅解析SRV实例。如果你想使用A记录，那么你必须得把SRV记录从DNS中删除。如果你只有A记录，则SRV记录查询失败，然后自动指向到A记录，并查询A记录是否存在，依次类推。

二、环形均衡器

　　使用环形平衡器时，后台服务的添加和删除将由Kong处理，不需要进行DNS更新。KONG将扮演服务注册的角色。可以通过单个HTTP请求添加/删除节点，并可立即启动/停止接收请求流量。

　　可以通过配置 upstream 和 target 属性来配置环形均衡器。

　　· upstream： 在API中把一个虚拟主机名称配置到upstream属性里。例如：一个weather.service的主机可以接收所有类似于http://weather.service/path/xxx/...的请求。

　　· target： 后台服务所在的IP和端口号的组合。例如：192.168.11.48:8080。每一个target都附加有一个weight属性来指示获得的相对负载。

1. upstream上游服务

　　每一个上游服务都有他自己的环形均衡器。每一个upstream都可以有多个target属性，代理到虚拟主机名的请求会被均衡到每个target上。环形平衡器具有预定义的槽数，基于target的权重，每个target会分配到一定数量的槽。进来的请求将会以加权循环方式进行代理。添加或删除一个target可以用管理员身份，通过一个简单的HTTP请求来完成。这种操作比较简单省事，然而相对的，如果要改变上游服务本身，则相当繁琐，譬如要重建负载，重新分配槽数等。

　　平衡器自动重建的唯一情况是清除target的历史记录；除此之外，它只会在更改时重建。

　　在平衡器中，环上有位置（从1到插槽总数量），每个都有一个“1”对齐的“插槽”。因此，还存在时隙数量的时隙，但它们随机分布在环位置上。这个随机性可以通过使用orderlist来设置，但是我们强烈反对这样做。在运行时廉价的调用环形均衡器时才会使用随机分配。轮到一个简单的循环（位置）将提供一个分布均匀的加权轮回目标，同时在插入/删除目标时也有廉价的操作。

2. 目标服务

三、Blue-Green 部署

四、Canary发布