序言
通过上篇你应该了解到了如何使用kong实现动态的负载均衡，以及kong提供的环形均衡器的作用。
本篇将在环形均衡器的基础上，讲解如何实现健康检查与熔断。
健康检查
在当下复杂的网络环境与现实环境众多因素的影响中，单台主机发生故障的几率大大提升。我们在现实业务中，需要了解每台主机的情况。
-
一个大栗子：
-
- 我们的工作如同路面施工者，
- 对坏的路面需要维修，
- 同时在坏的路面前方防止障碍物，让车辆避过，行驶在安全无危险的路面上。
大栗子解析：
-
- 开开心心上班的你
- 发现某个服务器宕机了
- 将流量引到其他服务器
在这里kong允许我们检查上游服务所配置的多个目标是否在正常工作。如果出现目标工作失败现象，流量将被引导向正常工作目标。
kong将检查部分分为主动检查与被动检查（断路器）。
主动检查
kong将定期主动请求http与https目标，并对目标响应判断其健康与否，并且自动在环形均衡器中禁止此目标。
熔断
此处称为被动健康检查，是我们常说的断路器。当发生问题后可以主动断开连接。本篇将称呼其为被动健康检查。
kong将请求转发到目标后，当目标变得无响应，断路器将检查到这一问题，并将之标记为不健康。kong提供的环形均衡器将跳过这一目标，达到熔断的目的。
恢复
通过kong提供的管理员API可以非常方便的回复目标健康状态。
注意：
- kong不会主动恢复标记健康，需人工操作。
- 恢复后广播所有节点，节点重置健康记录，恢复服务。
优缺点
- 被动检查不消耗额外流量，是在对目标正常访问过程中标记的。主动检查需要额外的定时检查。
- 主动检查无需人工操作，被动检查需要我们操作api恢复。
- 主动检查会将健康目标配置为探测端点，环形均衡器将向配置为探测端点的每个网络端点转发流量。被动则无需。
业务应用
在具体业务中，我们一般将两种方式结合起来。
- 被动检查检测目标健康状态，实行标记。
- 主动检查在目标不健康时应用，这个时候目标可以自行启动，环形均衡器正常分配流量。
emmm所以嘛~~被动恢复的api本篇不介绍^^
源代码
健康检查是在upstream上开启配置的。
<?php
/**
* @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就不截图了~~