服務發現與註冊 Eureka 設計理念，硬知識瞭解多少？

平衡之美

1。 AP 優於CP

· eureka是在部署AWS的背景下面設計的，其設計認為，在雲端，特別是大規模部署情況下面，失敗是不可以避免的，可能是因為eureka自身部署失敗或者網路分割槽等情況導致服務不可用，這些問題是不可以避免的，要解決這個問題就需要eureka在網路分割槽的時候，還能夠正常提供服務，因此eureka選擇滿足availability這個特性。

· eureka選擇了A也就必須放棄C，也就是說在eureka中採用最終一致性的方式來保證資料的一致性問題，因此例項的註冊資訊在叢集的所有節點之間的資料都不是強一性的，需要客戶端能支援負載均衡演算法及失敗重試等機制。

2。 Peer to Peer 架構

一般而言在分散式系統的資料有多個副本之間的複製方式，可以分為主從複製和對等複製

主從複製 Master-Slave模式

一個主副本和多個從副本，所有資料的寫操作都是提交到主副本，最後由主副本更新到其他的從副本（常採用非同步更新），通常寫是整個系統的瓶頸所在。

對等複製即Peer to Peer模式

副本之間不分主從，任何的副本都可以接受寫資料，然後副本之間進行資料更新。在對等複製中，由於每一個副本都可以進行寫操作，各個副本之間的資料同步及衝突處理是一個比較難解決的問題。

3。 Zone 及 Region 設計

· 使用region來代表一個獨立的地理區域，比如us-east-1、us-east-2，、us-west-1等。在每一個region下面還分為多個AvailabilityZone，一個region對應多個AvailabilityZone，不同的region之間相互隔離。預設情況下面資源只是在單個region之間的AvailabilityZone之間進行復制，跨region之間不會進行資源的複製。

· AvailabilityZone看成是region下面的一個一個機房，各個機房相對獨立，主要是為了region的高可用考慮的，一個region下面的機房掛了，還有其他的機房可以使用。

· 一個AvailabilityZone可以設定多個server例項，他們之間構成peer節點，然後採用peer to peer的複製模式進行資料複製。

4。 Self Preservation 設計

在分散式系統設計中，通常需要對應用例項的存活進行健康檢驗，這裡比較難處理的就是網路偶爾抖動或者短暫不可用而造成的誤判。因此eureka設計了self preservation機制。server和client之間有一個租約，client定期傳送心跳來維護這個租約，表示心跳還活著，eureka通過當前註冊的例項數量，去計算每分鐘應用從應用例項接受到的心跳數量，如果近一分鐘接受到的租約的次數小於等於指定的閾值，則關閉租約失效剔除，禁止定時任務剔除失效的例項，從而保護註冊資訊。