.Net Core服务治理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健康检查的文章就介绍到这了。希望对大家的学习有所帮助，也希望大家多多支持我们。

赞 (0)

相关推荐

  • .Net Core服务治理Consul搭建集群

    .Net Core服务治理Consul搭建集群

    延续上一篇的话题继续,顺便放上一篇的传送门:点这里. 集群的必要性 consul本身就是管理集群的,现在还需要给consul搞个集群,这是为啥?因为consul单点也容易挂啊!万一管理集群的consul挂掉了,那么相当于上下游应用都变成了瞎子,看不到也调不到.所以集群的必要性不用我说了吧? Server & Client 生产环境下,可以选择上面两种模式,下面我就简称S端.C端.说说它俩有啥不一样: S端: 1.数量不宜过多,一般推荐3.5个,要求是奇数. 2.持久化保存节点数据. 3.多个S端

  • .Net Core服务治理Consul使用服务发现

    .Net Core服务治理Consul使用服务发现

    先思考一些问题:它是做什么的.以及怎么使用它.带着这些问题往下走. consul是做什么的 consul用于微服务下的服务治理.服务治理是什么?它包含但不限于:服务发现.服务配置.健康检查.键值存储.安全服务通信.多数据中心等. 为什么需要服务治理?举个例子:最开始的服务比较简单,各服务之间通过API就能访问.后面业务复杂了,服务也跟着复杂了,搞分布式了,而分布式又必然是多服务器部署,这就有一个问题:如果服务之间还是用API访问,那某个服务所在的服务器挂掉以后这个服务就不能用了,也不能自动转移,

  • .Net Core服务治理Consul自动扩展和服务调用

    .Net Core服务治理Consul自动扩展和服务调用

    今天有写文章的时间了,开心.延续上一篇的话题继续,顺便放上一篇的传送门:点这里. 服务调用 既然服务注册已经搞完了,那么现在就开始调用这些注册好的服务.先做一下准备动作,把consul容器跑起来: 打开控制台确认正常: 然后多跑几个应用程序模拟多点部署: 程序跑完以后检察一下服务列表: 戳进去看看: 一切准备就绪,完美.然后进入编码环节.老规矩,直接上码: public static string Convert(string consulUri, string centerName, stri

  • .Net Core微服务网关Ocelot集成Consul

    .Net Core微服务网关Ocelot集成Consul

    有consul基础的都知道,consul可以发现新增的服务,剔除掉无效的服务,赋予应用自动伸缩的能力.而ocelot如果集成了consul,那ocelot也能拥有这些能力,还可以自主选择负载均衡策略,灵活性更强. (建议看完前一篇文章再来实践这一篇,不然可能有难度) 上干货. 首先打开上一篇新建好的项目,继续添加nuget包: 然后注册相关服务: public void ConfigureServices(IServiceCollection services) { services.AddOc

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

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

    继续上一篇的话题,顺便放上一篇的传送门:点这里. 健康检查 经过之前的操作,我的consul已经支持自动扩展,并且调用也很靠谱.但是这里有个问题,一旦服务列表里的某个服务挂了,consul并不知道,还是会把实际无效的地址返回给我,就算重启consul容器也无法刷新到最新的状态.所以,咱们要监控服务可用性,主动区分出不可用服务,这种手段,就称之为健康检查. 进入编码环节.老规矩,还是进入到之前我封装好的注册方法,在注册时增加健康检查的内容: client.Agent.ServiceRegister

  • 详解如何在ASP.Net Core中实现健康检查

    详解如何在ASP.Net Core中实现健康检查

    健康检查 常用于判断一个应用程序能否对 request 请求进行响应,ASP.Net Core 2.2 中引入了 健康检查 中间件用于报告应用程序的健康状态. ASP.Net Core 中的 健康检查 落地做法是暴露一个可配置的 Http 端口,你可以使用 健康检查 去做一个最简单的活性检测,比如说:检查网络和系统的资源可用性,数据库资源是否可用,应用程序依赖的消息中间件或者 Azure cloud service 的可用性 等等,这篇文章我们就来讨论如何使用这个 健康检查中间件. 注册健康检查

  • SpringBoot-Admin实现微服务监控+健康检查+钉钉告警

    SpringBoot-Admin实现微服务监控+健康检查+钉钉告警

    基于SpringCloud微服务平台,进行服务实例监控及健康检查,注册中心为eureka,SpringBoot提供了很好的组件SpringBoot Admin,2.X版本直接可以配置钉钉机器人告警. 效果:可以实现eureka注册的实例上线.下线触发钉钉告警.监控我们的服务实例健康检查. 搭建admin-server pom依赖 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="

  • 详解springcloud组件consul服务治理

    详解springcloud组件consul服务治理

    Consul是一款由HashiCorp公司开源的,用于服务治理的软件,Spring Cloud Consul对其进行了封装.Consul具有如下特点: 服务注册 - 自动注册和取消注册服务实例的网络位置 运行状况检查 - 检测服务实例何时启动并运行 分布式配置 - 确保所有服务实例使用相同的配置 Consul agent有两种运行模式:Server和Client.这里的Server和Client只是Consul集群层面的区分,与搭建在Cluster之上 的应用服务无关. 以Server模式运行的

  • .Net Core实现健康检查的示例代码

    ASP.NET Core 提供运行状况检查中间件和库,以用于报告应用基础结构组件的运行状况. 运行状况检查由应用程序作为 HTTP 终结点公开. 可以为各种实时监视方案配置运行状况检查终结点: 运行状况探测可以由容器业务流程协调程和负载均衡器用于检查应用的状态. 例如,容器业务流程协调程序可以通过停止滚动部署或重新启动容器来响应失败的运行状况检查. 负载均衡器可以通过将流量从失败的实例路由到正常实例,来应对不正常的应用. 可以监视内存.磁盘和其他物理服务器资源的使用情况来了解是否处于正常状态.

  • 如何给asp.net core写个简单的健康检查

    如何给asp.net core写个简单的健康检查

    Intro 健康检查可以帮助我们知道应用的当前状态是不是处于良好状态,现在无论是 docker 还是 k8s 还是现在大多数的服务注册发现大多都提供了健康检查机制来检测应用的健康状态,如果应用本身就提供一个健康检查的机制会更友好,更能真实的反映出应用的健康状态. 我们的开发环境虚拟机配置有点低,所以有时候虚拟机会卡死..导致接口无响应,有时可能有些服务启动有问题会挂掉,所以需要一个简单的健康检查机制去检查应用的健康状态来第一时间知道应用出现异常. 健康检查扩展实现 实现源码 public sta

  • SpringCloud微服务架构实战之微服务治理功能的实现

    SpringCloud微服务架构实战之微服务治理功能的实现

    微服务治理 Spring Cloud 工具套件为微服务治理提供了全面的技术支持.这些治理工具主要包括服务的注册与发现.负载均衡管理.动态路由.服务降级和故障转移.链路跟踪.服务监控等.微服务治理的主要功能组件如下: 注册管理服务组件Eureka,提供服务注册和发现的功能. 负载均衡服务组件Ribbon,提供负载均衡调度管理的功能. 边缘代理服务组件Zuul,提供网关服务和动态路由的功能. 断路器组件Hystrix,提供容错机制.服务降级.故障转移等功能. 聚合服务事件流组件Turbine,可用来

随机推荐