SpringCloud包含的微服務介紹

Eureka服務註冊與發現

為什麼需要註冊中心

當我們啟動專案時，我們通常會在屬性檔案中包含所有配置。隨著越來越多的服務的開發和部署，新增和修改這些屬性變得更加複雜。某些服務可能會停止執行，而某些服務可能會發生變化。手動更改屬性可能會產生問題。加上現在是開發都是微服務容器化部署，ip地址往往是動態，修改很麻煩，是有eureka的話只需要配置註冊服務的別名，就不用關注ip地址了，註冊中心可以自動獲取。

Eureka服務註冊和發現在這種情況下有所幫助。由於所有服務都已註冊到Eureka伺服器並通過呼叫Eureka Server完成查詢，因此無需處理服務位置的任何更改，並使用Netflix Eureka處理使用Spring雲的微服務註冊和發現。

Eureka 註冊中心三種角色

Eureka Server

通過 Register、Get、Renew 等介面提供服務的註冊和發現。

Application Service（Service Provider）

服務提供方，把自身的服務例項註冊到 Eureka Server 中。

Application Client（Service Consumer）

Eureka註冊中心工作流程

Eurka 工作流程

瞭解完 Eureka 核心概念，自我保護機制，以及叢集內的工作原理後，我們來整體梳理一下 Eureka 的工作流程：

1、Eureka Server 啟動成功，等待服務端註冊。在啟動過程中如果配置了叢集，叢集之間定時通過 Replicate 同步登錄檔，每個 Eureka Server 都存在獨立完整的服務登錄檔資訊

2、Eureka Client 啟動時根據配置的 Eureka Server 地址去註冊中心註冊服務

3、Eureka Client 會每 30s 向 Eureka Server 傳送一次心跳請求，證明客戶端服務正常

4、當 Eureka Server 90s 內沒有收到 Eureka Client 的心跳，註冊中心則認為該節點失效，會登出該例項

5、單位時間內 Eureka Server 統計到有大量的 Eureka Client 沒有上送心跳，則認為可能為網路異常，進入自我保護機制，不再剔除沒有上送心跳的客戶端

6、當 Eureka Client 心跳請求恢復正常之後，Eureka Server 自動退出自我保護模式

7、Eureka Client 定時全量或者增量從註冊中心獲取服務登錄檔，並且將獲取到的資訊快取到本地

8、服務呼叫時，Eureka Client 會先從本地快取找尋調取的服務。如果獲取不到，先從註冊中心重新整理登錄檔，再同步到本地快取

9、Eureka Client 獲取到目標伺服器資訊，發起服務呼叫

10、Eureka Client 程式關閉時向 Eureka Server 傳送取消請求，Eureka Server 將例項從登錄檔中刪除

這就是Eurka基本工作流程

為什麼同樣是服務註冊中心，Spingcloud選擇了Eureka而不是ZooKeeper

Eureka的優勢

• 在Eureka平臺中，如果某臺伺服器當機，Eureka不會有類似於ZooKeeper（注：ZooKeeper是著名Hadoop的一個子專案，旨在解決大規模分散式應用場景下，服務協調同步（Coordinate Service）的問題；它可以為同在一個分散式系統中的其他服務提供：統一命名服務、配置管理、分散式鎖服務、叢集管理等功能）的選舉leader的過程；客戶端請求會自動切換到新的Eureka節點；當當機的伺服器重新恢復後，Eureka會再次將其納入到伺服器叢集管理之中；而對於它來說，所有要做的無非是同步一些新的服務註冊資訊而已。所以，再也不用擔心有“掉隊”的伺服器恢復以後，會從Eureka伺服器叢集中剔除出去的風險了。
• 正常配置下，Eureka內建了心跳服務，用於淘汰一些“瀕死”的伺服器；如果在Eureka中註冊的服務，它的“心跳”變得遲緩時，Eureka會將其整個剔除出管理範圍（這點有點像ZooKeeper的做法）。
  同時，為了避免因為網路問題導致被剔除出去的伺服器本身是很”健康“的，Eureka節點會進入“自我保護模式”，當網路故障恢復後，這個Eureka節點會退出”自我保護模式“。所以Eureka的哲學是，同時保留”好資料“與”壞資料“總比丟掉任何”好資料“要更好，所以這種模式在實踐中非常有效。
• Eureka還有客戶端快取功能（注：Eureka分為客戶端程式與伺服器端程式兩個部分，客戶端程式負責向外提供註冊與發現服務介面）。所以即便Eureka叢集中所有節點都失效，或者發生網路分割故障導致客戶端不能訪問任何一臺Eureka伺服器；Eureka服務的消費者仍然可以通過Eureka客戶端快取來獲取現有的服務註冊資訊。
• Eureka的構架保證了它能夠成為Service發現服務。它相對與ZooKeeper來說剔除了Leader節點的選取或者事務日誌機制，這樣做有利於減少使用者維護的難度也保證了Eureka的在執行時的健壯性。而且Eureka就是為發現服務所設計的，它有獨立的客戶端程式庫，同時提供心跳服務、服務健康監測、自動釋出服務與自動重新整理快取的功能。但是，如果使用ZooKeeper你必須自己來實現這些功能。Eureka的所有庫都是開源的，所有人都能看到與使用這些原始碼，這比那些只有一兩個人能看或者維護的客戶端庫要好。
• 維護Eureka伺服器也非常的簡單，比如，切換一個節點只需要在現有EIP下移除一個現有的節點然後新增一個新的就行。Eureka提供了一個web-based的圖形化的運維介面，在這個介面中可以檢視Eureka所管理的註冊服務的執行狀態資訊：是否健康，執行日誌等。Eureka甚至提供了Restful-API介面，方便第三方程式整合Eureka的功能。

ZooKeeper的劣勢

4.4 ZooKeeper作為發現服務的問題

• 在分散式系統領域有個著名的CAP定理（C-資料一致性；A-服務可用性；P-服務對網路分割槽故障的容錯性，這三個特性在任何分散式系統中不能同時滿足，最多同時滿足兩個）；ZooKeeper是個CP的，即任何時刻對ZooKeeper的訪問請求能得到一致的資料結果，同時系統對網路分割具備容錯性；但是它不能保證每次服務請求的可用性（注：也就是在極端環境下，ZooKeeper可能會丟棄一些請求，消費者程式需要重新請求才能獲得結果）。但是別忘了，ZooKeeper是分散式協調服務，它的職責是保證資料（注：配置資料，狀態資料）在其管轄下的所有服務之間保持同步、一致；所以就不難理解為什麼ZooKeeper被設計成CP而不是AP特性的了，如果是AP的，那麼將會帶來恐怖的後果（注：ZooKeeper就像交叉路口的訊號燈一樣，你能想象在交通要道突然訊號燈失靈的情況嗎？）。而且，作為ZooKeeper的核心實現演算法Zab，就是解決了分散式系統下資料如何在多個服務之間保持同步問題的。

• 作為一個分散式協同服務，ZooKeeper非常好，但是對於Service發現服務來說就不合適了；因為對於Service發現服務來說就算是返回了包含不實的資訊的結果也比什麼都不返回要好；再者，對於Service發現服務而言，寧可返回某服務5分鐘之前在哪幾個伺服器上可用的資訊，也不能因為暫時的網路故障而找不到可用的伺服器，而不返回任何結果。所以說，用ZooKeeper來做Service發現服務是肯定錯誤的，如果你這麼用就慘了！

• 而且，如果被用作Service發現服務，ZooKeeper本身並沒有正確的處理網路分割的問題；而在雲端，網路分割問題跟其他型別的故障一樣的確會發生；所以最好提前對這個問題做好100%的準備。就像Jepsen在ZooKeeper網站上釋出的部落格中所說：在ZooKeeper中，如果在同一個網路分割槽（partition）的節點數（nodes）數達不到ZooKeeper選取Leader節點的“法定人數”時，它們就會從ZooKeeper中斷開，當然同時也就不能提供Service發現服務了。

• 如果給ZooKeeper加上客戶端快取（注：給ZooKeeper節點配上本地快取）或者其他類似技術的話可以緩解ZooKeeper因為網路故障造成節點同步資訊錯誤的問題。Pinterest與Airbnb公司就使用了這個方法來防止ZooKeeper故障發生。這種方式可以從表面上解決這個問題，具體地說，當部分或者所有節點跟ZooKeeper斷開的情況下，每個節點還可以從本地快取中獲取到資料；但是，即便如此，ZooKeeper下所有節點不可能保證任何時候都能快取所有的服務註冊資訊。如果ZooKeeper下所有節點都斷開了，或者叢集中出現了網路分割的故障（注：由於交換機故障導致交換機底下的子網間不能互訪）；那麼ZooKeeper會將它們都從自己管理範圍中剔除出去，外界就不能訪問到這些節點了，即便這些節點本身是“健康”的，可以正常提供服務的；所以導致到達這些節點的服務請求被丟失了。（注：這也是為什麼ZooKeeper不滿足CAP中A的原因）

• 更深層次的原因是，ZooKeeper是按照CP原則構建的，也就是說它能保證每個節點的資料保持一致，而為ZooKeeper加上快取的做法的目的是為了讓ZooKeeper變得更加可靠（available）；但是，ZooKeeper設計的本意是保持節點的資料一致，也就是CP。所以，這樣一來，你可能既得不到一個資料一致的（CP）也得不到一個高可用的（AP）的Service發現服務了；因為，這相當於你在一個已有的CP系統上強制栓了一個AP的系統，這在本質上就行不通的！一個Service發現服務應該從一開始就被設計成高可用的才行！

• 如果拋開CAP原理不管，正確的設定與維護ZooKeeper服務就非常的困難；錯誤會經常發生，導致很多工程被建立只是為了減輕維護ZooKeeper的難度。這些錯誤不僅存在與客戶端而且還存在於ZooKeeper伺服器本身。Knewton平臺很多故障就是由於ZooKeeper使用不當而導致的。那些看似簡單的操作，如：正確的重建觀察者（reestablishing watcher）、客戶端Session與異常的處理與在ZK視窗中管理記憶體都是非常容易導致ZooKeeper出錯的。同時，我們確實也遇到過ZooKeeper的一些經典bug：ZooKeeper-1159 與ZooKeeper-1576；我們甚至在生產環境中遇到過ZooKeeper選舉Leader節點失敗的情況。這些問題之所以會出現，在於ZooKeeper需要管理與保障所管轄服務群的Session與網路連線資源（注：這些資源的管理在分散式系統環境下是極其困難的）；但是它不負責管理服務的發現，所以使用ZooKeeper當Service發現服務得不償失。

Why 為什麼eureka 做什麼，沒有之前都怎麼實現 現在容器化 ip是動態
How 怎麼實現 註冊方 怎麼註冊。呼叫方怎麼呼叫 有沒有快取