服務治理->搭建服務註冊中心： Spring Cloud Eur

服務治理

    服務治理可以說是微服務架構中最為核心和基礎的模組， 它主要用來實現各個微服務 例項的自動化註冊與發現。 為什麼我們在微服務架構中那麼需要服務治理模組呢？微服務 系統沒有它會有什麼不好的地方嗎？

    在最初開始構建微服務系統的時候可能服務並不多， 我們可以透過做一些靜態配置來 完成服務的呼叫。 比如，有兩個服務 A 和 B, 其中服務 A 需要呼叫服務 B 來完成一個業務 操作時， 為了實現服務 B 的高可用， 不論採用服務端負載均衡還是客戶端負載均衡， 都需 要手工維護服務 B 的具體例項清單。 但是隨著業務的發展， 系統功能越來越複雜， 相應的 微服務應用也不斷增加， 我們的靜態配置就會變得越來越難以維護。 並且面對不斷髮展的業務， 我們的叢集規模、 服務的位置 、 服務的命名等都有可能發生變化， 如果還是透過手 工維護的方式， 那麼極易發生錯誤或是命名衝突等問題。 同時， 對於這類靜態內容的維護 也必將消耗大量的人力。

    為了解決微服務架構中的服務例項維護問題， 產生了大量的服務治理框架和產品。 這 些框架和產品的實現都圍繞著服務註冊與服務發現機制來完成對微服務應用例項的自動化管理。

    • 服務註冊：在服務治理框架中， 通常都會構建一個註冊中心， 每個服務單元向註冊 中心登記自己提供的服務， 將主機與埠號、 版本號、 通訊協議等一些附加資訊告 知註冊中心， 註冊中心按服務名分類組織服務清單。 比如， 我們有兩個提供服務A 的程式分別執行於 192.168.0.100:8000和192.168.0.101:8000位置上， 另外還有三個 提供服務B的程式分別執行千192.168.0.100:9000 、 192.168.0.101:9000、 192.168.0.102:9000位置上。 當這些程式均啟動， 並向註冊中心註冊自己的服務之後， 註冊中心就會維護類似下面的一個服務清單。 另外， 服務註冊中心還需要以心跳的方式去監測清單中的服務是否可用， 若不可用 需要從服務清單中剔除， 達到排除故障服務的效果。

   服務名                                                              位置 

   服務A                                 192.168.0.100:8000、192.168.0.101:8000

   服務B                         192.168.0.100:9000、192.168.0.101:9000、192.168.0.102:9000

    • 服務發現：由於在服務治理框架下運作， 服務間的呼叫不再透過指定具體的例項地 址來實現， 而是透過向服務名發起請求呼叫實現。 所以， 服務呼叫方在呼叫服務提 供方介面的時候， 並不知道具體的服務例項位置。 因此， 呼叫方需要向服務註冊中 心諮詢服務， 並獲取所有服務的例項清單， 以實現對具體服務例項的訪問。 比如， 現有服務C希望呼叫服務A, 服務C就需要向註冊中心發起諮詢服務請求， 服務注 冊中心就會將服務A的位置清單返回給服務C, 如按上例服務A的情況，C便獲得 了服務A的兩個可用位置 192.168.0.100:8000和192.168.0.101:8000。 當服務C要發起呼叫的時候， 便從該清單中以某種輪詢策略取出一 個位置來進行服 務呼叫， 這就是後續我們將會介紹的客戶端負載均衡。 這裡我們只是列舉了一種簡 單的服務治理邏輯， 以方便理解服務治理框架的基本執行思路。 實際的框架為了性 能等因素， 不會採用每次都向服務註冊中心獲取服務的方式， 並且不同的應用場景 在快取和服務剔除等機制上也會有一些不同的實現策略。

   Spring Cloud Eureka, 使用Netflix Eureka來實現服務註冊與發現， 它既包含了服務端元件，也包含了客戶端元件，並且服務端與客戶端均採用Java編寫，所以Eureka主要適用 於透過Java實現的分散式系統，或是與NM相容語言構建的系統。但是， 由於Eureka服 務端的服務治理機制提供了完備的RESTfulAPL所以它也支援將非Java語言構建的微服 務應用納入Eureka的服務治理體系中來。只是在使用其他語言平臺的時候，需要自己來實 現Eureka的客戶端程式。不過慶幸的是，在目前幾個較為流行的開發平臺上，都已經有了 一些針對Eureka 註冊中心的客戶端實現框架， 比如.NET平臺的 Steeltoe、 Node.js 的 eureka-js-client等。

    Eureka服務端，我們也稱為服務註冊中心。 它同其他服務註冊中心一樣，支援高可用 配置。它依託於強一致性提供良好的服務例項可用性，可以應對多種不同的故障場景。 如 果Eureka以叢集模式部署，當叢集中有分片出現故障時，那麼Eureka就轉入自我保護模 式。它允許在分片故障期間繼續提供服務的發現和註冊，當故障分片恢復執行時， 叢集中 的其他分片會把它們的狀態再次同步回來。以在AWS 上的實踐為例， Netflix推薦每個可 用的區域執行一個Eureka服務端，透過它來形成叢集。不同可用區域的服務註冊中心透過 非同步模式互相複製各自的狀態，這意味著在任意給定的時間點每個例項關於所有服務的狀 態是有細微差別的。

    Eureka客戶端，主要處理服務的註冊與發現。客戶端服務透過註解和引數配置的方式， 嵌入在客戶端應用程式的程式碼中，在應用程式執行時，Eureka客戶端向註冊中心註冊自身 提供的服務並週期性地傳送心跳來更新它的服務租約。同時，它也能從服務端查詢當前注 冊的服務資訊並把它們快取到本地並週期性地重新整理服務狀態。

    下面我們來構建一些簡單示例，學習如何使用Eureka構建註冊中心以及進行註冊與發 現服務。

搭建服務註冊中心

    首先，建立一個基礎的Spring Boot工程，命名為eureka-server, 並在pom.xml 中引入必要的依賴內容， 程式碼如下：

		
    org.springframework.boot		
    spring-boot-starter-parent		
    1.5.10.RELEASE		
     <!-- lookup parent from repository --&gt	

           
     org.springframework.cloud    	   
     spring-cloud-starter-eureka-server           
     1.4.4.RELEASE		
 
 	
     			
         				
             org.springframework.cloud    			
             spring-cloud-dependencies    			
             Brixton.SR7    			
             pom    			
             import			
         		
     	
 

透過@EnableEurekaServer 註解啟動一個服務註冊中心提供給其他應用進行對話。 這一步非常簡單， 只需在一個普通的 Spring Boot 應用中新增這個註解就能開啟此功能， 比 如下面的例子：

    在預設設定下， 該服務註冊中心也會將自己作為客戶端來嘗試註冊它自己，所以我們 需要禁用它的客戶端註冊行為， 只需在 application.properties 中增加如下配置：

• eureka.client.register-with-eureka: 由於該應用為註冊中心，所以設定 為 false, 代表不向註冊中心註冊自己。

• eureka.client.fetch-registry: 由於註冊中心的職責就是維護服務例項， 它並不需要去檢索服務， 所以也設定為 false。

   在完成了上面的配置後，啟動應用並訪問 8081/。可以看到Eureka 資訊皮膚， 其中 Instances currently registered with Eureka 欄是空的， 說明該註冊中心還沒有註冊任何服務。