|
51 | 51 |
|
52 | 52 | 1. 核心: 由 Kong(配置 upstream 和 target) 充当服务注册中心, 通过槽位和权重在 target 间负载 |
53 | 53 | 2. **每个 upstream 都有自己的环形均衡器**和多个 target(通过一个 HTTP 请求被添加/删除节点) |
| 54 | + |
54 | 55 | - 一个环形均衡器有一个最大的预定义槽位数, 根据 target 权重分配槽位: `权重最好是倍数关系(方便均衡器性能)` |
55 | 56 | - 在均衡器中, 从 1 到 slots **随机**地分布在环上 |
56 | 57 | - 当插槽数量发生变化时需要重建均衡器 |
| 58 | + |
57 | 59 | 3. rb 可以再单节点和集群种使用: 所有节点都要建立完全相同的环形均衡器, 以确保它们都能正常工作 |
| 60 | + |
58 | 61 | - 轮询算法时没有区别 |
59 | 62 | - hash 时则一定要使用 Ip 而不是域名 |
60 | 63 |
|
61 | 64 | ## 健康检查 |
62 | 65 |
|
63 | | -1. 主动检查: 定期请求 target 中的特定 HTTP 或 HTTPS 端点, 并根据其响应确定 target 的健康状况 |
| 66 | +1. 相关注意点说明 |
| 67 | + |
| 68 | + - 健康信息不会在集群中同步, 每个 Kong 节点分别确定其目标的健康状况: 避免 kong 节点的网络分区 |
| 69 | + - 健康检查仅对活动目标进行操作, 不会修改 Kong 数据库中 target 的活动状态 |
| 70 | + - 不健康的目标不会从负载均衡器中删除, 因此在使用 hash 算法时不会对均衡器布局产生任何影响(它们只会被跳过) |
| 71 | + - 禁用健康检查: 把计数器阈值或者间隔设置为零 |
| 72 | + |
| 73 | +2. 主动检查: 定期请求 target 中的特定 HTTP 或 HTTPS 端点, 并根据其响应确定 target 的健康状况 |
64 | 74 |
|
65 | 75 | - 主动健康检查目前只支持 HTTP/HTTPS, 且时间间隔设置为 0 则表示禁用检查 |
66 | 76 | - pros: 主动健康检查可以在 target 恢复健康时, 自动重新启用环形均衡器中的 target + 可以恢复被动检查导致的不健康 |
67 | 77 | - cons: 主动健康检查会对 target 产生额外的流量 + 且需要指定端点 |
68 | 78 |
|
69 | | -2. 被动检查: 断路器, 分析代理的流量并根据其响应确定 target 的健康状况(且无法自动恢复健康) |
| 79 | +3. 被动检查: 断路器, 分析代理的流量并根据其响应确定 target 的健康状况(且无法自动恢复健康) + 谨慎使用(可能误判) |
70 | 80 |
|
71 | 81 | - nginx 会监测代理的请求并根据响应状态决定是否转发流量到改服务 |
72 | 82 | - nginx 的上游服务的响应状态在短时间内累计一定的失败次数时, 会将其标记该服务器异常: 然后就不会转发流量给该服务器 |
73 | 83 | - nginx 每隔一段时间还是会转发少量的一些请求给该后端服务器来探测它的返回状态: 以便识别该服务器是否恢复正常 |
| 84 | + - 在客户端请求数量大于主动探测发起的请求时, **被动健康检查响应速度更快** |
74 | 85 |
|
75 | | -3. **主动检查&被动检查 最佳实践: 可以启用被动健康检查, 仅根据其流量监测目标的健康状况, 只在目标不健康时使用主动健康检查, 以便自动重新启用它** |
76 | | -4. 健康检查仅对活动目标进行操作, 不会修改 Kong 数据库中 target 的活动状态 |
77 | | -5. 不健康的目标不会从负载均衡器中删除, 因此在使用 hash 算法时不会对均衡器布局产生任何影响(它们只会被跳过) |
78 | | -6. upstream 也有健康概念: upstream 的健康状况取决于其 target 的状态 |
| 86 | +4. **主动检查&被动检查 最佳实践: 可以启用被动健康检查, 仅根据其流量监测目标的健康状况(快速), 只在目标不健康时使用主动健康检查, 以便自动重新启用它** |
| 87 | +5. upstream 也有健康概念: upstream 的健康状况取决于其 target 的状态 |
79 | 88 | - healthchecks.threshold=55: 权重的百分比 |
80 | 89 | - ups 进入不健康的状态, upstream 将只返回错误: target 恢复时, 环形均衡器的健康状态将自动更新 |
81 | 90 |
|
82 | 91 | ## target: host+port+weight |
83 | 92 |
|
84 | 93 | 1. 当不活跃的条目比活跃的条目多 10 倍时, target 将被自动清理: 此时 rb 会重建(代价比较大) |
85 | 94 | 2. 健康检查器会根绝健康检查更新一系列的内部计数器 |
| 95 | + |
86 | 96 | - 如果连接失败, 则增加 target 的 TCP 失败计数器并清除成功计数器 |
87 | 97 | - 如返回健康的状态码, 则增加 target 的成功计数器并清除其所有其他计数器 |
88 | 98 | - 如返回不健康的状态码, 则增加 target 的 HTTP 失败计数器并清除成功计数器 |
89 | 99 | - 如果超时, 它将增加 target 的超时计数器并清除成功计数器 |
| 100 | + |
90 | 101 | 3. 健康的定义 |
91 | | - - 健康信息不会在集群中同步, 每个 Kong 节点分别确定其目标的健康状况 |
| 102 | + |
92 | 103 | - 不健康: 任何 TCP 失败、HTTP 失败或超时计数器达到其配置的阈值, target 都不可用时会返回 503 |
93 | 104 | - 健康: 成功计数器达到其配置的阈值 |
94 | 105 |
|
|
98 | 109 |
|
99 | 110 | 1. https://www.jianshu.com/p/b44400618c69 |
100 | 111 | 2. https://github.com/Alice52/diagrams/blob/master/diagrams/lb/nginx/conf/03.upstream.svg |
| 112 | +3. https://cloud.tencent.com/developer/article/2131227 |
| 113 | +4. https://blog.csdn.net/tao_627/article/details/79298904 |
0 commit comments