序言
通过上篇你应该了解到了如何使用kong实现动态的负载均衡,以及kong提供的环形均衡器的作用。
本篇将在环形均衡器的基础上,讲解如何实现健康检查与熔断。
健康检查
在当下复杂的网络环境与现实环境众多因素的影响中,单台主机发生故障的几率大大提升。我们在现实业务中,需要了解每台主机的情况。
一个大栗子:
我们的工作如同路面施工者,
对坏的路面需要维修,
同时在坏的路面前方防止障碍物,让车辆避过,行驶在安全无危险的路面上。
大栗子解析:
开开心心上班的你
发现某个服务器宕机了
将流量引到其他服务器
在这里kong允许我们检查上游服务所配置的多个目标是否在正常工作。如果出现目标工作失败现象,流量将被引导向正常工作目标。
kong将检查部分分为主动检查与被动检查(断路器)。
主动检查
kong将定期主动请求http与https目标,并对目标响应判断其健康与否,并且自动在环形均衡器中禁止此目标。
熔断
此处称为被动健康检查,是我们常说的断路器。当发生问题后可以主动断开连接。本篇将称呼其为被动健康检查。
kong将请求转发到目标后,当目标变得无响应,断路器将检查到这一问题,并将之标记为不健康。kong提供的环形均衡器将跳过这一目标,达到熔断的目的。
恢复
通过kong提供的管理员API可以非常方便的回复目标健康状态。
注意:
kong不会主动恢复标记健康,需人工操作。
恢复后广播所有节点,节点重置健康记录,恢复服务。
优缺点
被动检查不消耗额外流量,是在对目标正常访问过程中标记的。主动检查需要额外的定时检查。
主动检查无需人工操作,被动检查需要我们操作api恢复。
主动检查会将健康目标配置为探测端点,环形均衡器将向配置为探测端点的每个网络端点转发流量。被动则无需。
业务应用
在具体业务中,我们一般将两种方式结合起来。
被动检查检测目标健康状态,实行标记。
主动检查在目标不健康时应用,这个时候目标可以自行启动,环形均衡器正常分配流量。
emmm所以嘛~~被动恢复的api本篇不介绍^^
源代码
健康检查是在upstream上开启配置的。
/**
* @author: 飘逸的罗伯特
*/
//创建名字为 upstream02 的 upstream
$upstream_data = [
'name' => 'upstream01',
'healthchecks.active.type' => 'http' //探头配置 此处可选【http https tcp】 默认http
//============================================主动检查============================================
'healthchecks.active.http_path' => '/' //主动检测get http请求使用路径
'healthchecks.active.timeout' => 1, //主动检查超时时间 此处设置1秒
'healthchecks.active.concurrency' => 10, //同时主动检查目标数量设置
'healthchecks.active.healthy.interval' => 0, //健康目标主动检查每隔几秒进行 0表示不进行
'healthchecks.active.unhealthy.interval' => 1, //不健康目标主动检查每隔几秒进行 此处设置1秒
'healthchecks.active.unhealthy.timeouts' => 10, //主动检查认为目标不健康的超时时间
//一起配合使用 当检测到响应为对应状态码指定次数,将标记目标为健康
'healthchecks.active.healthy.successes' => 1, //主动检查认为目标健康的成功次数
'healthchecks.active.healthy.http_statuses' => [200, 302], //主动检查健康状态码
//一起配合使用 当检测到响应为对应状态码指定次数,将标记目标为不健康
'healthchecks.active.unhealthy.http_failures' => 1, //主动检查认为目标不健康的失败次数
'healthchecks.active.unhealthy.http_statuses' => [500,505], //主动检查不健康状态码
//============================================被动检查============================================
'healthchecks.passive.unhealthy.timeouts' => 10, //被动检查认为目标不健康的超时时间
//一起配合使用 当检测到响应为对应状态码指定次数,将标记目标为健康
'healthchecks.passive.healthy.successes' => 1, //被动检查认为目标健康的成功次数
'healthchecks.passive.healthy.http_statuses' => [200, 302], //被动检查健康状态码
'healthchecks.passive.unhealthy.http_failures' => 1, //被动检查认为目标不健康的成功次数
'healthchecks.passive.unhealthy.http_statuses' => [500,505], //被动检查不健康状态码s
];
http_request('http://hz12.cn:8001/upstreams', $upstream_data);
/**
* 发送post请求
* @param [string] $url 请求地址
* @param [array] $postdata post参数
* @return [ar] [description]
*/
function http_request($url, $postdata=[]){
$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, $url);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($curl, CURLOPT_POST, 1);
curl_setopt($curl, CURLOPT_POSTFIELDS, $postdata);
$data = curl_exec();
curl_close($curl);
return $data;
}
作者最后的话
运行效果与上篇一致,宕机的目标不会被分配到流量,恢复工作的目标将重新被分配流量。
emmmm就不截图了~~
转载自CSDN-专业IT技术社区
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。