簡介：Spring Cloud Eureka 是Spring Cloud Netflix微服務套件中的一部分，他基於 Netflix Eureka做了二次封裝，主要負責完成微服務架構中的服務治理功能。Spring Cloud通過爲Eureka增加了Spring Boot風格的自動化配置，我們只需通過引入簡單的依賴和註解配置就能讓Spring Cloud構建的微服務應用輕鬆的與Eureka 服務治理體系進行整合。
1、服務治理
服務爲什麼需要治理？
早期的各個微服務之間相互調用，只是簡單的A調用B，爲了實現B的高可用，不論是服務端負載均衡還是客戶端的負載均衡，我們需要手動維護B 的具體實例清單，隨着業務的發展，系統功能越來越複雜，相應的微服務也越來越多，我們的靜態配置也變得難以維護，所以我們需要一個註冊中心，進行統一的微服務管理，這裏所說的管理就是 服務的註冊與發現。
服務註冊：即所有的應用服務想註冊中心，提供自己的詳細信息，注入ip、端口、服務名稱等信息。註冊中心還需要以心跳的方式檢測清單中的服務是否可用。
服務發現：當A需要調用B時，只需要向註冊中心索取服務名叫做B 的所有服務即可，然後通過比如輪訓調用策略進行調用。
2、Netflix Eureka
3、搭建服務註冊中心
首先，創建一個基礎的SpringBoot工程，引入必要的依賴：
並在SpringBoot項目主啓動類加上@EnableEurekaServer註解啓動一個服務註冊中心提供給其他應用進行對話。
在默認配置下，該註冊中心也會將自己作爲客戶端來嘗試註冊他自己，就是自己往自己本身進行註冊，這無疑形成了套娃，大可不必。我們需要禁止它的客戶端行爲，只需在application.properties
中增加如下配置：
- eureka.client.register-with-eureka :由於該應用爲註冊中心，設置爲false,標識不再想自己註冊自己
- eureka.clinet.fetch-registry :表示是否從Eureka Server獲取註冊的服務信息，註冊中心的職責本倆就是維護服務實力，他並不需要去服務端檢索獲取信息，因爲它就是它自己。所以設置爲false。
- eureka.clinet.serviceUrl.defaultZone :設置與Eureka Server交互的地址，查詢服務和註冊服務都需要依賴這個地址。多個地址可使用 " , "分隔 。
4、註冊服務提供者
1）修改pom.xml增加Spring Cloud Eureka模塊的依賴
2）主啓動類上添加@EnableDiscoveryClinet 註解，啓用服務註冊發現功能。
3) 修改 application.properties 配置文件，設置name 應用名，和註冊中心地址：
此時，啓動該服務，可在註冊中心發現該服務的註冊信息。
5、高可用註冊中心
單節點的註冊中心在生產環境顯然不合適，爲了達到軟件高可用的必要配置，我們需要多個Eureka相互註冊，共享服務信息的同時並向其他服務提供發現服務的功能。
我們可以在剛纔基礎之上搭建一個高可用的註冊中心：
通過spring.profile.active屬性來分別啓動peer1和peer2：
6、服務發現與消費
服務消費者主要有兩方面：服務的發現 與 消費 ，其中服務的發現任務有Eureka客戶端完成，而服務的消費任務有Ribbon完成 。 Ribbon是一個基於HTTP 和TCP的客戶端負載均衡器，他可以通過客戶端配置的ribbonServerList服務端列表去輪訓訪問已達到均衡負載的作用。當Ribbon與Eureka聯合使用是，Ribbon的服務實力清單 RibbonServeList會被DicoveryEnableNIWSServerList重寫，擴展成從Eureka註冊中心獲取服務列表。本章不對Ribbon做詳細介紹，你只需要清除它在Eureka服務發現的基礎之上，實現了一套對服務實力的選擇策略，從而實現消費服務。
創建SpringBoot基礎工程 構建消費者，取名爲ribbon-consumer，
1）pom.xml引入依賴：
2）在主類添加@EnableDicoveryClinet註解 ：讓該應用同樣註冊爲Eureka客戶端應用，以獲得服務發現能力。
3）在主類中穿點RestTemplate的Spring Bean 實例，並通過@LoadBalanced註解開啓客戶端負載均衡。
4）創建C〇nsumerC〇ntr〇lle：類並實現/ribbon—consumer接口。在該接口中， 通過在上面創建的 RestTemplate來實現對 HELLO- SERVICE服務提供的 /hello接口進行調用。可以看到這裏訪問的地址是服務名HELLO-SERVICE，而 不是一個具體的地址，在服務治理框架中，這是一個非常重要的特性，也符合在本 章一開始對服務治理的解釋。
在application .properties中配置Eureka服務註冊中心的位置，需要與之前 的HELLO-SERVICE—樣，不然是發現不了該服務的，同時設置該消費者的端口爲 9000，不能與之前啓動的應用端口衝突。
7、Eureka架構及服務治理機制詳解
在上一節中，我們通過一個簡單的服務註冊於實例發現，構建了Eureka服務治理體系中的三個核心角色：服務註冊中心、服務提供者以及服務消費者。通過上述示例，相信讀者對於Eureka的服務治理機制已經有了初步認識。至此，我們已經學會了如何構建服務註冊中心（包括單節點和高可用部署），也知道了如何使用Eureka的註解和配置將SpringBoot應用納入Eureka的服務治理體系，成爲服務提供者或服務消費者，同時對於客戶端負載均衡的服務消費也有了一些簡單的接觸。但是，在實踐中，我們的系統結構往往都要比上述複雜的多，我們還需要根據實際情況做一些配置、調整和擴展。
註冊中心 - 服務提供者 - 服務消費者：
服務提供者：
服務註冊：“服務提供者”在啓動的時候會通過發送REST請求的方式將自己註冊到Eureka Server上，同時帶上自身服務的一些元數據信息。Eureka Server 接收到這個REST請求之後，講這些元數據信息存儲到一個雙層結構的Map中，其中第一層的key是服務名，第二層的key是具體的服務實例名。（我們可以回想一下之前在實現Ribbon負載的例子中，Eureka信息面板中一個服務有多個實例的情況，這些內容就是以這樣的雙層Map形式存儲的。）
在服務註冊時需要確認一下eureka.clinet.register-with-eureka=true參數是否正確，該值默認爲true。若設置爲false將不會啓動註冊操作，自然不會被其他消費者獲得其信息。
服務同步：如架構圖中所示，這裏的兩個服務提供者註冊到了兩個不同的服務註冊中心上，也就是說，他們的信息分別被兩個服務註冊中心所維護。此時，由於服務註冊中心之間銀湖想註冊爲服務，當服務提供者發送註冊請求到一個服務註冊中心時，他會將該請求轉發給集羣中相連的其他註冊中心，從而實現註冊中心之間的服務同步。通過服務同步，兩個服務提供者的服務信息就可以通過這兩臺服務註冊中心的任意一臺獲取到。
服務續約：
服務消費者：
獲取服務：
服務調用：
服務下線：
註冊中心：
失效剔除：
自我保護：