1.解决Eureka注册服务慢的问题
（1）调整客户端心跳时间
instance:
# 心跳时间，即服务续约间隔时间（缺省为30s）
lease-renewal-interval-in-seconds: 5
# 发呆时间，即服务续约到期时间（缺省为90s）
lease-expiration-duration-in-seconds: 10
eureka.instance.lease-expiration-duration-in-seconds
leaseExpirationDurationInSeconds，表示eureka server至上一次收到client的心跳之后，等待下一次心跳的超时时间，在这个时间内若没收到下一次心跳，则将移除该instance。
默认为90秒
如果该值太大，则很可能将流量转发过去的时候，该instance已经不存活了。
如果该值设置太小了，则instance则很可能因为临时的网络抖动而被摘除掉。
该值至少应该大于leaseRenewalIntervalInSeconds
eureka.instance.lease-renewal-interval-in-seconds
leaseRenewalIntervalInSeconds，表示eureka client发送心跳给server端的频率。如果在leaseExpirationDurationInSeconds后，server端没有收到client的心跳，则将摘除该instance。除此之外，如果该instance实现了HealthCheckCallback，并决定让自己unavailable的话，则该instance也不会接收到流量。
默认30秒
作为实例还涉及到与注册中心的周期性心跳，默认持续时间为30秒（通过serviceUrl）。在实例、服务器、客户端都在本地缓存中具有相同的元数据之前，服务不可用于客户端发现（所以可能需要3次心跳）。你可以使用eureka.instance.leaseRenewalIntervalInSeconds 配置，这将加快客户端连接到其他服务的过程。在生产中，最好坚持使用默认值，因为在服务器内部有一些计算，他们对续约做出假设。
（2） Eureka的自我保护模式
如果在Eureka Server的首页看到以下这段提示，则说明Eureka已经进入了保护模式。
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.
配置
server:
#开启Eureka的自我保护机制
enable-self-preservation: true
#清理无效节点的时间间隔
eviction-interval-timer-in-ms: 5000
eureka.server.enable-self-preservation
是否开启自我保护模式，默认为true。
默认情况下，如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳，Eureka Server将会注销该实例（默认90秒）。但是当网络分区故障发生时，微服务与Eureka Server之间无法正常通信，以上行为可能变得非常危险了——因为微服务本身其实是健康的，此时本不应该注销这个微服务。
Eureka通过“自我保护模式”来解决这个问题——当Eureka Server节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式。一旦进入该模式，Eureka Server就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。当网络故障恢复后，该Eureka Server节点会自动退出自我保护模式。
综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮、稳定。
eureka.server.eviction-interval-timer-in-ms
eureka server清理无效节点的时间间隔，默认60000毫秒，即60秒
（3）如何解决Eureka Server不踢出已关停的节点的问题
在开发过程中，我们常常希望Eureka Server能够迅速有效地踢出已关停的节点，但是新手由于Eureka自我保护模式，以及心跳周期长的原因，常常会遇到Eureka Server不踢出已关停的节点的问题。解决方法如下：
（1） Eureka Server端：配置关闭自我保护，并按需配置Eureka Server清理无效节点的时间间隔。
eureka.server.enable-self-preservation # 设为false，关闭自我保护
eureka.server.eviction-interval-timer-in-ms # 清理间隔（单位毫秒，默认是60*1000）
（2） Eureka Client端：配置开启健康检查，并按需配置续约更新时间和到期时间。
eureka.client.healthcheck.enabled # 开启健康检查（需要spring-boot-starter-actuator依赖）
eureka.instance.lease-renewal-interval-in-seconds # 续约更新时间间隔（默认30秒）
eureka.instance.lease-expiration-duration-in-seconds # 续约到期时间（默认90秒）
（4）zuul间隔多久去拉取注册服务的信息
eureka.client.registry-fetch-interval-seconds
表示eureka client间隔多久去拉取服务注册信息，默认为30秒，对于api-gateway，如果要迅速获取服务注册状态，可以缩小该值，比如5秒
（5）ribbon的饥饿加载
意为Spring Cloud为每个Ribbon客户端维护了一个相对的子应用环境的上下文，应用的上下文在第一次请求到指定客户端的时候懒加载。不过可以通过如下配置进行修改
ribbon:
eager-load:
enabled: true
clients:
- callback,service-cache,service-singlepoint
按照如上的配置之后，发现鉴权服务启动时就将user服务的Ribbon客户端进行了加载。
（6）zuul的饥饿加载
上面小节解决了auth-Service调用user-Service的Ribbon客户端启动时饥饿加载。网关作为对外请求的入口，zuul内部使用Ribbon调用其他服务，Spring Cloud默认在第一次调用时懒加载Ribbon客户端。zuul同样需要维护一个相对的子应用环境的上下文，所以也需要启动时饥饿加载。
zuul:
ribbon:
eager-load:
enabled: true
