springcloud配置

#每间隔2秒，向服务端发送一次心跳，证明自己依然“存活”
eureka.instance.lease-renewal-interval-in-seconds=2

#告诉服务端，如果我10s之内没有给你发心跳，就代表我故障了，将我踢出
eureka.instance.lease-expiration-duration-in-seconds=10

#告诉服务端，服务实例以IP作为链接，而不是取机器名
eureka.instance.prefer-ip-address=true

#告诉服务端，服务实例的名字
eureka.instance.instance-id=34-springcloud

Eureka与Zookeeper的比较
著名的CAP理论指出，一个分布式系统不可能同时满足C（一致性）、A（可用性）和p(分区容错性)
由于分区容错性在分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡，在此Zookeeper保证的是CP，而Eureka则是AP

Zookeeper保证CP
在Zookeeper中，当master节点因为网络故障与其他节点失去联系是，剩余节点会重新进行leader选举，但是问题在于，选举leader需要一定时间，且选举期间整个Zookeeper集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得Zookeeper集群失去master节点是大概率事件，但是在选举时间内导致服务注册长期不可用是难以容忍的

Eureka保证AP
Eureka优先保证可用性，Eureka各个节点是平等的，某几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和服务查询。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）

Eureka服务注册中心自我保护机制
自我保护机制是Eureka注册中心的重要特性，当Eureka注册中心进入自我保护模式时，在Eureka Server首页会输入如下警告信息:
emergency! eureka may be incorrectly claiming instances are up when they’re not. renewals are
lesser than threshold and hence the instances are not being expired just to be safe.
在没有eureka自我保护的情况下，如果eureka server在一定时间内没有接收到微服务实例的心跳，eureka server将会注销该实例，但是当发生网络分区故障时，那么微服务与eureka server之间将无法正常通信，以上行为可能变得非常危险了，因为微服务本身其实时正常的，此时不应该注销这个微服务，如果没有自我保护机制，那么eureka server就会将此服务注销掉。
eureka通过“自我保护模式”来解决这个问题——当eureka server节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么就会把这个微服务节点进行保护。一旦进入自我保护模式，eureka server就会保护服务注册表中的信息，不删除服务注册表中的数据（也就是不会注销任务微服务）。当网络故障恢复后，该eureka server节点会再自动退出自我保护模式。
所以，自我保护模式是一种应对网络异常的安全保护措施，它的架构哲学是宁可保留所有微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务，使用自我保护模式，可以让eureka集群更加的健壮、稳定。配置 eureka.server.enable-self-preservation=false 禁用自我保护模式