springcloud学习之路（二）

简介：

前言：这是在上一篇的基础上学习的 https://blog.csdn.net/tuesdayma/article/details/82868103

1、eureka集群

2、eureka自我保护机制

一、eureka集群

简介： 注册中心是springcloud最核心的东西，如果注册中心挂了的话，所有的服务就算是正常的也将无法访问，所以说注册中心是不可能单机的。

修改服务端配置文件：

1、端口 - - - 改为不同的就行了。。。

2、设置服务名称（所有集群的eureka服务名称都要保持一致）

3、defaultZone：填写其他几台eureka地址，遵循一个原则（你中有我，我中有你）

4、修改register-with-eureka和fetch-registry为true

server:
  port: 8101
###设置服务名称
spring:
  application:
    name: mzd-eureka
eureka:
  instance:
    ##注册中心的ip地址
    hostname: 127.0.0.1
  client:
    service-url: 
        ##注册中心地址
      defaultZone: http://${eureka.instance.hostname}:8102/eureka,http://${eureka.instance.hostname}:8103/eureka
     ###自己是注册中心，是否要将自己注册到注册中心去,但是集群的时候需要设置为true
    register-with-eureka: true
     ###自己是注册中心，不需要去检索服务信息
    fetch-registry: true

修改客户端配置文件：

defaultZone：填写所有的eureka服务端，用"，"隔开即可，主要是以防eureka其中一台挂了。。。

###订单服务端口号
server:
  port: 9200
###服务别名---服务注册到注册中心的名称
spring:
  application:
    name: mzd-order
eureka:
  client:
    service-url:
    ###当前订单服务注册到eureka服务地址
      defaultZone: http://127.0.0.1:8101/eureka,http://127.0.0.1:8102/eureka,http://127.0.0.1:8103/eureka
    ###是否需要注册到eureka上
    register-with-eureka: true
    ###需要检索服务
    fetch-registry: true

结果： 这个时候8101是主机，其他两台是备机。



异常： 这个时候8101突然宕机了。。。过了数秒之后：


说明： 一般注册的服务只会在主机上进行显示，当8101宕机之后，eureka从8102和8103中选择了8102作为主机，其他服务器之间的调用任然能继续进行。

二、eureka自我保护机制

前言： eureka客户端会通过http协议向服务端定时发送心跳包。如果不开启自我保护机制的话，在客户端自己规定的时间间隔里，服务端没有收到心跳包的话，服务端将把这个客户端直接剔除；如果开启自我保护机制的话，他会等待一段时间（默认是90s），如果超过这个时间，服务端还是没有收到心跳包的话，才认为这个客户端已经挂了，将它剔除。

简介： 因为服务的集群是部署在不同的服务器上的，不同服务器与eureka服务器之间的网络问题是不能保证的，也就是说eureka客户端与服务器端有时存在着短暂的网络波动，访问不通的情况，如果因为是网络短暂访问不同引起的访问失败，这时候如果不开启自我保护机制的话，这个服务端就直接把这个客户端剔除了，但是其实过几秒钟，网络好了任然能访问这个客户端的，这样就是误认为这个客户端挂了，实际上并没有，如果开启了自我保护机制就能大量的减少这个误踢的情况发生。

关闭自我保护机制： 默认是开启的。- - 个人觉得本地开发环境直接关了就行。。。影响效率

修改服务端配置文件：将enable-self-preservation设置为false

server:
  port: 8101
spring:
  application:
    name: mzd-eureka
eureka:
  instance:
    ##注册中心的ip地址
    hostname: 127.0.0.1
  client:
    service-url: 
        ##注册中心地址
      defaultZone: http://${eureka.instance.hostname}:8101/eureka
     ###自己是注册中心，是否要将自己注册到注册中心去,但是集群的时候需要设置为true
    register-with-eureka: false
     ###自己是注册中心，不需要去检索服务信息
    fetch-registry: false
  server:
    ##是否开启自我保护机制
    enable-self-preservation: false

修改客户端配置文件：设置lease-renewal-interval-in-seconds和lease-expiration-duration-in-seconds

###会员项目端口号
server:
  port: 9101
###服务别名---服务注册到注册中心的名称
spring:
  application:
    name: mzd-member
eureka:
  client:
    service-url:
    ###当前会员服务注册到eureka服务地址
      defaultZone: http://127.0.0.1:8101/eureka
    ###是否需要注册到eureka上
    register-with-eureka: true
    ###需要检索服务
    fetch-registry: true
  instance:
    ##客户端自己告诉服务端多少秒发送一个心跳包
    lease-renewal-interval-in-seconds: 1
    ##客户端告诉服务端等待多少秒之后如果还是没有收到心跳包，那就把我剔除吧
    lease-expiration-duration-in-seconds: 2

开启自我保护机制： 下面是建立在关闭的基础上修改的，注意一下！

修改服务端配置文件：设置eviction-interval-timer-in-ms，表示超过多少毫秒则直接剔除；设置enable-self-preservation为true，或者直接不设置，因为默认是true。

server:
  port: 8101
spring:
  application:
    name: mzd-eureka
eureka:
  instance:
    ##注册中心的ip地址
    hostname: 127.0.0.1
  client:
    service-url: 
        ##注册中心地址
      defaultZone: http://${eureka.instance.hostname}:8101/eureka
     ###自己是注册中心，是否要将自己注册到注册中心去,但是集群的时候需要设置为true
    register-with-eureka: false
     ###自己是注册中心，不需要去检索服务信息
    fetch-registry: false
  server:
    ##是否开启自我保护机制
    ##enable-self-preservation: true
    ##超过20之后才剔除
    eviction-interval-timer-in-ms: 20000

修改客户端配置文件：基本没啥要修改的，可以把lease-expiration-duration-in-seconds删除。

###会员项目端口号
server:
  port: 9100
###服务别名---服务注册到注册中心的名称
spring:
  application:
    name: mzd-member
eureka:
  client:
    service-url:
    ###当前会员服务注册到eureka服务地址
      defaultZone: http://127.0.0.1:8101/eureka
    ###是否需要注册到eureka上
    register-with-eureka: true
    ###需要检索服务
    fetch-registry: true
  instance:
    ##客户端自己告诉服务端多少秒发送一个心跳包
    lease-renewal-interval-in-seconds: 1
    ##客户端告诉服务端等待多少秒之后如果还是没有收到心跳包，那就把我剔除吧
    lease-expiration-duration-in-seconds: 2

结果：

1、我们关闭了其中一台member（9100）服务，可以发现，集群中轮询调用的有一台报错了


2、20秒之后：所有的请求都是9101在处理了，9100彻底挂了。。。这就是自我保护机制在起作用，这个时候重启9100之后，继续访问，发现还是只有9101在处理，这是因为每个客户端在规定时间内向注册中心读取一次配置，这个值默认是30秒，而ribbon实现的是客户端本地负载均衡，本地缓存中的地址只有一个9101，所以9100并没有被调用；我们可以发现30秒后，9100也开始轮询工作了。

总结：

个人认为，这种自我保护机制在生产环境中是非常有用的，因为网络波动是非常常见的，如果因为网络波动而将一台客户端误认为宕机这显然是不科学的，但是在开发环境中可以考虑关闭这个功能。。