Spring Cloud Eureka

我們使用微服務，微服務的本質還是各種API介面的呼叫，那麼我們怎麼產生這些介面、產生了這些介面之後如何進行呼叫那？如何進行管理哪？

答案就是Spring Cloud Eureka，我們可以將自己定義的API 介面註冊到Spring Cloud Eureka上，Eureka負責服務的註冊於發現，如果學習過Zookeeper的話，就可以很好的理解，Eureka的角色和 Zookeeper的角色差不多，都是服務的註冊和發現，構成Eureka體系的包括：服務註冊中心、服務提供者、服務消費者。

上圖中描述了（圖片來源於網路）：

1、兩臺Eureka服務註冊中心構成的服務註冊中心的主從複製叢集； 
2、然後服務提供者向註冊中心進行註冊、續約、下線服務等； 
3、服務消費者向Eureka註冊中心拉去服務列表並維護在本地（這也是客戶端發現模式的機制體現！）； 
4、然後服務消費者根據從Eureka服務註冊中心獲取的服務列表選取一個服務提供者進行消費服務。

1、在Eureka平臺中，如果某臺伺服器宕機，Eureka不會有類似於ZooKeeper的選舉leader的過程；客戶端請求會自動切換到新的Eureka節點；當宕機的伺服器重新恢復後，Eureka會再次將其納入到伺服器叢集管理之中；而對於它來說，所有要做的無非是同步一些新的服務註冊資訊而已。所以，再也不用擔心有“掉隊”的伺服器恢復以後，會從Eureka伺服器叢集中剔除出去的風險了。Eureka甚至被設計用來應付範圍更廣的網路分割故障，並實現“0”宕機維護需求。（多個zookeeper之間網路出現問題,造成出現多個leader，發生腦裂）當網路分割故障發生時，每個Eureka節點，會持續的對外提供服務（注：ZooKeeper不會）：接收新的服務註冊同時將它們提供給下游的服務發現請求。這樣一來，就可以實現在同一個子網中（same side of partition），新發布的服務仍然可以被發現與訪問。

2、正常配置下，Eureka內建了心跳服務，用於淘汰一些“瀕死”的伺服器；如果在Eureka中註冊的服務，它的“心跳”變得遲緩時，Eureka會將其整個剔除出管理範圍（這點有點像ZooKeeper的做法）。這是個很好的功能，但是當網路分割故障發生時，這也是非常危險的；因為，那些因為網路問題（注：心跳慢被剔除了）而被剔除出去的伺服器本身是很”健康“的，只是因為網路分割故障把Eureka叢集分割成了獨立的子網而不能互訪而已。

幸運的是，Netflix考慮到了這個缺陷。如果Eureka服務節點在短時間裡丟失了大量的心跳連線（注：可能發生了網路故障），那麼這個Eureka節點會進入”自我保護模式“，同時保留那些“心跳死亡“的服務註冊資訊不過期。此時，這個Eureka節點對於新的服務還能提供註冊服務，對於”死亡“的仍然保留，以防還有客戶端向其發起請求。當網路故障恢復後，這個Eureka節點會退出”自我保護模式“。所以Eureka的哲學是，同時保留”好資料“與”壞資料“總比丟掉任何”好資料“要更好，所以這種模式在實踐中非常有效。

3、Eureka還有客戶端快取功能（注：Eureka分為客戶端程式與伺服器端程式兩個部分，客戶端程式負責向外提供註冊與發現服務介面）。所以即便Eureka叢集中所有節點都失效，或者發生網路分割故障導致客戶端不能訪問任何一臺Eureka伺服器；Eureka服務的消費者仍然可以通過Eureka客戶端快取來獲取現有的服務註冊資訊。甚至最極端的環境下，所有正常的Eureka節點都不對請求產生相應，也沒有更好的伺服器解決方案來解決這種問題
時；得益於Eureka的客戶端快取技術，消費者服務仍然可以通過Eureka客戶端查詢與獲取註冊服務資訊，這點很重要。
4、Eureka的構架保證了它能夠成為Service發現服務。它相對與ZooKeeper來說剔除了Leader節點的選取或者事務日誌機制，這樣做有利於減少使用者維護的難度也保證了Eureka的在執行時的健壯性。而且Eureka就是為發現服務所設計的，它有獨立的客戶端程式庫，同時提供心跳服務、服務健康監測、自動釋出服務與自動重新整理快取的功能。但是，如果使用ZooKeeper你必須自己來實現這些功能。Eureka的所有庫都是開源的，所有人都能看到與使用這些原始碼，這比那些只有一兩個人能看或者維護的客戶端庫要好。

5、維護Eureka伺服器也非常的簡單，比如，切換一個節點只需要在現有EIP下移除一個現有的節點然後新增一個新的就行。Eureka提供了一個web-based的圖形化的運維介面，在這個介面中可以檢視Eureka所管理的註冊服務的執行狀態資訊：是否健康，執行日誌等。Eureka甚至提供了Restful-API介面，方便第三方程式整合Eureka的功能。