轉載請標明出處：
blog.csdn.net/forezp/arti…
本文出自方誌朋的部落格
Eureka的一些概念
Register：服務註冊
當Eureka客戶端向Eureka Server註冊時，它提供自身的後設資料，比如IP地址、埠，執行狀況指示符URL，主頁等。Renew：服務續約
Eureka客戶會每隔30秒傳送一次心跳來續約。 通過續約來告知Eureka Server該Eureka客戶仍然存在，沒有出現問題。 正常情況下，如果Eureka Server在90秒沒有收到Eureka客戶的續約，它會將例項從其登錄檔中刪除。 建議不要更改續約間隔。Fetch Registries：獲取註冊列表資訊
Eureka客戶端從伺服器獲取登錄檔資訊，並將其快取在本地。客戶端會使用該資訊查詢其他服務，從而進行遠端呼叫。該註冊列表資訊定期（每30秒鐘）更新一次。每次返回註冊列表資訊可能與Eureka客戶端的快取資訊不同， Eureka客戶端自動處理。如果由於某種原因導致註冊列表資訊不能及時匹配，Eureka客戶端則會重新獲取整個登錄檔資訊。 Eureka伺服器快取註冊列表資訊，整個登錄檔以及每個應用程式的資訊進行了壓縮，壓縮內容和沒有壓縮的內容完全相同。Eureka客戶端和Eureka 伺服器可以使用JSON / XML格式進行通訊。在預設的情況下Eureka客戶端使用壓縮JSON格式來獲取註冊列表的資訊。Cancel：服務下線
Eureka客戶端在程式關閉時向Eureka伺服器傳送取消請求。 傳送請求後，該客戶端例項資訊將從伺服器的例項登錄檔中刪除。該下線請求不會自動完成，它需要呼叫以下內容：
DiscoveryManager.getInstance().shutdownComponent()；Eviction 服務剔除
在預設的情況下，當Eureka客戶端連續90秒沒有向Eureka伺服器傳送服務續約，即心跳，Eureka伺服器會將該服務例項從服務註冊列表刪除，即服務剔除。
Eureka的高可用架構
如圖為Eureka的高階架構圖，該圖片來自於Eureka開原始碼的文件，地址為github.com/Netflix/eur… 。
從圖可以看出在這個體系中，有2個角色，即Eureka Server和Eureka Client。而Eureka Client又分為Applicaton Service和Application Client，即服務提供者何服務消費者。 每個區域有一個Eureka叢集，並且每個區域至少有一個eureka伺服器可以處理區域故障，以防伺服器癱瘓。
Eureka Client向Eureka Serve註冊，並將自己的一些客戶端資訊傳送Eureka Serve。然後，Eureka Client通過向Eureka Serve傳送心跳（每30秒）來續約服務的。 如果客戶端持續不能續約，那麼，它將在大約90秒內從伺服器登錄檔中刪除。 註冊資訊和續訂被複制到叢集中的Eureka Serve所有節點。 來自任何區域的Eureka Client都可以查詢登錄檔資訊（每30秒發生一次）。根據這些登錄檔資訊，Application Client可以遠端呼叫Applicaton Service來消費服務。
Register服務註冊
服務註冊，即Eureka Client向Eureka Server提交自己的服務資訊，包括IP地址、埠、service ID等資訊。如果Eureka Client沒有寫service ID，則預設為 ${spring.application.name}。
服務註冊其實很簡單，在Eureka Client啟動的時候，將自身的服務的資訊傳送到Eureka Server。現在來簡單的閱讀下原始碼。在Maven的依賴包下，找到eureka-client-1.6.2.jar包。在com.netflix.discovery包下有個DiscoveryClient類，該類包含了Eureka Client向Eureka Server的相關方法。其中DiscoveryClient實現了EurekaClient介面，並且它是一個單例模式，而EurekaClient繼承了LookupService介面。它們之間的關係如圖所示。
在DiscoveryClient類有一個服務註冊的方法register()，該方法是通過Http請求向Eureka Client註冊。其程式碼如下：
boolean register() throws Throwable {
logger.info(PREFIX + appPathIdentifier + ": registering service...");
EurekaHttpResponse<Void> httpResponse;
try {
httpResponse = eurekaTransport.registrationClient.register(instanceInfo);
} catch (Exception e) {
logger.warn("{} - registration failed {}", PREFIX + appPathIdentifier, e.getMessage(), e);
throw e;
}
if (logger.isInfoEnabled()) {
logger.info("{} - registration status: {}", PREFIX + appPathIdentifier, httpResponse.getStatusCode());
}
return httpResponse.getStatusCode() == 204;
}複製程式碼在DiscoveryClient類繼續追蹤register()方法，它被InstanceInfoReplicator 類的run()方法呼叫，其中InstanceInfoReplicator實現了Runnable介面，run()方法程式碼如下：
public void run() {
try {
discoveryClient.refreshInstanceInfo();
Long dirtyTimestamp = instanceInfo.isDirtyWithTime();
if (dirtyTimestamp != null) {
discoveryClient.register();
instanceInfo.unsetIsDirty(dirtyTimestamp);
}
} catch (Throwable t) {
logger.warn("There was a problem with the instance info replicator", t);
} finally {
Future next = scheduler.schedule(this, replicationIntervalSeconds, TimeUnit.SECONDS);
scheduledPeriodicRef.set(next);
}
}複製程式碼而InstanceInfoReplicator類是在DiscoveryClient初始化過程中使用的，其中有一個initScheduledTasks()方法。該方法主要開啟了獲取服務註冊列表的資訊，如果需要向Eureka Server註冊，則開啟註冊，同時開啟了定時向Eureka Server服務續約的定時任務，具體程式碼如下：
private void initScheduledTasks() {
...//省略了任務排程獲取註冊列表的程式碼
if (clientConfig.shouldRegisterWithEureka()) {
...
// Heartbeat timer
scheduler.schedule(
new TimedSupervisorTask(
"heartbeat",
scheduler,
heartbeatExecutor,
renewalIntervalInSecs,
TimeUnit.SECONDS,
expBackOffBound,
new HeartbeatThread()
),
renewalIntervalInSecs, TimeUnit.SECONDS);
// InstanceInfo replicator
instanceInfoReplicator = new InstanceInfoReplicator(
this,
instanceInfo,
clientConfig.getInstanceInfoReplicationIntervalSeconds(),
2); // burstSize
statusChangeListener = new ApplicationInfoManager.StatusChangeListener() {
@Override
public String getId() {
return "statusChangeListener";
}
@Override
public void notify(StatusChangeEvent statusChangeEvent) {
instanceInfoReplicator.onDemandUpdate();
}
};
...
}複製程式碼然後在來看Eureka server端的程式碼，在Maven的eureka-core:1.6.2的jar包下。開啟com.netflix.eureka包，很輕鬆的就發現了又一個EurekaBootStrap的類，BootStrapContext具有最先初始化的許可權，所以先看這個類。
protected void initEurekaServerContext() throws Exception {
...//省略程式碼
PeerAwareInstanceRegistry registry;
if (isAws(applicationInfoManager.getInfo())) {
...//省略程式碼，如果是AWS的程式碼
} else {
registry = new PeerAwareInstanceRegistryImpl(
eurekaServerConfig,
eurekaClient.getEurekaClientConfig(),
serverCodecs,
eurekaClient
);
}
PeerEurekaNodes peerEurekaNodes = getPeerEurekaNodes(
registry,
eurekaServerConfig,
eurekaClient.getEurekaClientConfig(),
serverCodecs,
applicationInfoManager
);
}複製程式碼其中PeerAwareInstanceRegistryImpl和PeerEurekaNodes兩個類看其命名，應該和服務註冊以及Eureka Server高可用有關。先追蹤PeerAwareInstanceRegistryImpl類，在該類有個register()方法，該方法提供了註冊，並且將註冊後資訊同步到其他的Eureka Server服務。程式碼如下：
public void register(final InstanceInfo info, final boolean isReplication) {
int leaseDuration = Lease.DEFAULT_DURATION_IN_SECS;
if (info.getLeaseInfo() != null && info.getLeaseInfo().getDurationInSecs() > 0) {
leaseDuration = info.getLeaseInfo().getDurationInSecs();
}
super.register(info, leaseDuration, isReplication);
replicateToPeers(Action.Register, info.getAppName(), info.getId(), info, null, isReplication);
}複製程式碼其中 super.register(info, leaseDuration, isReplication)方法，點選進去到子類AbstractInstanceRegistry可以發現更多細節，其中註冊列表的資訊被儲存在一個Map中。replicateToPeers()方法，即同步到其他Eureka Server的其他Peers節點，追蹤程式碼，發現它會遍歷迴圈向所有的Peers節點註冊，最終執行類PeerEurekaNodes的register()方法，該方法通過執行一個任務向其他節點同步該註冊資訊，程式碼如下：
public void register(final InstanceInfo info) throws Exception {
long expiryTime = System.currentTimeMillis() + getLeaseRenewalOf(info);
batchingDispatcher.process(
taskId("register", info),
new InstanceReplicationTask(targetHost, Action.Register, info, null, true) {
public EurekaHttpResponse<Void> execute() {
return replicationClient.register(info);
}
},
expiryTime
);
}複製程式碼經過一系列的原始碼追蹤，可以發現PeerAwareInstanceRegistryImpl的register()方法實現了服務的註冊，並且向其他Eureka Server的Peer節點同步了該註冊資訊，那麼register()方法被誰呼叫了呢？之前在Eureka Client的分析可以知道，Eureka Client是通過 http來向Eureka Server註冊的，那麼Eureka Server肯定會提供一個註冊的介面給Eureka Client呼叫，那麼PeerAwareInstanceRegistryImpl的register()方法肯定最終會被暴露的Http介面所呼叫。在Idea開發工具，按住alt+滑鼠左鍵，可以很快定位到ApplicationResource類的addInstance ()方法，即服務註冊的介面，其程式碼如下：
@POST
@Consumes({"application/json", "application/xml"})
public Response addInstance(InstanceInfo info,
@HeaderParam(PeerEurekaNode.HEADER_REPLICATION) String isReplication) {
...//省略程式碼
registry.register(info, "true".equals(isReplication));
return Response.status(204).build(); // 204 to be backwards compatible
}複製程式碼Renew服務續約
服務續約和服務註冊非常類似，通過之前的分析可以知道，服務註冊在Eureka Client程式啟動之後開啟，並同時開啟服務續約的定時任務。在eureka-client-1.6.2.jar的DiscoveryClient的類下有renew()方法，其程式碼如下：
/**
* Renew with the eureka service by making the appropriate REST call
*/
boolean renew() {
EurekaHttpResponse<InstanceInfo> httpResponse;
try {
httpResponse = eurekaTransport.registrationClient.sendHeartBeat(instanceInfo.getAppName(), instanceInfo.getId(), instanceInfo, null);
logger.debug("{} - Heartbeat status: {}", PREFIX + appPathIdentifier, httpResponse.getStatusCode());
if (httpResponse.getStatusCode() == 404) {
REREGISTER_COUNTER.increment();
logger.info("{} - Re-registering apps/{}", PREFIX + appPathIdentifier, instanceInfo.getAppName());
return register();
}
return httpResponse.getStatusCode() == 200;
} catch (Throwable e) {
logger.error("{} - was unable to send heartbeat!", PREFIX + appPathIdentifier, e);
return false;
}
}複製程式碼另外服務端的續約介面在eureka-core:1.6.2.jar的 com.netflix.eureka包下的InstanceResource類下，介面方法為renewLease()，它是REST介面。為了減少類篇幅，省略了大部分程式碼的展示。其中有個registry.renew()方法，即服務續約，程式碼如下:
@PUT
public Response renewLease(...引數省略）{
... 程式碼省略
boolean isSuccess=registry.renew(app.getName(),id, isFromReplicaNode);
... 程式碼省略
}複製程式碼讀者可以跟蹤registry.renew的程式碼一直深入研究。在這裡就不再多講述。另外服務續約有2個引數是可以配置，即Eureka Client傳送續約心跳的時間引數和Eureka Server在多長時間內沒有收到心跳將例項剔除的時間引數，在預設的情況下這兩個引數分別為30秒和90秒，官方給的建議是不要修改，如果有特殊要求還是可以調整的，只需要分別在Eureka Client和Eureka Server修改以下引數：
eureka.instance.leaseRenewalIntervalInSeconds
eureka.instance.leaseExpirationDurationInSeconds複製程式碼最後，服務註冊列表的獲取、服務下線和服務剔除就不在這裡進行原始碼跟蹤解讀，因為和服務註冊和續約類似，有興趣的朋友可以自己看下原始碼，深入理解。總的來說，通過讀原始碼，可以發現，整體架構與前面小節的eureka 的高可用架構圖完全一致。
Eureka Client註冊一個例項為什麼這麼慢
- Eureka Client一啟動（不是啟動完成），不是立即向Eureka Server註冊，它有一個延遲向服務端註冊的時間，通過跟蹤原始碼，可以發現預設的延遲時間為40秒，原始碼在eureka-client-1.6.2.jar的DefaultEurekaClientConfig類下，程式碼如下：
public int getInitialInstanceInfoReplicationIntervalSeconds() {
return configInstance.getIntProperty(
namespace + INITIAL_REGISTRATION_REPLICATION_DELAY_KEY, 40).get();
}複製程式碼Eureka Server的響應快取
Eureka Server維護每30秒更新的響應快取,可通過更改配置eureka.server.responseCacheUpdateIntervalMs來修改。 所以即使例項剛剛註冊，它也不會出現在呼叫/ eureka / apps REST端點的結果中。Eureka Server重新整理快取
Eureka客戶端保留登錄檔資訊的快取。 該快取每30秒更新一次（如前所述）。 因 此，客戶端決定重新整理其本地快取並發現其他新註冊的例項可能需要30秒。LoadBalancer Refresh
Ribbon的負載平衡器從本地的Eureka Client獲取服務註冊列表資訊。Ribbon本身還維護本地快取，以避免為每個請求呼叫本地客戶端。 此快取每30秒重新整理一次（可由ribbon.ServerListRefreshInterval配置）。 所以，可能需要30多秒才能使用新註冊的例項。
綜上幾個因素，一個新註冊的例項，特別是啟動較快的例項（預設延遲40秒註冊），不能馬上被Eureka Server發現。另外，剛註冊的Eureka Client也不能立即被其他服務呼叫，因為呼叫方因為各種快取沒有及時的獲取到新的註冊列表。
Eureka 的自我保護模式
當一個新的Eureka Server出現時，它嘗試從相鄰節點獲取所有例項登錄檔資訊。如果從Peer節點獲取資訊時出現問題，Eureka Serve會嘗試其他的Peer節點。如果伺服器能夠成功獲取所有例項，則根據該資訊設定應該接收的更新閾值。如果有任何時間，Eureka Serve接收到的續約低於為該值配置的百分比（預設為15分鐘內低於85％），則伺服器開啟自我保護模式，即不再剔除註冊列表的資訊。
這樣做的好處就是，如果是Eureka Server自身的網路問題，導致Eureka Client的續約不上，Eureka Client的註冊列表資訊不再被刪除，也就是Eureka Client還可以被其他服務消費。