Spring Cloud Eureka是Spring Cloud Netflix微服務套件中的壹部分，它基於Netflix
Eureka做了二次封裝，主要負責完成微服務架構中的服務治理功能。Spring Cloud通過為
Eureka增加了Spring Boot風格的自動化配置，我們只需通過簡單引入依賴和註解配置就能
讓Spring Boot構建的微服務應用輕松地與Eureka服務治理體系進行整合。
在本章中，我們將指引讀者學習下面這些核心內容，並構建起用於服務治理的基礎設
施。
·構建服務註冊中心
·服務註冊與服務發現
。Eureka的基礎架構
Eureka的服務治理機制
Eureka的配置
服務治理
服務治理可以說是微服務架構中最為核心和基礎的模塊，它主要用來實現各個微服務
實例的自動化註冊與發現。為什麽我們在微服務架構中那麽需要服務治理模塊呢？微服務
系統沒有它會有什麽不好的地方嗎？
在最初開始構建微服務系統的時候可能服務並不多，我們可以通過做壹些靜態配置來
完成服務的調用。比如，有兩個服務A和B,其中服務A需要調用服務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。
當服務要發起調用的時候，便從該清單中以某種輪詢策略取出壹個位置來進行服
務調用，這就是後續我們將會介紹的客戶端負載均衡。這裏我們只是列舉了壹種簡
單的服務治理邏輯，以方便理解服務治理框架的基本運行思路。實際的框架為了性
能等因素，不會采用每次都向服務註冊中心獲取服務的方式，並且不同的應用哦場景
在緩存和服務剔除等機制上也會有壹些不同的實現策略。