SpringCloud（6）Eureka架構與CAP原則與取捨策略
- 2021 年 6 月 25 日
- 筆記
- SpringCloud
一：Eureka架構
Register(服務註冊)：把自己的 IP 和埠註冊給 Eureka。
Renew(服務續約)：發送心跳包，每 30 秒發送一次，告訴 Eureka 自己還活著。如果 90 秒還未發送心跳，宕
機。
Cancel(服務下線)：當 Provider 關閉時會向 Eureka 發送消息，把自己從服務列表中刪除。防止 Consumer 調
用到不存在的服務。
Get Registry(獲取服務註冊列表)：獲取其他服務列表。
Replicate(集群中數據同步)：Eureka 集群中的數據複製與同步。
Make Remote Call(遠程調用)：完成服務的遠程調用。
二： CAP原則與取捨策略
C（一致性）：代表的是：數據不管微服務的節點有多少個，最終數據和所有節點數據是一致的。
A（可用性）：不超時，立馬響應
P（分區容錯）： 多塊區域的數據
CAP 原則又稱 CAP 定理，指的是在一個分散式系統中具有以下其中兩個特性：
Consistency （一致性）
Availability （可用性）
Partition tolerance（分區容錯性）
CAP 由 Eric Brewer 在 2000 年 PODC 會議上提出。該猜想在提出兩年後被證明成立，成為我們熟知的 CAP 定
理。CAP 三者不可兼得。
取捨策略
CAP 三個特性只能滿足其中兩個，那麼取捨的策略就共有三種：
CA without P：如果不要求P（不允許分區），則C（強一致性）和A（可用性）是可以保證的。但放棄 P 的同
時也就意味著放棄了系統的擴展性，也就是分散式節點受限，沒辦法部署子節點，這是違背分散式系統設計的
初衷的。
CP without A：如果不要求A（可用），相當於每個請求都需要在伺服器之間保持強一致，而P（分區）會導致
同步時間無限延長（也就是等待數據同步完才能正常訪問服務），一旦發生網路故障或者消息丟失等情況，就
要犧牲用戶的體驗，等待所有數據全部一致了之後再讓用戶訪問系統。設計成 CP 的系統其實不少，最典型的就
是分散式資料庫，如 Redis、HBase 等。對於這些分散式資料庫來說，數據的一致性是最基本的要求，因為如
果連這個標準都達不到，那麼直接採用關係型資料庫就好，沒必要再浪費資源來部署分散式資料庫。
AP without C：要高可用並允許分區，則需放棄一致性。一旦分區發生，節點之間可能會失去聯繫，為了高可
用，每個節點只能用本地數據提供服務，而這樣會導致全局數據的不一致性。典型的應用就如某米的搶購手機
場景，可能前幾秒你瀏覽商品的時候頁面提示是有庫存的，當你選擇完商品準備下單的時候，系統提示你下單
失敗，商品已售完。這其實就是先在 A（可用性）方面保證系統可以正常的服務，然後在數據的一致性方面做
了些犧牲，雖然多少會影響一些用戶體驗，但也不至於造成用戶購物流程的嚴重阻塞。
總結
現如今，對於多數大型互聯網應用的場景，主機眾多、部署分散，而且現在的集群規模越來越大，節點只會越來
越多，所以節點故障、網路故障是常態，因此分區容錯性也就成為了一個分散式系統必然要面對的問題。那麼就只能
在 C 和 A 之間進行取捨。但對於傳統的項目就可能有所不同，拿銀行的轉賬系統來說，涉及到金錢的對於數據一致
性不能做出一絲的讓步，C 必須保證，出現網路故障的話，寧可停止服務，可以在 A 和 P 之間做取捨。
總而言之，沒有最好的策略，好的系統應該是根據業務場景來進行架構設計的，只有適合的才是最好的。
