Spring Cloud Eureka 是 Spring Cloud Netflix 微服務套件中的一部分， 它基于 Netflix Eureka 做了二次封裝， 主要負責完成微服務架構中的服務治理功能。 Spring Cloud 通過為 Eureka 增加了 Spring Boot 風格的自動化配置，我們只需通過簡單引入依賴和注解配置就能 讓 Spring Boot 構建的微服務應用輕松地與 Eureka 服務治理體系進行整合。

在本章中， 我們將指引讀者學習下面這些核心內容， 并構建起用于服務治理的基礎設施。

? 構建服務注冊中心

? 服務注冊與服務發現

? Eureka 的基礎架構

? Eureka 的服務治理機制

? Eureka 的配置

服務治理

服務治理可以說是微服務架構中最為核心和基礎的模塊， 它主要用來實現各個微服務 實例的自動化注冊與發現。 為什么我們在微服務架構中那么需要服務治理模塊呢？微服務系統沒有它會有什么不好的地方嗎？ 在最初開始構建微服務系統的時候可能服務并不多， 我們可以通過做一些靜態配置來 完成服務的調用。 比如，有兩個服務 A 和 B, 其中服務 A 需要調用服務 B 來完成一個業務 操作時， 為了實現服務 B 的高可用， 不論采用服務端負載均衡還是客戶端負載均衡， 都需 要手工維護服務 B 的具體實例清單。 但是隨著業務的發展， 系統功能越來越復雜， 相應的 微服務應用也不斷增加， 我們的靜態配置就會變得越來越難以維護。 并且面對不斷發展的? Spring Cloud微服務實戰 業務， 我們的集群規模、 服務的位置 、 服務的命名等都有可能發生變化， 如果還是通過手 工維護的方式， 那么極易發生錯誤或是命名沖突等問題。 同時， 對于這類靜態內容的維護也必將消耗大量的人力。

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

? 服務注冊：在服務治理框架中， 通常都會構建一個注冊中心， 每個服務單元向注冊中心登記自己提供的服務， 將主機與端口號、 版本號、 通信協議等一些附加信息告知注冊中心， 注冊中心按服務名分類組織服務清單。 比如， 我們有兩個提供服務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要發起調用的時候， 便從該清單中以某種輪詢策略取出一個位置來進行服務調用， 這就是后續我們將會介紹的客戶端負載均衡。 這里我們只是列舉了一種簡單的服務治理邏輯， 以方便理解服務治理框架的基本運行思路。 實際的框架為了性能等因素， 不會采用每次都向服務注冊中心獲取服務的方式， 并且不同的應用場景在緩存和服務剔除等機制上也會有一些不同的實現策略。

總結

以上是生活随笔為你收集整理的SpringCloud Eureka服务治理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。