Eureka优化

Server 端

一 自我保护优化：

场景	服务数	失去心跳	剔除后的阈值	默认阈值	要开自我保护吗？
场景一	10个/比较少	3个	70%	85%	不开启
场景二	1000个/比较大	3个	99.7%	85%	开启

场景一：

由于服务数本来就只有10个，如果因为3个断了，如果开启了自我保护机制，大量请求可能就会访问坏的三个服务，这样肯定是不行的，所以要关闭，相当于断了，就要将其剔除；虽然关闭了自我保护机制，也会有剔除服务时间间隔，来保障服务重连的情况，可以将eviction-interval-timer-in-ms参数设置短一点，以免让客户端放问断开的服务，该参数默认是60s，相当于快速下线。

场景二：

服务数比较大，断了3个也问题不大，所以建议开启保护机制，如果3个失去心跳的服务是由于网络抖动导致的，开启之后还给了他们复活重连的机会。

eureka:
  server:
    # 自我保护开关，默认开启
    enable-self-preservation: true
    # 自我保护阈值，默认0.85
    renewal-percent-threshold: 0.85
    # 自我保护剔除时间间隔，单位毫秒，默认60s
    eviction-interval-timer-in-ms: 60000
    # 客户端续约时间间隔，默认30s
    expected-client-renewal-interval-seconds: 30
    # 阈值更新的时间间隔，单位为毫秒，默认为15 * 60 * 1000
    renewal-threshold-update-interval-ms: 900000

生产中的问题
     优化目的：减少服务上下线的延时。
    自我保护的选择：看网络和服务状况。
    服务更新：停止，再发送下线请求。
建议如果服务器不多时，自我保护可以关掉；如果是很多时，自我保护开启（网络抖动）


二 三级缓存优化：

什么是三级缓存
Eureka Server 存在三个变量：registry、readWriteCacheMap、readOnlyCacheMap 保存服务注册信息

public abstract class AbstractInstanceRegistry implements InstanceRegistry {
    // 三级
    private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry
            = new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();
}

public class ResponseCacheImpl implements ResponseCache {
    
    // 二级
    private final ConcurrentMap<Key, Value> readOnlyCacheMap = new ConcurrentHashMap<Key, Value>();
    // 一级
    private final LoadingCache<Key, Value> readWriteCacheMap;
}

三级缓存工作流程

默认情况下定时任务每 30s 将 readWriteCacheMap 同步至 readOnlyCacheMap，每 60s 清理超过 90s 未续约的节点，Eureka Client 每 30s 从 readOnlyCacheMap 拉取服务注册信息，而服务的注册则在 registry 更新信息。

三级缓存的优点

尽可能保证了内存注册表中的数据不会出现频繁的读写冲突问题，并且进一步保证了对EurekaServer大量请求，都是快速从内存中取，性能极高。
生产环境中优化

由于我们取获取服务时，默认从readOnlyCacheMap中读取，由于readWriteCacheMap每隔30s才同步到readOnlyCacheMap，数据不是强一致性的，所以这是Eureka只实现了AP，没有实现C的原因。

CAP：
    Consistency(一致性)：等同于所有节点访问同一份最新的数据副本。
    Availability(可用性)：每次请求都能获取到正确的响应，但是不保证获取的数据为最新的数据。
    Partition tolerance(分区兼容性)：以实际效果而言，分区相当于对通信的时限要求，系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间作出选择。

优化：

eureka:
  server:
    # 关闭从readOnly读注册表，直接去readWriteCacheMap中读
    use-read-only-response-cache: false
    # readWrite 和 readOnly 减少同步时间间隔。
    response-cache-update-interval-ms: 1000

use-read-only-response-cache默认这个参数是true，去readOnlyCacheMap中读，设置成false之后去readWriteCache中读，这样会快一点。

三 定时器Timer优化：

Eureka源码用了大量的Timer定时任务，由于Timer定时器存在以下缺陷：
Timer缺陷：

    Timer在执行所有定时任务时只会创建一个线程，当存在多个任务时，其任务是串行执行的。
    由于Timer只会创建一个线程，那么在TimerTask抛出了一个未检出的异常，那么Timer线程就会被终止掉，导致其它任务都停止。
    Timer执行周期任务时依赖系统时间，如果当前系统时间发生变化会出现一些执行上的变化。

建议使用ScheduledExecutorService

client 端

# 刷新注册表（拉取注册表）间隔
eureka.client.registry-fetch-interval-seconds=5
# 心跳续约间隔
eureka.instance.lease-renewal-interval-in-seconds=10
# 服务失效的时间
eureka.instance.lease-expiration-duration-in-seconds=10

建议
    可以设置饥饿加载。防止第一次请求超时。
    eureka.client.service-url：打乱配置。不要所有服务都写一样顺序的配置（因为默认都会注册到第一个服务器，而且默认是注册前3个，第4个不会注册）。


下面我们总结一下在Eureka中常用的配置选项及代表的含义：

配置	含义	默认值
eureka.client.enabled	是否启用Eureka Client 默认值：true	true
eureka.client.register-with-eureka	表示是否将自己注册到Eureka Server 默认值：true	true
eureka.client.fetch-registry	表示是否从Eureka Server获取注册的服务信息默认值：true	true
eureka.client.serviceUrl.defaultZone	配置Eureka Server地址，用于注册服务和获取服务默认值：http://localhost:8761/eureka	http://localhost:8761/eureka
eureka.client.registry-fetch-interval-seconds	默认值为30秒，即每30秒去Eureka Server上获取服务并缓存默认值：30	30
eureka.instance.lease-renewal-interval-in-seconds	向Eureka Server发送心跳的间隔时间，单位为秒，用于服务续约默认值：30	30
eureka.instance.lease-expiration-duration-in-seconds	定义服务失效时间，即Eureka Server检测到Eureka Client木有心跳后（客户端意外下线）多少秒将其剔除默认值：90	90
eureka.server.enable-self-preservation	用于开启Eureka Server自我保护功能默认值：true	true
eureka.client.instance-info-replication-interval-seconds	更新实例信息的变化到Eureka服务端的间隔时间，单位为秒默认值：30	30
eureka.client.eureka-service-url-poll-interval-seconds	轮询Eureka服务端地址更改的间隔时间，单位为秒。默认值：300	300
eureka.instance.prefer-ip-address	表示使用IP进行配置为不是域名默认值：false	false
eureka.client.healthcheck.enabled	默认Erueka Server是通过心跳来检测Eureka Client的健康状况的，通过置为true改变Eeureka Server对客户端健康检测的方式，改用Actuator的/health端点来检测。默认值：false	false