本文主要是介绍Spring Cloud 十二:Eureka生产环境优化,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
文章目录
- 一,自我保护优化
- 自我保护常用配置
- 自我保护场景优化
- 二,三级缓存优化
- 什么是三级缓存
- 三级缓存工作流程
- 三级缓存的优点
- 生产环境中优化
- 三,定时器Timer优化
- Timer缺陷:
- 建议使用ScheduledExecutorService
一,自我保护优化
自我保护常用配置
eureka:server:# 自我保护开关,默认开启enable-self-preservation: true# 自我保护阈值,默认0.85renewal-percent-threshold: 0.85# 自我保护剔除时间间隔,单位毫秒,默认60seviction-interval-timer-in-ms: 60000# 客户端续约时间间隔,默认30sexpected-client-renewal-interval-seconds: 30# 阈值更新的时间间隔,单位为毫秒,默认为15 * 60 * 1000renewal-threshold-update-interval-ms: 900000
自我保护场景优化
场景 | 服务数 | 失去心跳 | 剔除后的阈值 | 默认阈值 | 要开自我保护吗? |
---|---|---|---|---|---|
场景一 | 10个/比较少 | 3个 | 70% | 85% | 不开启 |
场景二 | 1000个/比较大 | 3个 | 99.7% | 85% | 开启 |
场景一:
由于服务数本来就只有10个,如果因为3个断了,如果开启了自我保护机制,大量请求可能就会访问坏的三个服务,这样肯定是不行的,所以要关闭,相当于断了,就要将其剔除;虽然关闭了自我保护机制,也会有剔除服务时间间隔,来保障服务重连的情况,可以将eviction-interval-timer-in-ms参数设置短一点,以免让客户端放问断开的服务,该参数默认是60s,相当于快速下线。
场景二:
服务数比较大,断了3个也问题不大,所以建议开启保护机制,如果3个失去心跳的服务是由于网络抖动导致的,开启之后还给了他们复活重连的机会。
二,三级缓存优化
什么是三级缓存
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
这篇关于Spring Cloud 十二:Eureka生产环境优化的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!