⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 cnblogs.com/zhoujie/p/kong4.html 「zhoujie」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

负载均衡（Load balancing）是一种计算机网络技术，用来在多个计算机（计算机集群）、网络连接、CPU、磁盘驱动器或其他资源中分配负载，以达到最佳化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。

使用带有负载均衡的多个服务器组件，取代单一的组件，可以通过冗余提高可靠性。负载均衡服务通常是由专用软体和硬件来完成。

对于互联网服务，负载均衡器通常是一个软体程序，这个程序侦听一个外部端口，互联网用户可以通过这个端口来访问服务，而作为负载均衡器的软体会将用户的请求转发给后台内网服务器，内网服务器将请求的响应返回给负载均衡器，负载均衡器再将响应发送到用户，这样就向互联网用户隐藏了内网结构，阻止了用户直接访问后台（内网）服务器，使得服务器更加安全，可以阻止对核心网络栈和运行在其它端口服务的攻击。

当所有后台服务器出现故障时，有些负载均衡器会提供一些特殊的功能来处理这种情况。例如转发请求到一个备用的负载均衡器、显示一条关于服务中断的消息等。负载均衡器使得 IT 团队可以显著提高容错能力。它可以自动提供大量的容量以处理任何应用程序流量的增加或减少。

对于核心 api，需要保证搞可靠性，那么就要对于该 api 有多个 backend service，即实际后端对该 api 有多个服务的节点；那么最好在 api-gateway 即 kong 这一层实现负载均衡。　　Kong为多个后端服务提供了多种负载平衡请求方式：一种基于DNS的简单方法，以及一种更加动态的环平衡器，该方法还允许在不需要DNS服务器的情况下进行服务注册。

基于DNS的负载均衡

当使用基于DNS的负载均衡时，后端服务的注册是在Kong以外完成的，而Kong仅接收来自DNS服务器的更新。如果名称解析为多个IP地址，并且主机名未解析为上游名称或名称，则每个使用包含hostname（而不是IP地址）的host定义的service都将自动使用基于DNS的负载平衡你的DNS hosts文件。 DNS记录ttl设置（生存时间）决定信息刷新的频率。当使用0的ttl时，每个请求都将使用自己的DNS查询来解析。很明显，这会导致性能下降，但更新/更改的延迟将非常低。

A记录

A记录包含一个或多个IP地址。因此，当主机名解析为A记录时，每个后端服务都必须具有自己的IP地址。由于没有weight信息，因此所有条目在负载平衡器中将被视为具有相同的权重，并且平衡器(balancer)将进行简单的循环。

SRV记录

SRV记录包含所有IP地址的权重(weight)和端口(port)信息。后端服务可以通过IP地址和端口号的唯一组合来识别。因此，单个IP地址可以在不同的端口上托管同一服务的多个实例。由于weight信息可用，每个条目将在负载均衡器中获得自己的权重，并执行加权循环。同样，任何给定的端口信息都将被来自DNS服务器的端口信息覆盖。如果服务具有host = myhost.com和port = 123的属性，并且myhost.com解析为具有127.0.0.1:456的SRV记录，则该请求将被代理到http://127.0.0.1:456/somepath，因为123端口将被456覆盖。

DNS优先级

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

上次解析的最后一次成功类型（LAST）
SRV记录
A记录
CNAME记录

该顺序可通过dns_order配置属性进行配置。解析不同记录类型的顺序。 LAST类型表示上次成功查找的类型（用于指定的名称）。格式是一个（不区分大小写）逗号分隔的列表。默认值：LAST，SRV，A，CNAME

DNS警告（DNS caveats）

无论何时刷新DNS记录，都会生成一个列表以正确处理权重。尽量保持权重为对方的倍数以保持算法的高效性，例如，17和31的2个权重将导致具有527个项目的结构，而权重16和32（或其最小的相对对应项1和2）将导致在只有3个条目的结构中，尤其是具有非常小（甚至0）ttl值的结构。
在这些情况下，某些域名服务器不会返回所有条目（由于UDP数据包的大小）（例如Consul最多返回3个），给定的Kong节点将只使用由名称服务器提供的少数上游服务实例。在这种情况下，由于名称服务器提供的信息有限，Kong节点实际上不了解某些实例，因此上游实例池可能会不一致地加载。为了缓解这种情况，可以使用不同的名称服务器，使用IP地址而不是名称，或者确保使用足够的Kong节点来继续使用所有上游服务。
当名称服务器返回3 name error时，那么对于Kong来说这是一个有效的响应。如果这是意外，请首先验证是否正在查询正确的name，然后检查您的nameserver配置。
从DNS记录（A或SRV）中初始选择IP地址不是随机的。因此，当使用ttl为0的记录时，nameserver应该随机记录条目。

环平衡器(ring-balancer)

当使用环平衡器时，添加和删除后端服务将由Kong处理，并且不需要DNS更新。kong将担任服务登记。节点可以通过一个HTTP请求added/deleted，并立即start/stop接收流量。 配置环平衡器是通过上游和目标实体完成的。

target：具有后端服务驻留端口号的IP地址或主机名，例如。 “192.168.100.12:80”。每个target都会得到一个额外的权重来指示它获得的相对负载。 IP地址可以是IPv4和IPv6两种格式。

upstream：可以在路由主机字段中使用的'virtual hostname'，例如，上游命名的weather.v2.service将从具有host = weather.v2.service的服务获得所有请求

上游（upstream）

每个upstream都有自己的环形平衡器。每个upstream可以有许多target条目附加到它，代理到'virtual hostname'的请求将在target上进行负载平衡。环形平衡器具有预定义(pre-defined)数量的槽(number of slots)，并且基于目标权重，槽(slots)被分配给上游的目标。

添加和删除目标可以通过Admin API上的简单HTTP请求完成。这个操作相对便宜。改变上游本身更昂贵，因为例如当槽的数量改变时平衡器将需要重建。

自动重建平衡器的唯一情况是清理目标历史记录时;除此之外，它只会在改变时重建。

在平衡器内部有（从1到slots）的位置，它们随机分布( randomly distributed)在环上。在运行时需要随机性来调用环平衡器。轮子上的简单循环（位置）将为目标提供良好的分布式加权循环，同时在插入/删除目标时也具有廉价的操作。

每个目标使用的插槽数量（至少）应该在100个左右，以确保插槽正确分布。例如。对于预期最多8个目标，即使初始设置仅包含2个目标，上游应至少定义为slot = 800。

这里的折衷是，插槽数量越多，随机分布越好，但更改更为昂贵（添加/删除目标）

有关添加和操作上游的详细信息，请参阅Admin API

目标（target）

由于上游保留了更改历史记录，目标只能添加，不能修改或删除。要更改目标，只需为目标添加一个新条目，然后更改重量值。最后一个条目是将要使用的条目。因为这样的设置权重= 0将禁用目标，有效地从平衡器中删除它。有关添加和操作目标的详细信息，请参阅Admin API参考的目标部分。

当活动条目比活动条目多10倍时，目标将自动清除。清洁将涉及重建平衡器，因此比添加目标条目更昂贵。目标也可以具有主机名而不是IP地址，在这种情况下，名称将被解析，所有找到的条目将被单独添加到环形平衡器中，例如，添加api.host.com:123且权重= 100。名称'api.host.com'解析为具有2个IP地址的A记录。然后这两个IP地址将被添加为目标，每个获得weight = 100和端口123.注意：权重用于单个条目，而不是整个！它是否会解析为SRV记录，然后DNS记录中的端口和权重字段将被拾取，并且会否定给定的端口123和权重= 100。平衡器将遵守DNS记录的ttl设置和重新查询，并在平衡器到期时更新。例外情况：当DNS记录的ttl = 0时，主机名将被添加为具有指定权重的单个目标。在对该目标的每个代理请求时，它将再次查询名称服务器。

平衡算法

默认情况下，环平衡器将使用加权循环方案。另一种方法是使用基于散列的算法。散列的输入可以是none，consumer，ip或header。如果设置为none，则将使用加权循环方案，并且散列将被禁用。

有两种选择，一种primary 和一种回退(fallback)，以防primary失败（例如，如果primary设置为consumer，但没有consumer通过验证）

不同的散列选项：

none：不要使用散列，而是使用weighted-round-robin（默认）。
consumer：使用消费者ID作为散列输入。如果没有消费者ID可用（如果使用外部身份验证，如ldap），此选项将回退到凭证ID。
ip：远程（始发）IP地址将用作输入。在使用此设置时，查看确定真实IP的配置设置。
header：使用指定的标题（在hash_on_header或hash_fallback_header字段中）作为散列的输入。

哈希算法基于'一致哈希'（或'ketama原理'），它确保当平衡器通过改变目标（添加，移除，失败或改变权重）而被修改时，只有最小数量的哈希损失发生。这将最大化上游缓存命中。

有关确切设置的更多信息，请参阅Admin API参考的上游upstream部分。

平衡警告（Balancing caveats）

环平衡器设计为既可以在单个节点上工作，也可以在群集中工作。对于加权循环算法没有太大的区别，但是当使用基于散列的算法时，重要的是所有节点构建完全相同的环平衡器以确保它们都工作一致。要做到这一点，平衡器必须以确定性的方式构建。

不要在平衡器中使用主机名称，因为平衡器可能会/会慢慢发生分歧，因为DNS ttl只有第二精度，更新取决于实际请求名称的时间。最重要的是一些域名服务器没有返回所有条目的问题，这加剧了这个问题。因此，在Kong群集中使用哈希方法时，只能通过IP地址添加目标实体，而不能通过名称添加target实体。

当选择你的散列输入时，确保输入具有足够的方差以得到散布良好的散列。哈希将使用CRC-32摘要进行计算。例如，如果您的系统有成千上万的用户，但只有少数用户（每个平台定义了3个用户：Web，iOS和Android），那么挑选consumer散列输入是不够的，通过设置使用远程IP地址对于ip的哈希将提供更多的输入差异，从而更好地分配哈希输出

蓝绿部署（Blue-Green Deployments）

使用环形平衡器，可以轻松地为一项服务策划一个蓝绿色部署。切换目标基础架构只需要服务上的PATCH请求，即可更改其主机值。

设置“blue”环境，运行version 1 of the address service：

# create an upstream
$ curl -X POST http://kong:8001/upstreams \
    --data "name=address.v1.service"

# add two targets to the upstream
$ 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"

# create a Service targeting the Blue upstream
$ curl -X POST http://kong:8001/services/ \
    --data "name=address-service" \
    --data "host=address.v1.service" \
    --data "path=/address"

# finally, add a Route as an entry-point into the Service
$ curl -X POST http://kong:8001/services/address-service/routes/ \
    --data "hosts[]=address.mydomain.com"

在部署version 2 of the address service之前，请设置“green”环境：

# create a new Green upstream for address service v2
$ curl -X POST http://kong:8001/upstreams \
    --data "name=address.v2.service"

# add targets to the upstream
$ 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"

要激活blue/green开关，现在只需要更新服务:

# Switch the Service from Blue to Green upstream, v1 -> v2
$ curl -X PATCH http://kong:8001/services/address-service \
    --data "host=address.v2.service"

主机头设置为address.mydomain.com的传入请求现在由Kong代理到新目标; 1/2的请求将转到http://192.168.34.17:80/address（权重= 100），另一半将转到http://192.168.34.18:80/address（权重= 100 ）。

与往常一样，通过Kong Admin API进行的更改是动态的，并且会立即生效。不需要重新加载或重新启动，并且没有进行中的请求将被丢弃。

金丝雀版本（Canary Releases）

使用环形平衡器，可以精确调整目标重量，从而实现平稳.。

使用一个非常简单的2 target示例：

# first target at 1000
$ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \
    --data "target=192.168.34.17:80"
    --data "weight=1000"

# second target at 0
$ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \
    --data "target=192.168.34.18:80"
    --data "weight=0"

通过重复请求，但每次改变权重，流量将缓慢路由到另一个target。例如，将其设置为10％：

# first target at 900
$ curl -X POST http://kong:8001/upstreams/address.v2.service/targets \
    --data "target=192.168.34.17:80"
    --data "weight=900"

# second target at 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进行的更改是动态的，并会立即生效。不需要重新加载或重新启动，并且没有进行中的请求将被丢弃。

KONG负载均衡实现

实际在操作过程中，采用的是 kong 的 Ring-balancer 做负载均衡。

使用 Kong Community Edition（社区版 v0.13）来搭建一个负载均衡器，由于 Kong 是基于 Openresty 的，而 Openresty 又是 Nginx 的二次封装，所有很多配置项和 Nginx 类似。

来看一个较为典型的 Nginx 负载均衡配置：

upstream hello {
    server localhost:3000 weight=100;
    server localhost:3001 weight=50;
}

server {
    listen  80;
    location /hello {
        proxy_pass http://hello;
    }
}

nginx 监听来自本地 80 端口的请求，如果路径与 /hello 匹配，便将请求原封不动的转发到名称为 hello 的upstream，而该 upstream 我们配置了一个负载均衡器，会路由到本地的 3000 端口和 3001 端口。

接下来便可以针对 Kong 进行负载均衡的配置了。

配置 upstream 和 target

创建一个名称 hello 的 upstream

curl -X POST http://localhost:8001/upstreams --data "name=hello"

为 hello 添加两个负载均衡节点

curl -X POST http://localhost:8001/upstreams/hello/targets --data "target=localhost:3000" --data "weight=100"
curl -X POST http://localhost:8001/upstreams/hello/targets --data "target=localhost:3001" --data "weight=50"

如上的配置对应了 Nginx 的配置：

upstream hello {
    server localhost:3000 weight=100;
    server localhost:3001 weight=50;
}

配置 service 和 route

使用 Kong v0.13之前版本的用户可能会接触过 api 这个概念，但是在 Kong v0.13.0 中，已经被废除了，取而代之的是 service 和 route 的配置。

配置一个 service

curl -X POST http://localhost:8001/services --data "name=hello" --data "host=hello"

host 的值便对应了 upstream 的名称，配置成功后会返回生成的 service 的 id，返回结果：8695cc65-16c1-43b1-95a1-5d30d0a50409。

为上面的 service 配置路由信息

curl -X POST http://localhost:8001/routes --data "paths[]=/hello" --data "service.id=8695cc65-16c1-43b1-95a1-5d30d0a50409"

请求路径包含 /hello 的请求都会被转移到对应的 service 进行处理。

如上的配置便对应了Nginx的配置：

location /hello {
    proxy_pass http://hello;
}

测试 Kong 的负载均衡

curl http://localhost:8000/hello/hi

因为复杂均衡的原因，需要多测试几次，多次 curl 之后结果如下：

reference：

https://getkong.org/docs/0.13.x/loadbalancing/

https://getkong.org/docs/0.13.x/configuration/

芋道源码 —— 纯源码解析博客

Kong(四)负载均衡理论及实现