当前位置 : 主页 > 网络编程 > ASP >

.Net Core服务治理Consul健康检查

来源:互联网 收集:自由互联 发布时间:2023-01-18
继续上一篇的话题,顺便放上一篇的传送门:点这里。 健康检查 经过之前的操作,我的consul已经支持自动扩展,并且调用也很靠谱。但是这里有个问题,一旦服务列表里的某个服务挂

继续上一篇的话题,顺便放上一篇的传送门:点这里。

健康检查

经过之前的操作,我的consul已经支持自动扩展,并且调用也很靠谱。但是这里有个问题,一旦服务列表里的某个服务挂了,consul并不知道,还是会把实际无效的地址返回给我,就算重启consul容器也无法刷新到最新的状态。所以,咱们要监控服务可用性,主动区分出不可用服务,这种手段,就称之为健康检查。

进入编码环节。老规矩,还是进入到之前我封装好的注册方法,在注册时增加健康检查的内容:

client.Agent.ServiceRegister(new AgentServiceRegistration()
            {
                ID = $"server {ip}:{port}",
                Name = "shenzhen-ma",
                Address = ip,
                Port = int.Parse(port),
                Tags = new string[] { weight },
                Check = new AgentServiceCheck()
                {
                    Interval = TimeSpan.FromSeconds(10),//每隔10秒发起检查
                    HTTP = $"http://{ip}:{port}/v1/client/base/index",//检查请求地址
                    Timeout = TimeSpan.FromSeconds(5),//超时时长5秒
                    DeregisterCriticalServiceAfter = TimeSpan.FromSeconds(10)//超过10秒还没能连接到服务,就开始注销本服务
                }
            });

变色部分就是健康检查的配置了。根据上面的配置,consul会周期性发起健康检查,并且根据结果自动移除不可用的服务。

这次我要严谨一些,用真实的远程服务器来模拟生产环境。手头服务器太多,很多有项目在跑。仔细翻了翻,发现还有两台相对空闲的服务器,一台是win server,另一台centos,嘿嘿,正好。centos做consul服务器,win服务器用来做下游调用方。

先把consul搞起来:

进去访问下:

OK了,现在转到另一台服务器跑几个客户端。这里偷个懒,直接把可运行文件拷贝过去,哈哈:

看下consul控制台:

还是熟悉的shenzhen-ma,两个服务已经稳稳的待在分组列表里了。注意我框起来的位置,它表示服务已经通过了健康检查。这时候我把5051这个程序关掉,再来看看:

5051状态自动更新成failing,而且没过一会儿,它就会自动移除。5050这时候去再去访问,就访问不到5051了:

再然后偷偷把5051跑起来,重新调用:

又可以访问了不是?

新实例启动自动发现,实例状态异常自动剔除,下端调用无需任何调整,舒坦。起码我这个懒人觉得很舒服。

tips:新的服务默认状态是failing,注册成功后会马上发起一次检查,成功后才会变更状态。而且服务注销没有那么快,耗时一般都会比设置的时间长。

最后一点

关于consul写了3篇了,要是都看完,想在项目里用起来是没问题的,不过要上生产环境仍然有个隐患:单点故障。你想啊,consul这么能干,万一它挂了可咋整。。。。所以集群是必要的,而且集群之后的服务注册、调用自然就不能和单体一样。这问题三言两语还说不清,后面再写吧。

到此这篇关于.Net Core服务治理Consul健康检查的文章就介绍到这了。希望对大家的学习有所帮助,也希望大家多多支持自由互联。

网友评论