Eureka服务注册与发现中心

Eureka服务注册与发现中心

两个概念：server服务端和client客户端

我们在一个项目中通常会有各种各样的模块服务，比如说在一个电商项目中可能会有订单模块服务、付款模块服务、发货模块服务，实际项目中的每个模块服务在Eureka服务注册与发现中心都是对应client客户端；
而对于Eureka服务注册与发现中心的server服务端，可以理解成是一个独立于项目之外的一个管理中心，这个管理中心不属于我们的项目模块，但它可以用来管理我们实际的项目中的各个模块之间的微服务。

eureka里的client客户端
因此，对于我们项目中的每个模块的微服务，不管是服务提供者还是服务消费者，对于Eureka来说都只是一个微服务而已。我们都需要引入eureka-client客户端依赖，并且在启动类上使用Eureka客户端相关注解@EnableEurekaClient，如下图：

<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>

我们上面的payment8001是一个服务提供者，提供者的意思就是说这个微服务不会调用其他的微服务，但其他的微服务会调用这个微服务，比如order80服务就是一个消费者，这个微服务会去调用payment8001服务。但是既便你是消费者服务，本质上来说你也就是一个服务而已，对于Eureka服务注册与发现中心来说没啥差别，因此消费者服务order80也需要在启动类上写上@EnableEurekaClient注解，并且也需要在pom.xml里面引入eureka-client的相关依赖。

eureka里的server服务端
对于eureka里的server服务端，它不是我们项目里面的模块服务，而是相当于一个管理项目里的各个模块微服务的管理中心。
一个eureka服务端需要在pom.xml文件中引入eureka-server依赖，并且还需要在启动类上配置@EnableEurekaServer注解，如下图：

<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
        </dependency>

eureka相关的配置，每个配置的作用是什么？

eureka-client客户端相关配置
首先来看下在application.yml配置文件中，关于eureka-client客户端的常见的配置都有哪些，如下图：

eureka-client客户端的配置是使用的client关键字，如上图，接下来我们来一个一个配置说下他们的作用。

register-with-eureka
register-with-eureka表示的是是否把自己注测到eureka微服务管理中心中去，因为当前是eureka-client客户端，是项目里面的一个实实在在的微服务，因此肯定是要注册到管理中心去的，因此这里的值我们设置的是ture。而如果要是eureka-server服务端，则设置成false。

fetch-registry（其中fetch是得到的意思）
fetch-registry的作用主要是开启服务发现功能。对于项目里面的每个服务，也就是对于eureka管理中心的每个微服务来说，它都需要能够有发现其他微服务的本领，因为eureka管理中心的微服务之间是相互联系的，他们后期需要相互之间调用，因此对于注册到eureka管理中心的每个微服务来说，它们都是eureka-clinet客户端，我们都需要把fetch-registry的值设置成true；
但是对于eureka-server服务器来说，它不需要有发现别的微服务并调用的功能，因为它的主要职责不是去调用其他的微服务，而是去管理好这些微服务，因此对于eureka-server服务器来说需要把fetch-registry设置为false。

defaultZone
defaultZone的作用是设置eureka-client客户端与eureka-server服务器交互的地址，用于服务的注册和发现。

当一个微服务启动的时候，会通过defaultZone的地址把自己注册到eureak管理中心去，这样其他的微服务就能调用自己；当一个微服务想要去调用其他的微服务的时候，它首先需要得到defalutZone的地址，以获取eureka管理中心，这样它才能去eureka管理中心中去调用其他微服务；

因此如果你的defaultZone的地址设置的不正确，那么你的微服务启动之后它的服务注册就不能注册到eureka管理中心中，并且它调用其他微服务的时候也会因为找不到eureka管理中心进而找不到它想要调用的微服务。

instance-id
instance-id的作用是用来唯一标识eureka管理中心的一个微服务，它其实就相当于我们数据库表的一个主键id一样。如果没有设置这个id值，那么当前微服务注册到eureka管理中心之后会生成一个默认的主键id值，设置了就是我们设置的id，如下图：

prefer-ip-address
当鼠标放到instance-id主键id上之后，可以显示微服务的ip地址。假如prefer-ip-address的值设置的为false，那么当鼠标放到instance-id上的时候是显示不出来ip地址的，如下图：

但如果改成true就可以了，如下图：

lease-renewal-interval-in-seconds
lease-renewal-interval-in-seconds，租约更新时间，比如上面就是1s钟更新一次租约，通常会配合下面的lease-expiration-duration-in-seconds租约过期持续时间来使用（默认90s），比如我们上面的租约过期持续时间设置的是2s。那么这两个结合起来是什么意思呢？
就是如果1s内eureka-server服务器可以收到eureka-client客户端的心跳，那么会更新租约，租约是续约状态；但是如果1s内服务器没收到客户端的心跳，并且2s内也一直没有收到，那么服务器会把当前的eureka-client客户端微服务的状态设置为 已过期状态，这个时候我理解的是eureka-server服务器还没有在它的管理中心中清楚掉这个微服务，那什么时候清楚呢？

请看eureka-server中的配置。如下。

eureka-server服务端相关配置
注意eureka-server服务端相关的配置也可以写client关键字，具体相关配置如下图：

client的对应配置我们已经说过了，这里就不再重复叙述了，我们主要来说下server对应的相关配置。

eviction-interval-timer-in-ms（eviction是驱逐的意思）
单位ms。
如果在设置时间内，仍然没有收到管理中心中微服务的心跳，那么Eureka-Server管理中心会把服务注册表中相关的微服务给清楚掉。默认是6000ms一分钟。
如果在设置的时间内仍然没有收到微服务的心跳，并且此微服务的状态为已过期的状态，Eureka-Server管理中心就会把服务注册表中的相关的微服务给清除掉。

误区解释
刚开始的时候我看eureka-client客户端有个lease-expiration-duration-in-seconds配置，默认是90s，也就是90s内未续约的都会变成已过期状态，会被eureka-server清楚掉；
但是我们eureka-server服务端也有个类似的eviction-interval-timer-in-ms配置，默认是60000ms也就是60s，如果微服务60s内没有像eureka-server发送心跳，那么也会被清楚掉；
看到这两个我就有点懵了，因为既然它俩都可以控制eureka-server管理中心清楚微服务的时间，直接设置一个不就行了吗？为什么还要开发两个呢？那如果同时设置两个，是不是会按时间最小的来呢？比如说 都是默认值的话，那如果一个微服务60s都没有向eureka-server发送心跳，那它是不是就会被清楚掉呢？其实是不会的，因为60s之后只会清楚掉已经标记过期的微服务，这样解释设置两个配置才说得通。比如60s内一个微服务没有发送心跳，但是因为还没有达到90s，所以微服务的租约还未过期，而在60s的时候eureka管理中心只会清楚掉哪些租约过期的微服务；如果等到70s的时候，有了心跳，那么微服务相当于再次续约了，这样到下一个60s的时候eureka管理中心就不会清楚掉这个微服务了；但如果90s过后该微服务仍然没有续约，那它就会被标记为已过期状态了，等到下个60s的时候就会被eureka管理中心从服务注册表中清楚掉了。

enable-self-preservation
enable-self-preservation的作用是是否开启自我保护机制。
为什么需要自我保护机制呢？假如现在由于网络问题，微服务向eureka管理中心发送心跳时数据传输有问题，那么eureka管理中心可能会由于检测不到微服务的心跳，就把此微服务删除了。但此微服务还是可用状态，只不过是因为网络出问题了而已。所以这就会导致eureka管理中心误删微服务，那么为了解决这个问题，eureka设置了一种自我保护机制，就是既便eureka管理中心没有收到微服务的心跳，但是仍然不会删除它，所有微服务此时都不会删除，因为eureka的解释是目前网络出现了问题，并不是微服务出问题了。

默认是等到是三个心跳周期lease-expiration-duration-in-seconds后，也就是默认是3个90s之后，如果还没收到微服务的心跳，此时才会删除。