SpringCloud微服務_3 Eureka註冊中心實現原理
作者：田超凡
版權所有，轉載請註明原作者，仿冒侵權必究法律責任
1 Eureka註冊中心
剛纔對註冊中心的作用和實現原理進行了簡要介紹，那麼接下來就開始搭建一個基於SpringCloud2.0 Greenwich S3版本的Eureka註冊中心吧。Eureka註冊中心始源國外的一個開源視頻網站netflix，後來netflix傻乎乎的把組件提供給了SpringCloud研發團隊，現在估計哭不出來了。
需要注意的是Eureka目前是閉源的，剛開始在SpringCloud1.0中開始開源的，後來不知道爲什麼就閉源了，但是不用擔心，SpringCloud2.0中直接把Eureka作爲內置且官方推薦的註冊中心，並且對Eureka註冊中心功能進行持續優化和完善，詳情可自行去github廣場查看最新版本發佈情況。
由於我是按照自己的實踐理解來默寫總結的，只能說是把重點部分做下總結，如果有疏漏和考慮不周的地方，github或者碼雲call我一下啦。大致說一下Eureka註冊中心搭建步驟：
首先，pon.xml新增基本依賴如下：
spring-boot-starter-parent 版本2.0
spring-boot-starter-logging
spring-boot-starter-web
spring-boot-starter-jdbc
spring-boot-starter-aop
spring-cloud-starter-parent Greenwich S3或者Finalize.REALASE，SpringBoot2.0.X則用前者
spring-cloud-starter-netflix-eureka-server
創建啓動類，這裏有三個要使用的註解做下簡單介紹
EnableEurekaServer 應用啓動立即加載Eureka註冊中心
EnableEurekaClient 應用啓動立即聯通Eureka註冊中心
EnableDiscoveryClient 暴露當前服務
底層實現實際是讀取application.yml配置文件並加載配置的註冊中心信息到META-INF/spring.factories文件中，應用啓動之後SpringApplication內部會基於EnableAutoConfigurationImportSelector掃描配置信息並加載到內存中，然後基於ApplicationRunListener監聽服務註冊，再通過SpringFactoriesLoader讀取生成的spring.factories文件中的EnableAutoConfiguration指向的EurekaServerAutoConfiguration註冊Eureka註冊中心。具體的可以去查看SpringBoot項目運行加載機制的相關源碼解析
創建application.yml配置文件，除SpringBoot應用基本配置項外，新增Eureka註冊中心相關配置，重點說下幾個重要的配置項：
spring.application.name指定serviceid，全局唯一（不唯一則當做集羣處理）
eureka.instance.hostname 註冊中心主機ip
eureka.service.uri.defaultZone 註冊中心url
eureka.service.register-with-eureka 是否需要把自身註冊到Eureka註冊中心
eureka.service.fetch-registry 是否需要在Eureka註冊中心中查找服務
啓動應用訪問，默認會直接打開Eureka註冊中心，在SpringCloud內置的Eureka註冊中心中默認提供了ui組件進行渲染，在頁面上可以實時看到服務的註冊和運行情況。
2 Eureka註冊中心集羣實現原理概述
前面我們說了，一般情況下所有微服務架構項目註冊中心都不會只有一個，默認都會搭建註冊中心集羣來容災。Eureka註冊中心集羣方式搭建比較簡單靈活，採用的實現機制是依賴傳遞。簡單的說，就是同一個集羣中的註冊中心相互註冊從而實現註冊中心中的服務在其它註冊中心中保持同步。在application.yml指定的註冊中心defaultZone中可以指定多個註冊中心的url（默認相同集羣環境中的所有註冊中心此處均保持相同配置從而實現傳遞註冊進而實現服務同步），每個註冊中心url之間使用逗號隔開。
同一個集羣環境下的所有註冊中心spring.application.name必須保持一致，否則將會單獨成爲註冊中心而不是註冊中心集羣。
註冊中心集羣環境下可能會後臺輸出一些無法訪問的異常，比如can not connect to serviceid或者can not found eureka instance serviceid等等，這是因爲在同一個集羣環境下每一個註冊中心之間都需要相互註冊，剛啓動的時候由於依賴的其他註冊中心還沒有啓動成功所以也就無法註冊當前註冊中心到其他的註冊中心。同一個集羣中的所有註冊中心全部啓動成功之後，這個異常就會消失。如果Eureka註冊中心集羣環境搭建並且啓動成功，訪問其中任意一個Eureka註冊中心都會發現，同一個serviceid對應多個註冊中心實例，這就表明我們的Eureka註冊中心集羣搭建成功。
3 Eureka註冊中心備註和補充
SpringCloud微服務框架提供了目前市面上使用頻率比較高的註冊中心支持，包括但不限於
zookeeper，eureka，consul，redis
注意：
Eureka在SpringCloud2.0中已經閉源，但是目前仍是官方建議推薦的主流注冊中心，如果對Eureka源碼感興趣可以參考SpringCloud1.0中的Eureka源碼或者參考netflix視頻網站中的Eureka源碼。
consul是Apache基金會全新發布的一款consul是Apache基金會全新發布的一款Go語言編寫的註冊中心，由於和由於和Java兼容性不好，所以目前所以目前SpringCloud2.0官方只是把0官方只是把consul當做備選方案，如果後期如果後期netflix和如果後期如果後期netflix和SpringCloud談不攏的話，SpringCloud官方推薦SpringCloud官方推薦consul也不是不無可能，說白了，其實consul目前只是備胎。
zookeeper是dubbo和dubbox官方推薦並使用的註冊中心，優點是跨平臺能力強，但是由於體型較大且安裝配置方式較爲複雜，被被SpringCloud2.0逐漸淡忘了。。。但是但是SpringCloud2.0還是保留了對zookeeper的部分支持，但是在微服務體系中實際並不常用。
redis新推出的註冊中心名氣較小並且不穩定，還在SNAPSHOT階段，目前SpringCloud2.0官方並不推薦使用。
補充說明：
基於dubbo/dubbox的SOA架構 PK 基於Eureka的SpringCloud微服務架構
傳統SOA架構雖然也是面向服務架構，雖然也可以對服務進行調度管理，但是對於日趨龐大的軟件系統而言，缺點也是逐漸顯現出來：
服務粒度過粗，大量服務的情況下服務治理出現混亂，服務調用機制缺乏靈活性，服務容災性差，配置和維護複雜性大，經常性出現牽一髮動全身問題，數據傳輸速率很慢，服務經常宕機。
基於基於SpringCloud2.0的微服務架構則提供了一整套微服務體系治理機制，服務粒度更加精細，專門提供了服務治理和監管機制，最大限度確保服務的彈性，伸縮性，進而提高整個應用系統的容災性和高可用性。擁有單獨的微服務分佈式配置中心統一管理所有服務配置信息，採用主流REST數據傳輸機制進行服務和註冊中心，服務和服務之間的高性能RPC遠程調用，極大提高了系統輕便和靈活性，進而提高開發的敏捷性。擁有單獨的熔斷和容災機制，最大限度減少服務雪崩所帶來的蝴蝶效應，對於服務器來說服務訪問線程分配更加均衡，也避免了線程阻塞導致項目崩潰問題出現的可能性。所以在面向服務設計的架構體系中，基於SpringCloud2.0的微服務架構得到了開源社區開發同行的廣泛認可，也正逐漸成爲越來越多大廠開發項目首選架構。