先看張圖
一，自我保護(hù)優(yōu)化
自我保護(hù)常用配置
eureka:
server:
# 自我保護(hù)開關(guān)，默認(rèn)開啟
enable-self-preservation: true
# 自我保護(hù)閾值，默認(rèn)0.85
renewal-percent-threshold: 0.85
# 自我保護(hù)剔除時(shí)間間隔，單位毫秒，默認(rèn)60s
eviction-interval-timer-in-ms: 60000
# 客戶端續(xù)約時(shí)間間隔，默認(rèn)30s
expected-client-renewal-interval-seconds: 30
# 閾值更新的時(shí)間間隔，單位為毫秒，默認(rèn)為15 * 60 * 1000
renewal-threshold-update-interval-ms: 900000
| 場(chǎng)景 | 服務(wù)數(shù) | 失去心跳 | 剔除后的閾值 | 默認(rèn)閾值 | 要開自我保護(hù)嗎？ |
|---|---|---|---|---|---|
| 場(chǎng)景一 | 10個(gè)/比較少 | 3個(gè) | 70% | 85% | 不開啟 |
| 場(chǎng)景二 | 1000個(gè)/比較大 | 3個(gè) | 99.7% | 85% | 開啟 |
由于服務(wù)數(shù)本來(lái)就只有10個(gè)，如果因?yàn)?個(gè)斷了，如果開啟了自我保護(hù)機(jī)制，大量請(qǐng)求可能就會(huì)訪問壞的三個(gè)服務(wù)，這樣肯定是不行的，所以要關(guān)閉，相當(dāng)于斷了，就要將其剔除；雖然關(guān)閉了自我保護(hù)機(jī)制，也會(huì)有剔除服務(wù)時(shí)間間隔，來(lái)保障服務(wù)重連的情況，可以將eviction-interval-timer-in-ms參數(shù)設(shè)置短一點(diǎn)，以免讓客戶端放問斷開的服務(wù)，該參數(shù)默認(rèn)是60s，相當(dāng)于快速下線。
場(chǎng)景二：
服務(wù)數(shù)比較大，斷了3個(gè)也問題不大，所以建議開啟保護(hù)機(jī)制，如果3個(gè)失去心跳的服務(wù)是由于網(wǎng)絡(luò)抖動(dòng)導(dǎo)致的，開啟之后還給了他們復(fù)活重連的機(jī)會(huì)。
二，三級(jí)緩存優(yōu)化
什么是三級(jí)緩存
Eureka Server 存在三個(gè)變量：registry、readWriteCacheMap、readOnlyCacheMap 保存服務(wù)注冊(cè)信息。
public abstract class AbstractInstanceRegistry implements InstanceRegistry {
// 三級(jí)
private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry
= new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();
}
public class ResponseCacheImpl implements ResponseCache {
// 二級(jí)
private final ConcurrentMap<Key, Value> readOnlyCacheMap = new ConcurrentHashMap<Key, Value>();
// 一級(jí)
private final LoadingCache<Key, Value> readWriteCacheMap;
}
三級(jí)緩存工作流程
默認(rèn)情況下定時(shí)任務(wù)每 30s 將 readWriteCacheMap 同步至 readOnlyCacheMap，每 60s 清理超過 90s 未續(xù)約的節(jié)點(diǎn)，Eureka Client 每 30s 從 readOnlyCacheMap 拉取服務(wù)注冊(cè)信息，而服務(wù)的注冊(cè)則在 registry 更新信息。
三級(jí)緩存的優(yōu)點(diǎn)
盡可能保證了內(nèi)存注冊(cè)表中的數(shù)據(jù)不會(huì)出現(xiàn)頻繁的讀寫沖突問題，并且進(jìn)一步保證了對(duì)EurekaServer大量請(qǐng)求，都是快速?gòu)膬?nèi)存中取，性能極高。
生產(chǎn)環(huán)境中優(yōu)化
由于我們?nèi)～@取服務(wù)時(shí)，默認(rèn)從readOnlyCacheMap中讀取，由于readWriteCacheMap每隔30s才同步到readOnlyCacheMap，數(shù)據(jù)不是強(qiáng)一致性的，所以這是Eureka只實(shí)現(xiàn)了AP，沒有實(shí)現(xiàn)C的原因。
CAP：
1.Consistency(一致性)：等同于所有節(jié)點(diǎn)訪問同一份最新的數(shù)據(jù)副本。
2.Availability(可用性)：每次請(qǐng)求都能獲取到正確的響應(yīng)，但是不保證獲取的數(shù)據(jù)為最新的數(shù)據(jù)。
3.Partition tolerance(分區(qū)兼容性)：以實(shí)際效果而言，分區(qū)相當(dāng)于對(duì)通信的時(shí)限要求，系統(tǒng)如果不能在時(shí)限內(nèi)達(dá)成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當(dāng)前操作在C和A之間作出選擇。
優(yōu)化：
eureka:
server:
# 關(guān)閉從readOnly讀注冊(cè)表，直接去readWriteCacheMap中讀
use-read-only-response-cache: false
# readWrite 和 readOnly 減少同步時(shí)間間隔。
response-cache-update-interval-ms: 1000
use-read-only-response-cache默認(rèn)這個(gè)參數(shù)是true，去readOnlyCacheMap中讀，設(shè)置成false之后去readWriteCache中讀，這樣會(huì)快一點(diǎn)。
三，定時(shí)器Timer優(yōu)化
Eureka源碼用了大量的Timer定時(shí)任務(wù)，由于Timer定時(shí)器存在以下缺陷：
Timer缺陷：
1.Timer在執(zhí)行所有定時(shí)任務(wù)時(shí)只會(huì)創(chuàng)建一個(gè)線程，當(dāng)存在多個(gè)任務(wù)時(shí)，其任務(wù)是串行執(zhí)行的。
2.由于Timer只會(huì)創(chuàng)建一個(gè)線程，那么在TimerTask拋出了一個(gè)未檢出的異常，那么Timer線程就會(huì)被終止掉，導(dǎo)致其它任務(wù)都停止。
3.Timer執(zhí)行周期任務(wù)時(shí)依賴系統(tǒng)時(shí)間，如果當(dāng)前系統(tǒng)時(shí)間發(fā)生變化會(huì)出現(xiàn)一些執(zhí)行上的變化。
建議使用ScheduledExecutorService
