Eureka集群以及自我保护机制

曾经以为走不出的日子，现在都回不去了。——村上春树

eureka伪集群的搭建

1）将eureka服务端复制2份

2）修改eureka服务的端口（因为是伪集群，在一台机器上，需要修改端口）

3）找到本机的hosts文件（C:\Windows\System32\drivers\etc\hosts）,分别给本机设置3个主机名

127.0.0.1 eureka1
127.0.0.1 eureka2
127.0.0.1 eureka3

4）修改3个eureka服务的service-url配置（在上一篇的基础上）

#配置eureka的相关属性
eureka:
  client:
    service-url:
      #配置eureka的注册地址
      #defaultZone没有提示，必须手写
      defaultZone: http://eureka1:20000/eureka,http://eureka2:20001/eureka,http://eureka3:20002/eureka
    #当前的微服务就是注册中心，注册中心不能从注册中心抓取服务，所以该配置需要配置成false
    fetch-registry: false
    #使得当前的微服务不注册到注册中心上
    register-with-eureka: false

5）启动三台eureka服务
6）所有的微服务的注册地址必须改成eureka集群的地址

eureka:
  client:
    service-url:
      #配置注册中心的地址，因为微服务需要注册，也需要抓取服务所以另外两个配置就可以省略了
      defaultZone: http://eureka1:20000/eureka,http://eureka2:20001/eureka,http://eureka3:20002/eureka

Eureka的自我保护机制

5.1 什么是Eureka的自我保护机制？

Eureka如果收到的微服务心跳相对于应该收到的微服务心跳来说，如果低于了85%，那么就会触发Eureka的自我保护机制。一旦自我保护机制启动，Eureka会保护所有的微服务，不被移除，哪怕当前微服务已经下线，仍然会保留到Eureka微服务列表中。

5.2 自我保护机制的作用

为什么Eureka要一种看起来如此傻逼的设计？- 自我保护机制是为了保证微服务间的高可用性，避免脑裂的影响

为什么Zookeeper要设计一个过半数存活原则？感觉特别浪费资源？ - 为了让整个集群一定只有一个Leader

CAP原则：任何一个分布式系统，都只能满足CAP中的2个原则，因为分区问题不可避免，所以P是必选的，一般的系统，都是从C和A中做选择。Zookeeper是CP设计，而Eureka是AP设计。

C（一致性）

A（可用性）

P（分区容错性）

思考：Eureka的自我保护机制，虽然是为了保证服务的高可用，但是如果服务真的挂掉了？那么也被自我保护起来，是不是有问题呢？

自我保护机制一旦启动，确实会保护那些真的出问题的微服务，所以Eureka设计了一个阈值，当15%的心跳都丢失的时候，才会发生自我保护机制。因为这个时候，相对于15%的机器挂掉来说，发生脑裂的概率大一些。但是有没有可能真的是15%机器挂掉了？这个时候Eureka是不能帮我们判断的，需要客户端本身有一定的容错机制，比如断路器

思考：CP设计好？还是AP设计好？ - 取决于业务，对于注册中心来说，偶尔拿到出问题的微服务，其实对于整个架构来讲没有太大问题，微服务架构最害怕整个注册中心服务不可用，因此对于注册中心来说，AP（高可用）设计强于CP（一致性）设计。并不是说一致性不好，对于分布式锁的业务来讲，一定要CP，不然整个集群的业务会混乱

注意：zookeeper可以是偶数台，只是说奇数台，服务器成本更低一些