學習自：【精選】Eureka原理看這一篇就夠了_阿小木的憤怒的博客-CSDN博客

1、分布式

分布式系統：由多個應用程序協同來完成任務的一種工作模式系統。這里的任務可能是一個下單操作、復雜的統計計算、存儲一個超大數據等等?？傊@種任務不適合或無法由單個程序獨立完成，需要多個程序協同完成。

2、服務發現

1）解耦、程序屏蔽 與 IP、端口依賴

分布式系統中，程序之間通過一次或多次遠程調用或數據傳輸完成任務。

調用程序前我們首先需要知道被調用程序在網絡中的位置，要在網絡中定位程序的位置自然會想到IP+Port的方式。但是這種方式存在兩個問題：

①IP地址沒有特殊含義，不便于記憶和理解；

②當被調用程序的IP、Port發生改變，調用者也要同步修改。

服務發現的作用之一：將程序之間對于IP+Port的依賴轉化為對服務名的依賴，服務名可以根據業務功能來命名。

因此，解耦、屏蔽服務間的IP+Port依賴是分布式系統需要解決的第一個問題。

2）動態管理服務狀態

分布式系統中，程序狀態是隨時變化、不可預測的，誰也無法保證下一秒某個程序還能正常運行（服務宕機、磁盤損壞、線程全被占用、網絡不穩定），如果某個程序掛掉，調用者不能及時知道，就會出現連鎖反應。

服務發現的作用之二：對服務狀態進行管理，當服務狀態發生改變，可以第一時間通知程序調用者：

①程序之間需要彼此知道對方的狀態和信息；

②對方程序狀態發生改變可以及時知曉。

3、Eureka如何設計服務發現

1）統一管理中心

服務發現要實現抽象程序標識達到解耦、屏蔽IP+Port、程序狀態實時管理。

要進行管理，就要有一個統一的管理中心——注冊中心。

注冊中心就是Eureka的大腦，負責Eureka各項管理、協調職能。

2）基本概念

Eureka對于管理者與被管理者進行了區分，管理者——注冊中心（S端），被管理者——干活的應用程序（C端），分別對應EurekaServer、EurekaClient。

 

　　S端-注冊中心-管理者

　　C端-提供服務與消費服務的應用程序-被管理者

3）基本流程

1. C端發起服務注冊；
2. S端保存注冊信息到注冊表；
3. C端定時發生心跳檢測；
4. S端服務剔除及自我保護；
5. C端發起服務下線；
6. C端或S端注冊信息到本地內存；
7. C端整合服務發現。

①C端發起服務注冊

C端向S端發送請求，將自身相關信息提交給S端。該過程稱為服務注冊。

Eureka S端會提供一個接口，用來接收C端服務注冊的請求，S端會一直監聽該接口，等待C端調用。

C端在啟動時先找到S端及自身信息（分區、服務名、IP、Port等），調用S端提供的服務注冊接口，將自身的信息發送過去。

配置信息可能在C端的配置文件中，也可能在配置中心統一配置。

②S端保存注冊信息

S端保存C端請求發送的服務注冊信息到本地內存注冊表。

注冊表是服務發現的核心，基本所有操作都是圍繞注冊表進行操作，注冊表的添加、獲取、更新、刪除、同步等一系列操作。

Eureka的注冊表是一個雙字典結構數據，服務發現的目的是標識服務和服務狀態的管理，因此注冊表中會有服務標識、服務基本信息、服務狀態信息等。

③C端定時發送心跳檢測

C端定時向S端發送請求服務，告訴S端自己正常運行。

C端只是啟動時注冊服務信息，后續運行過程中S端并不知道C端是否正常運行，就無法對C端狀態進行實時管理。因此C端定時不斷向S端發送請求，告訴S端自己正常運行，這種主動上報狀態的過程，在Eureka中稱為服務續約。

具體實現，S端提供一個續約接口，C端通過定時任務不斷調用續約接口，S端收到請求后，更新注冊表中服務續約時間。

④S端服務剔除和自我保護

S端如果一段時間內沒收到C端心跳請求，就從注冊表移除該C端。

心跳檢測時C端會定時發送心跳請求，S端收到請求會將注冊表中的服務續約時間進行更新，目的是S端可以實時知道C端運行狀態。

如果S端在一段時間（默認90s）沒收到C端心跳請求，此時S端認為C端掛掉，就會從注冊表中移除該C端信息，該過程稱為服務剔除。

 

網絡問題引發的通信中斷

有時由于網絡問題，C端和S端會無法通信，但是此時C端仍然正常運行，按照續約規則，所有的C端會從注冊表中被移除，這會影響那些正常運行的C端。

此時S端有自我保護機制來解決這種問題：

S端判斷15分鐘內，有超過85%的C端都沒有進行服務續約，則進入自我保護；

進入自我保護機制后，S端不再剔除未續約C端，S端只接收新C端的注冊與服務查詢。

 

⑤C端發送服務下線請求

C端正常關閉，向S端發送服務下線請求，S端會直接從注冊表移除該C端。

Eureka通過心跳續約、服務剔除來排查異常服務，對于正常關閉的服務，可以通過發送服務下線請求，使S端從注冊表移除C端，該過程稱為服務下線。

 

⑥C端定時獲取注冊表信息

C端分為生產者（服務提供者）和消費者（服務調用者）。

C端會定時向S端發送請求，獲取其注冊表信息，保存到本地內存。

在設計中，C端本地也有一個注冊表，還有一個定時器，定時從S端更新注冊表信息，保存到C端本地內存。

 ⑦C端整合服務發現

C端消費者從本地注冊表獲取C端生產者的服務信息，并進行后續操作。

 

4、Eureka如何保持高可用、一致性

Eureka支持集群部署，在不同機房部署多個S端實例，這樣可以橫向擴展服務發現的規模，當有一個S端掛掉，其他S端仍能正常運行，保證系統的高可用。但是集群多個節點部署時，需要考慮一個問題，就是數據一致性。

1）CAP理論

Linux：CAP定理——分布式計算 - ShineLe - 博客園

C（Consistency，一致性）：所有節點數據保持一致；

A（Available，可用性）：系統能對請求作出及時響應，不管響應成功還是失敗；

P（Partition Tolerance，分區容錯）：系統由于某些故障發生分區，各區系統仍能持續提供服務的能力。

這三者是一定無法同時滿足的。

作為一個分布式系統，P是必須滿足的，否則就失去了分布式的意義。

所以另一個特性只能在C（一致性）和A（可用性）中選擇一個：如果要保證一致性，就要進行所有節點的數據同步，該過程中無法保證系統可用性，會出現超時；如果要保證可用性，就無法保證一致性。

Eureka的設計中認為系統可用性優于一致性，采用AP，作為對比的zookeeper采用的是CP（下圖所示案例）：

當zookeeper體系下，雙機房之間網絡時，只有主節點所在的機房能進行正常的服務注冊，另一個機房中的從節點無法去主節點同步信息，所以在該機房中會注冊失敗。此時機房2中由于zk的一致性要求，犧牲了部分可用性。

而對于Eureka而言，采用的是AP，當網絡發生分區，機房2中的服務仍可以注冊，服務之間也能正常調用，但是兩個機房數據會不一致，為了可用性犧牲了一致性。

Eureka為什么采用AP？

在服務發現時注冊表信息不會涉及業務邏輯，保存的是一些服務器信息，這些信息不會經常發生變化，換句話說就是不一致的概率比較低，因此采用AP。

2）S端數據同步

分布式系統下數據同步模式一般分為兩種：主從模式、對等模式。

主從模式

集群中有一個主副本和多個從副本，主本負責寫入，之后會將數據同步到其他從本，從本負責讀操作。

該模式下主本面臨所有的寫操作，可能會成為瓶頸，但能保證一致性。

對等模式

集群中不存在主從副本，每個節點都能進行讀寫，之后節點之間進行相互數據同步，優點是沒有單點寫壓力，缺點是數據同步、數據沖突是個需要解決的問題。

Eureka中節點進行數據同步的示意圖

5、Eureka分區

region

地理上的分區，如亞洲分區、華北分區等等，地區沒有具體大小限制，根據實際劃分。

zone

可以理解為region下的具體分區（機房），例如北京分區下有兩個機房，可以劃分出兩個區域zone1、zone2。

通過分區管理，可以實現不同區域不同機房的服務進行就近調用，降低延遲。