Eureka -- 淺談Eureka

目錄：

　　一：Eureka介紹

　　二：Eureka架構圖

　　三：Eureka組件

　　四：Eureka做用

　　五：Eureka和Zookeeper對比

什麼是Eureka

　　引入SpringCloud中文文檔介紹

Eureka is a REST (Representational State Transfer) based service that is primarily used in the AWS cloud for locating services for the purpose of load balancing and failover of middle-tier servers.

At Netflix, Eureka is used for the following purposes apart from playing a critical part in mid-tier load balancing.

• For aiding Netflix Asgard - an open source service which makes cloud deployments easier, in

  • Fast rollback of versions in case of problems avoiding the re-launch of 100's of instances which could take a long time.
  • In rolling pushes, for avoiding propagation of a new version to all instances in case of problems.

• For our cassandra deployments to take instances out of traffic for maintenance.

• For our memcached caching services to identify the list of nodes in the ring.

• For carrying other additional application specific metadata about services for various other reasons.

　　意思爲：

Eureka是一種基於REST（Representational State Transfer）的服務，主要用於AWS雲，用於定位服務，以實現中間層服務器的負載平衡和故障轉移。

在Netflix，除了在中間層負載平衡中起關鍵做用以外，Eureka還用於如下目的。

• 爲了幫助Netflix Asgard - 一種開源服務，能夠更輕鬆地實現雲部署

  • 在出現問題的狀況下快速回滾版本，避免從新啓動可能須要很長時間的100個實例。
  • 在滾動推送中，以免在出現問題時將新版本傳播到全部實例。

• 對於咱們的cassandra部署，將實例從流量中取出進行維護。

• 對於咱們的memcached緩存服務來識別環中的節點列表。

• 因爲各類其餘緣由而攜帶有關服務的其餘應用程序特定元數據。

 

Eureka架構圖

　　上面的架構圖描述了Eureka是如何在Netflix部署的，這也是Eureka集羣的運行方式。在每一個區域（region）都有一個eureka集羣，它只知道該區域內的實例信息。每一個分區（zone）至少有一個eureka服務器來處理本分區故障。

　　服務註冊在Eureka上而且每30秒發送心跳來續租。若是一個客戶端在幾回內沒有刷新心跳，它將在大約90秒內被移出服務器註冊表。註冊信息和更新信息會在整個eureka集羣的節點進行復制。任何分區的客戶端均可查找註冊中心信息（每30秒發生一次）來定位他們的服務（可能會在任何分區）並進行遠程調用。

　　摘自：Eureka at a glance  

Eureka組件

　　Eureka包含兩個組件：Eureka Server和Eureka Client。

　　Eureka Server提供服務註冊服務，各個節點啓動後，會在Eureka Server中進行註冊，這樣EurekaServer中的服務註冊表中將會存儲全部可用服務節點的信息，服務節點的信息能夠在界面中直觀的看到。

　　Eureka Client是一個java客戶端，用於簡化與Eureka Server的交互，客戶端同時也就別一個內置的、使用輪詢(round-robin)負載算法的負載均衡器。

　　在應用啓動後，將會向Eureka Server發送心跳,默認週期爲30秒，若是Eureka Server在多個心跳週期內沒有接收到某個節點的心跳，Eureka Server將會從服務註冊表中把這個服務節點移除(默認90秒)。

　　Eureka Server之間經過複製的方式完成數據的同步，Eureka還提供了客戶端緩存機制，即便全部的Eureka Server都掛掉，客戶端依然能夠利用緩存中的信息消費其餘服務的API。綜上，Eureka經過心跳檢查、客戶端緩存等機制，確保了系統的高可用性、靈活性和可伸縮性。

　　摘自： Eureka（服務發現框架）

Eureka做用

　　在多個服務節點下，若是經過人爲管理地址配置，隨着節點增多，會出現不方便管理，不方便維護的狀況。  所以須要一一個服務治理的中間件協助咱們管理註冊的服務節點。

　　常見的註冊中心有　　　

　　　　如: eureka ，zookeeper, consul, redis等。-般在eureka中會保存節點的IP地址，端口號，服務名等

 

      註冊方式
　　　　1.中心化配置:用一個統一的註冊中心管理各個節點，如zookeeper

　　　　2.去中心化配置:每一個服務既是服務端又是客戶端，如: eureka 

Zookeeper和Eureka對比

　　著名的CAP理論指出，一個分佈式系統不可能同時知足C(一致性)、A(可用性)和P(分區容錯性)。因爲分區容錯性在是分佈式系統中必需要保證的，所以咱們只能在A和C之間進行權衡。在此Zookeeper保證的是CP, 而Eureka則是AP。

　　zookeeper優先保證CP，當服務發生故障會進行leader的選舉，整個期間服務處在不可用狀態，若是選舉時間過長勢必會大幅度下降性能，另外就用途來講zookeeper偏向於服務的協調，固然含有註冊中心的做用

　　eureka優先保證AP, 即服務的節點各個都是平等的，沒有leader不leader一說， 當服務發生故障時，其他的節點仍然能夠提供服務，所以在出現故障時，性能表現優於zookeeper，可是可能會形成數據不一致的狀況。

 

　總結：Eureka做爲單純的服務註冊中心來講要比zookeeper更加「專業」，由於註冊服務更重要的是可用性，咱們能夠接受短時間內達不到一致性的情況。