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

一、Eureka的自我保护模式

进入自我保护模式最直观的体现就是Eureka Server首页的警告,如下图:

默认情况下,如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳,Eureka Server将会注销该实例(默认90秒)。但是当网络分区故障发生时,微服务与Eureka Server之间无法正常通信,这就可能变得非常危险了----因为微服务本身是健康的,此时本不应该注销这个微服务。

Eureka Server通过“自我保护模式”来解决这个问题----当Eureka Server节点在短时间内丢失过多客户端时(可能发生了网络分区故障),那么这个节点就会进入自我保护模式。一旦进入该模式,Eureka Server就会保护服务注册表中的信息,不再删除服务注册表中的数据(也就是不会注销任何微服务)。当网络故障恢复后,该Eureka Server节点会自动退出自我保护模式。

自我保护模式是一种对网络异常的安全保护措施。使用自我保护模式,而已让Eureka集群更加的健壮、稳定。

在Spring Cloud中,可以使用eureka.server.enable-self-preservation=false来禁用自我保护模式,当然也可以使用显示指定IP地址来解决:

eureka.instance.instance-id: ${spring.cloud.client.ipAddress}:${server.port}

二、多网卡环境下的IP选择

2.1、简介

指定IP在某些场景下很有用,如某台服务器有eth0、eth1和eth2三块网卡,但是eth1可以被其它的服务器访问;如果Eureka Client将eth0或者eth2注册到Eureka Server上,其它微服务就无法通过这个IP调用该微服务的接口。

Spring Cloud提供了按需选择IP的能力,从而避免以上的问题。

2.2、操作

方案1、忽略指定名称的网卡

#忽略eth0,支持正则表达式
spring.cloud.inetutils.ignored-interfaces[0]=eth0
#注册时使用ip而不是主机名
eureka.instance.prefer-ip-address=true

方案2、只使用站点本地地址

#只使用站点本地地址
spring.cloud.inetutils.use-only-site-local-interfaces=true
#注册时使用ip而不是主机名
eureka.instance.prefer-ip-address=true

方案3、手动指定IP地址

#手动指定IP地址
spring.cloud.inetutils.default-ip-address=127.0.0.1
#注册时使用ip而不是主机名
eureka.instance.prefer-ip-address=true

三、Eureka的健康检查

先看下图:

说明:在Status栏显示着UP,表示应用程序状态正常。其它取值DOWN、OUT_OF_SERVICE、UNKNOWN等,只有UP的微服务会被请求。

由于Eureka Server与Eureka Client之间使用心跳机制来确定Eureka Client的状态,默认情况下,服务器端与客户端的心跳保持正常,应用程序就会始终保持“UP”状态,所以微服务的UP并不能完全反应应用程序的状态。

Spring Boot Actuator提供了/health端点,该端点可展示应用程序的健康信息,只有将该端点中的健康状态传播到Eureka Server就可以了,实现这点很简单,只需为微服务配置如下内容:

#开启健康检查(需要spring-boot-starter-actuator依赖)
eureka.client.healthcheck.enabled = true

如果需要更细粒度健康检查,可实现com.netflix.appinfo.HealthCheckHandler接口

时间: 2024-10-13 00:19:48

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

Spring Cloud Eureka的自我保护模式与实例下线剔除

之前我说明了Eureka注册中心的保护模式,由于在该模式下不能剔除失效节点,故按原有配置在实际中不剔除总感觉不是太好,所以深入研究了一下.当然,这里重申一下,不管实例是否有效剔除,消费端实现Ribbon重试机制也是必须的. 说下背景,在微服务架构中,有个CAP原则(一致性,可用性,可靠性),三者由于存在互斥,只能同时满足其二,第三点需要有一定舍弃.Eureka舍弃了强一致性,所以在进入保护模式后,失效节点的一致性不能得到保证. 以下是我验证后的几种方式,可以实现服务的及时剔除. 1.关闭自我保护

eureka的简单介绍,eureka单节点版的实现?eureka的自我保护?eureka的AP性,和CP性?

一.什么是eureka? // eureka是一个注册中心,实现了dubbo中zookeeper的效果! 二.实现eureka工程的搭建? 1.1 单节点版 1.1 zookeeper 和 eureka的区别? /* 1. zookeeper不会把自己注册到注册中心,但是eureka会! 2. 配置eureka 需要配置不能把自己注册到注册中心里面. 3. consumer 也不能把自己注册到注册中心. 4. 只要provider可以. */ 1.2 创建eureka工程 20190926-sp

Eureka的自我保护机制

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

springCloud(3):微服务的注册与发现(Eureka)

一.简介 服务消费者需要一个强大的服务发现机制,服务消费者使用这种机制获取服务提供者的网络信息.即使服务提供者的信息发生变化,服务消费者也无须修改配置. 服务提供者.服务消费者.服务发现组件三者之间的关系大致如下: 1.各个微服务在启动时,将自己的网络地址等信息注册到服务发现组件中,服务发现组件会存储这些信息. 2.服务消费者可以从服务发现组件查询服务提供者的网络地址,并使用该地址调用服务提供者的接口. 3.各个微服务与服务发现组件使用一定机制(如:心跳)通信,服务发现组件如长时间无法与某微服务

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

Eureka自我保护机制 接着以上篇文章建立的三个工程为基础(eureka-server,uerreg,myweb),默认Eureka是开启自我保护的.我们来做个测试,我们先启动三个工程,我们访问注册中心http://localhost:8761/, image.png 可以看到,实例是成功注册到中心的.此时我们将uerreg服务关闭,刷新注册中心,我们会发现如下界面 image.png 我们除了看到了一行红色的警告信息,还发现了一件神奇的事情,就是我们的服务实例虽然被kill了,但是在服务注册

spring cloud中微服务之间的调用以及eureka的自我保护机制

上篇讲了spring cloud注册中心及客户端的注册,所以这篇主要讲一下服务和服务之间是怎样调用的 不会搭建的小伙伴请参考我上一篇博客:idea快速搭建spring cloud-注册中心与注册 基于上一篇的搭建我又自己搭建了一个客户端微服务: 所以现在有两个微服务,我们所实现的就是微服务1和微服务2之间的调用 注册中心就不用多说了,具体看一下两个微服务 application.yml配置也不用说了,不知道怎么配置的请参考我上篇博客 在project-solr中的constroller中: @R

linux 两块网卡设置同一ip地址

双网卡绑定为同一个虚拟的网卡(bond), 外界看到的好像是bond网卡在向外界提供服务, 而其实底层是两块真实的网卡在提供服务. 下面介绍一些简单的概念: 1>. Bonding 就是将多块网卡绑定同一IP 地址对外提供服务,可以实现高可用或者负载均衡.当然,直接给两块网卡设置同一IP 地址是不可能的.通过bonding ,虚拟一块网卡对外提供连接, 物理网卡的被修改为相同的MAC 地址. 2>. Bonding 的工作模式 Mode 0 (balance-rr) 轮转(Round-robi

Linux网卡多IP和bond实现多网卡使用同一IP

一.一个网卡可以根据网络环境选择不同的IP 有时我们会遇到这样一种情况,在参加公司某个项目时,所在的网络环境没有DHCP服务,IP配置必须手动指定,而当我们下班回家继续工作时,必须更改IP配置才能正常上网.在windows和Linux中其实都支持备份IP的配置,即当主配置无法通过DHCP获得IP时,启用手动配置的备份IP.值得一提的是,只有当主IP配置使用DHCP时才能使用备用配置且备用配置必须手动指定. 这个配置非常的简单,只需创建一个/etc/sysconf/network-scripts/

linux 单网卡绑定多IP及BONGDING的实现

Linux Bond 1 bond 的概念 Linux双网卡绑定实现就是使用两块网卡虚拟成为一块网卡,这个聚合起来的设备看起来是一个单独的以太网接口设备,通俗点讲就是两块网卡具有相同的IP地址而并行链接聚合成一个逻辑链路工作. 2 bond 技术的由来 这项 技术在Sun和Cisco中早已存在,被称为Trunking和Etherchannel技术,在Linux的2.4.x的内核中也采用这这种技术,被称为bonding. 3 bond 工作原理 在正常情况下,网卡只接收目的硬件地址(MAC Add