近期因工作原因減緩了更新頻率，同時為了把Spring Cloud中文社群搭建起來也費了不少時間，幾乎每天都在擠牙膏般的湊時間出來做一些有意義的事。未能按原計劃更新博文，在此對持續關注我部落格的朋友們深表歉意。

之前在寫spring Cloud系列文章的時候，列過一個較粗的計劃，現在由於收到不少反饋和問題，因此準備做一些調整，先將一些大家關注較為集中的點拉出來寫一些內容。

今天這篇主要就說說Eureka Server的高可用問題。

前言

在Spring Cloud系列文章的開始，我們就介紹了服務註冊與發現，其中，主要演示瞭如何構建和啟動服務註冊中心Eureka Server，以及如何將服務註冊到Eureka Server中，但是在之前的示例中，這個服務註冊中心是單點的，顯然這並不適合應用於線上生產環境，那麼下面在前文的基礎上，我們來看看該如何構建高可用的Eureka Server叢集。

單點Eureka Server的樣例：

Eureka Server的高可用

Eureka Server除了單點執行之外，還可以通過執行多個例項，並進行互相註冊的方式來實現高可用的部署，所以我們只需要將Eureke Server配置其他可用的serviceUrl就能實現高可用部署。

下面以Chapter1-1-1中的eureka-server為基礎，對其改造，構建雙節點的服務註冊中心。

• 建立application-peer1.properties，作為peer1服務中心的配置，並將serviceUrl指向peer2

• 建立application-peer2.properties，作為peer2服務中心的配置，並將serviceUrl指向peer1

• 在/etc/hosts檔案中新增對peer1和peer2的轉換

• 通過spring.profiles.active
  屬性來分別啟動peer1和peer2

• 此時訪問peer1的註冊中心：http://localhost:1111/，如下圖所示，我們可以看到registered-replicas中已經有peer2節點的eureka-server了。同樣地，訪問peer2的註冊中心：http://localhost:1112/，能看到registered-replicas中已經有peer1節點，並且這些節點在可用分片（available-replicase）之中。我們也可以嘗試關閉peer1，重新整理http://localhost:1112/，可以看到peer1的節點變為了不可用分片（unavailable-replicas）。

服務註冊與發現

在設定了多節點的服務註冊中心之後，我們主需要簡單需求服務配置，就能將服務註冊到Eureka Server叢集中。我們以Chapter1-1-1中的compute-service為基礎，修改application.properties配置檔案：

上面的配置主要對eureka.client.serviceUrl.defaultZone屬性做了改動，將註冊中心指向了之前我們搭建的peer1與peer2。

下面，我們啟動該服務，通過訪問http://localhost:1111/和http://localhost:1112/，可以觀察到compute-service同時被註冊到了peer1和peer2上。若此時斷開peer1，由於compute-service同時也向peer2註冊，因此在peer2上其他服務依然能訪問到compute-service，從而實現了高可用的服務註冊中心。

深入理解

雖然上面我們以雙節點作為例子，但是實際上因負載等原因，我們往往可能需要在生產環境構建多於兩個的Eureka Server節點。那麼對於如何配置serviceUrl來讓叢集中的服務進行同步，需要我們更深入的理解節點間的同步機制來做出決策。

Eureka Server的同步遵循著一個非常簡單的原則：只要有一條邊將節點連線，就可以進行資訊傳播與同步。什麼意思呢？不妨我們通過下面的實驗來看看會發生什麼。

• 場景一：假設我們有3個註冊中心，我們將peer1、peer2、peer3各自都將serviceUrl指向另外兩個節點。換言之，peer1、peer2、peer3是兩兩互相註冊的。啟動三個服務註冊中心，並將compute-service的serviceUrl指向peer1並啟動，可以獲得如下圖所示的叢集效果。

訪問http://localhost:1112/，可以看到3個註冊中心組成了叢集，compute-service服務通過peer1同步給了與之互相註冊的peer2和peer3。

• 場景二：依然假設我們有3個註冊中心，我們將peer1的serviceUrl指向peer2，peer2的指向peer3，peer3的指向peer1，此時peer1、peer2、peer3通過單向邊形成環。分別啟動peer1、peer2、peer3，並訪問資訊頁面，我們可以找到下面的規律，peer1成為了peer2的分片節點，peer2成為了peer3的分片節點，peer3則成為了peer1的分片節點，再將compute-service的serviceUrl指向peer1並啟動。放別訪問peer1、peer2、peer3的資訊頁面，可以發現compute-service均被peer2和peer3同步過去了，所以單向邊也能進行服務的傳播與同步。此時，我們斷開peer2，可以看到peer3中的compute-service消失了。重新開啟peer2並斷開peer3，可以看到peer2依然能同步到compute-service。所以我們可以得出結論，Eureka Server的傳播與同步是具備方向性的。

通過上面的實驗，我們可以得出下面的兩點結論來指導我們搭建服務註冊中心的高可用叢集：

• 兩兩註冊的方式可以實現叢集中節點完全對等的效果，實現最高可用性叢集，任何一臺註冊中心故障都不會影響服務的註冊與發現
• Eureka Server具備單方面有指向的服務傳播與同步機制，在一些對服務發現有限制的情況下，可以利用這樣的機制進行服務註冊與發現的的單向控制

本文完整示例可參考