在前几篇中《创建Eureka服务中心》我们介绍了Eureka的心跳检测并创建了Eureka服务中心,本篇将承接前面的内容讲解Eureka的自我保护机制以及离线服务。 自我保护机制通过阅读Eureka官网体系架构图下方的文档我们能够知道,eureka客户端,默认会每隔30秒发送一次心跳的eureka注册中心,如果在90秒内没收到一个eureka客户端的心跳,那么就摘除这个服务实例,消费者将无法访问这个服务实例了。 但是很多情况下不是微服务节点有问题,而是出现了网络抖动等原因导致EurekaServer无法发现该微服务(检测不到该微服务主机的心跳),从而摘除这个服务实例。 如果在短时间内EurekaServer摘除掉了较多的微服务(收到的心跳数量小于阈值),那么为了保证系统的可用性(AP),那些由于网络抖动被摘除的服务实例将会“复活”,Eureka自动进入自我保护模式。 (服务列表只可读取、写入,不可执行删除操作。当EurekaServer收到的心跳数量恢复到阈值以上时,其会自动退出自我保护模式。) 自我保护模式是自动开启的,可以在eurekaserver的配置文件中关闭,不建议关闭!(除非处于特殊状态,例如:测试) 关闭自我保护机制后可以设置server端剔除不可用服务的时间 也可以修改不同服务实例发送心跳的周期 指定让Server认定当前Client已经失效的时间 自我保护的阈值因子默认为0.85,也就是说当EurekaServer接收到的心跳数量小于85%时自我保护机制就会自动开启。自我保护的阈值因子也可以在eurekaserver的配置文件中根据需求进行自定义。 配置完成后执行代码,刷新浏览器 红色的提示信息不会在访问马上出来。 自我保护模式被激活的条件是:在1分钟后 Renews(lastmin)<Renewsthreshold Renewsthreshold:EurekaServer期望每分钟收到客户端实例续约的总数。 Renews(lastmin):EurekaServer最后1分钟收到客户端实例续约的总数。 Renewsthreshold计算代码: 如果在1分钟后,Renews(lastmin)<Renewsthreshold,默认需等待5分钟(可以通过eureka.server.wait-time-in-ms-when-sync-empty配置),即5分钟后你会看到红色的提示信息。 服务下线服务离线是指服务不能再对外提供服务了。 服务离线的原因有两种: 服务下架与服务下线,这两种方案都是基于Actuator监控器实现的。 服务下架:将注册到EurekaServer中的EurekaClient从Server的注册表中移除,这样其它Client就无法发现该Client了。 服务下线:Client并没有从EurekaServer的注册表中移除(其它Client仍可发现该服务),而是通过修改服务的状态来到达其它Client无法调用的目的。 首先为EurekaClient添加actuator依赖。 在provider和consumer的pom文件中添加spring-boot-starter-actuator依赖。 服务下架修改provider的配置文件。 执行代码,在postman中访问 http://localhost:8081/actuator/shutdown 服务下架后EurekaClient从Server的注册表中彻底移除,再次使用时需要重新启动。但是对于大型应用来说比较耗时的,所以希望服务可以平滑上/下线。 服务平滑上/下线配置文件只需将shutdown监控终端部分注释掉。 执行代码,在postman中访问 http://localhost:8081/actuator/service-registry 将状态自定义为DOWN。 回到浏览器查看服务状态。 此时Client无法调用。 将状态DOWN改成UP就可以实现平滑上线。 平滑上线之后,consumer需要等待一会儿才能正常访问。因为Client下载注册表每三十秒更新一次,consumer启动时,注册表可能还没有更新。 |
|