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通過當前注冊的實例數量，去計算每分鐘應用從應用實例接受到的心跳數量，如果近一分鐘接受到的租約的次數小于等于指定的閾值，則關閉租約失效剔除，禁止定時任務剔除失效的實例，從而保護注冊信息。

自我保護模式的設計哲學是：在不確定節點是否可用的情況下，盡可能保留節點!