[转]Eureka自我保护机制、健康检查的作用、actuator模块监控

  • Eureka自我保护机制

接着以上篇文章建立的三个工程为基础(eureka-server,uerreg,myweb),默认Eureka是开启自我保护的。我们来做个测试,我们先启动三个工程,我们访问注册中心http://localhost:8761/,

image.png

可以看到,实例是成功注册到中心的。此时我们将uerreg服务关闭,刷新注册中心,我们会发现如下界面

image.png

我们除了看到了一行红色的警告信息,还发现了一件神奇的事情,就是我们的服务实例虽然被kill了,但是在服务注册中心他还是存在的。这就是Eureka自我保护机制,他不会剔除已经挂掉的服务,他会认为这个服务是在尝试重新连接的。
我们在开发过程中肯定是不希望这样的,不利于开发。我们可以关闭Eureka的自我保护机制(实际生产环境不建议关闭)。

  • eureka-server服务端
    配置文件中我们添加如下配置
#关闭保护机制,以确保注册中心将不可用的实例正确剔除
eureka.server.enable-self-preservation=false
#(代表是5秒,单位是毫秒,清理失效服务的间隔 )
eureka.server.eviction-interval-timer-in-ms=5000
  • userreg客户端
    配置文件中我们添加如下配置
# 心跳检测检测与续约时间
# 测试时将值设置设置小些,保证服务关闭后注册中心能及时踢出服务
# 配置说明
#  lease-renewal-interval-in-seconds 每间隔10s,向服务端发送一次心跳,证明自己依然”存活“
#  lease-expiration-duration-in-seconds  告诉服务端,如果我20s之内没有给你发心跳,就代表我“死”了,将我踢出掉。
eureka.instance.lease-renewal-interval-in-seconds=10
eureka.instance.lease-expiration-duration-in-seconds=20

  

我们重新启动服务,然后关闭userreg客户端进行测试。

此时我们发现,红色警告变成了自我保护被关闭的警告,且实例被注册中心剔除,表明此时自我保护机制被关闭。

  • 健康检查

人会生病,就像人一样服务有时候也会出现异常情况,我们也需要知道某个服务的健康状况。我们可以通过添加如下依赖,开启某个服务的健康检查。以userreg服务为例
pom文件中添加如下依赖

<!--健康检查依赖-->
       <dependency>
           <groupId>org.springframework.boot</groupId>
           <artifactId>spring-boot-starter-actuator</artifactId>
       </dependency>

  

ok,其他的什么都不变,我们来访问一下这个接口http://localhost:9001/health
我们看到了一个很简短的健康报告:{"description":"Spring Cloud Eureka Discovery Client","status":"UP"},类似的还有

info 显示任意的应用信息
metrics 展示当前应用的指标信息 true
mappings 显示所有@RequestMapping路径的整理列表
trace 显示trace信息(默认为最新的一些HTTP请求)
health 展示应用的健康信息
beans 显示一个应用中所有Spring Beans的完整列表

这其中有一些是敏感信息,出于安全考虑,如果不设置

#关掉认证(公网下的生产环境不建议,内网部署可以)
#management.security.enabled=false

默认是无法访问的。
如果我们要访问查看而且想保证一定的安全性,我们应该做什么呢?我们在userreg的pom文件中引入

<!--安全认证依赖-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-security</artifactId>
        </dependency>

  

此时我们访问/beans敏感信息时,弹出如下信息,需要我们进行身份认证

仅仅引入依赖其实是有问题的,因为我们请求正常的业务接口他也会要求进行认证,解决办法可以在userreg工程的配置文件中添加如下设置:

#(增加了访问路径)
management.context-path=/admin
security.user.name=root
security.user.password=123
#只对/admin进行安全认证
security.basic.path=/admin

重启服务,我们访问http://localhost:9001/admin/beans,注意哦,我们在配置文件中添加了相对路径,只对admin进行验证,此时我们输入正确的用户名和密码(已在配置文件中配置)会显示我们需要的信息。

  • 实战健康检查

健康检查在实际应用场景中有哪些呢?举个例子,我们配置userreg工程数据源
在pom文件中引入以下依赖

<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-jdbc</artifactId>
        </dependency>
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
        </dependency>

然后建立一个配置类,配置数据源DataSource

@Configuration
public class Myconfig {
   @Bean
   public DataSource dataSource()
   {
       org.apache.tomcat.jdbc.pool.DataSource dataSource=new org.apache.tomcat.jdbc.pool.DataSource();
       dataSource.setUrl("jdbc:mysql://localhost/test?characterEncoding=UTF-8");
       dataSource.setUsername("root");
       dataSource.setPassword("mysql");
       dataSource.setDriverClassName("com.mysql.jdbc.Driver");
       return dataSource;
   }
}

这个在springboot中已经学习过,后续我会把springboot学习过程以博客的方式记录下来,配置完成数据源之后,我们启动服务,访问http://localhost:9001/admin/health 查看健康情况

image.png

我们可以看到db的健康情况。假如此时我们的mysql服务挂掉,会怎样呢?

image.png

我们手动停止mysql服务,然后再看健康情况

image.png

发现db状态已经由“UP”变成了“DOWN”并显示了错误信息,这样就很方便我们查看服务的健康情况了。

作者:谜00016
链接:https://www.jianshu.com/p/df61a3273528
來源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

原文地址:https://www.cnblogs.com/gengaixue/p/9216020.html

时间: 2024-10-07 15:52:54

[转]Eureka自我保护机制、健康检查的作用、actuator模块监控的相关文章

springcloud Eureka自我保护机制

自我保护背景 首先对Eureka注册中心需要了解的是Eureka各个节点都是平等的,没有ZK中角色的概念, 即使N-1个节点挂掉也不会影响其他节点的正常运行. 默认情况下,如果Eureka Server在一定时间内(默认90秒)没有接收到某个微服务实例的心跳,Eureka Server将会移除该实例.但是当网络分区故障发生时,微服务与Eureka Server之间无法正常通信,而微服务本身是正常运行的,此时不应该移除这个微服务,所以引入了自我保护机制. 自我保护机制 官方对于自我保护机制的定义:

Spring Cloud之Eureka自我保护环境搭建

Eureka详解 服务消费者模式 获取服务 消费者启动的时候,使用服务别名,会发送一个rest请求到服务注册中心获取对应的服务信息,让后会缓存到本地jvm客户端中,同时客户端每隔30秒从服务器上更新一次. 可以通过 fetch-inte vall-seconds=30参数进行修以通过eureka.client .registry该参数默认值为30, 单位为秒. 服务下线 在系统运行过程中必然会面临关闭或重启服务的某个实例的情况,在服务关闭期有我们自然不希望客户端会继续调用关闭了的实例.所以在客户

spring cloud微服务架构b2b2c电子商务-Eureka保护机制

首先对Eureka注册中心需要了解的是Eureka各个节点都是平等的,没有ZK中角色的概念, 即使N-1个节点挂掉也不会影响其他节点的正常运行.了解springcloud架构可以加求求:三五三六二四七二五九 默认情况下,如果Eureka Server在一定时间内(默认90秒)没有接收到某个微服务实例的心跳,Eureka Server将会移除该实例.但是当网络分区故障发生时,微服务与Eureka Server之间无法正常通信,而微服务本身是正常运行的,此时不应该移除这个微服务,所以引入了自我保护机

Nginx实战系列之功能篇----后端节点健康检查

公司前一段对业务线上的nginx做了整理,重点就是对nginx上负载均衡器的后端节点做健康检查.目前,nginx对后端节点健康检查的方式主要有3种,这里列出: 1.ngx_http_proxy_module 模块和ngx_http_upstream_module模块(自带)     官网地址:http://nginx.org/cn/docs/http/ngx_http_proxy_module.html#proxy_next_upstream 2.nginx_upstream_check_mod

Nginx实战系列之功能篇----后端节点健康检查(转)

公司前一段对业务线上的nginx做了整理,重点就是对nginx上负载均衡器的后端节点做健康检查.目前,nginx对后端节点健康检查的方式主要有3种,这里列出:   1.ngx_http_proxy_module 模块和ngx_http_upstream_module模块(自带)    官网地址:http://nginx.org/cn/docs/http/ng ... proxy_next_upstream2.nginx_upstream_check_module模块    官网网址:https:

有容云AppSoar容器健康检查与调度策略

近两年来,微服务架构和基于容器的虚拟化技术以迅雷不及掩耳之势席卷了整个软件开发社区,微服务与Docker的结合更被视为一种"颠覆".在与容器结合使用后,微服务架构的优点得到了进一步的放大:微服务鼓励软件开发者将整个软件解耦为较小的功能模块,并且这些功能能够应对外界的故障:而容器进一步对这种解耦性进行了扩展,它能够将软件从底层的硬件中分离出来. 这种方式所产生的结果是:应用程序能够更快地进行创建,并且更易于维护,同时又能够得到更高的质量,从而促使越来越多的产业应用容器化.如eBay.Am

Nginx被动健康检查和主动健康检查

1.被动健康检查 Nginx自带有健康检查模块:ngx_http_upstream_module,可以做到基本的健康检查,配置如下: upstream cluster{ server 172.16.0.23:80 max_fails=1 fail_timeout=10s; server 172.16.0.24:80 max_fails=1 fail_timeout=10s; # max_fails=1和fail_timeout=10s 表示在单位周期为10s钟内,中达到1次连接失败,那么接将把节

springCloud(6):Eureka的自我保护模式、多网卡下的IP选择、Eureka的健康检查

一.Eureka的自我保护模式 进入自我保护模式最直观的体现就是Eureka Server首页的警告,如下图: 默认情况下,如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳,Eureka Server将会注销该实例(默认90秒).但是当网络分区故障发生时,微服务与Eureka Server之间无法正常通信,这就可能变得非常危险了----因为微服务本身是健康的,此时本不应该注销这个微服务. Eureka Server通过"自我保护模式"来解决这个问题----当Eu

Eureka的自我保护机制

一.介绍 Eureka的自我保护机制主要是为了网络异常时保持高可用设计的,当在Eureka中注册的微服务超过设定是时间内(默认90秒)没有向Eureka服务端发送心跳,该微服务会进入自我保护模式.在自我保护模式中,Eureka会保护服务注册表中的信息,不会注销任何服务实例,直至收到的心跳数恢复至阈值以上,该微服务退出自我保护模式. 二.理解 好死不如赖活:Eureka的设计哲学是宁可保留错误的服务信息,也不盲目注销可能健康的服务.所以异常的服务不会被注销,而是进入了自我保护模式. 三.自我保护模