Spring-cloud微服務實戰【三】：eureka註冊中心（中）

  回憶一下,在上一篇文章中,咱們建立了兩個springboot項目,而且在consumer項目中經過restTemplate進行HTTP通訊,成功訪問到了producer提供的接口,思考一下這樣的實現方式有什麼問題?
  1.consumer必須知道producer的IP,才能調用對方的HTTP接口,而且在consumer代碼中使用硬編碼的方式來訪問producer的HTTP接口,代碼耦合度高,實現方式不優雅.也許有童鞋會說,咱們能夠在application.properties配置文件進行配置,那麼請看第二個問題.
  2.通常來講,生產環境的producer是一個集羣,有多個IP,那我consumer該怎麼寫請求地址?而且假如producer集羣的IP變了,consumer應用須要修改配置,從新打包上線.這對於一個高併發訪問的生產項目來講是不可接受的.所以,consumer應用須要一種機制,能夠在訪問producer的時候不須要關心producer的IP,而且該機制還應該提供相似於觀察者模式的通知機制,在producer的IP進行變動的時候,及時通consumer,而且還能提供相似Nginx的負載均衡的功能,這就是eureka註冊中心的做用.

什麼是eureka註冊中心?

  eureka是netflix公司開發的一款用於服務發現的框架,spring-cloud將其集成到spring-cloud-netflix子項目中,包括咱們後續會使用的負載均衡ribbon,服務熔斷與降級Hystrix等等都是netflix公司開發的.能夠看出,springcloud其實整合了許多優秀公司的框架.
  咱們經過一張圖來講明一下eureka工做機制:

  假如咱們如今有許多的微服務做爲服務提供方,每一個微服務是一個集羣,他們將本身的集羣節點的IP與端口號註冊到eureka中心,當有消費者須要消費服務的時候,便可從註冊中心拉取全部的服務提供方列表,選擇須要消費的服務,此時,eureka會根據負載算法將消費者須要的服務的IP與端口號返回給消費者,此時,消費者就能夠根據IP和端口號去消費對應的服務了.此外,eureka還必須接收註冊服務的心跳,確保註冊的服務可用.而且從圖中咱們能夠得知:

代碼實戰

  接下來,咱們改造上一篇文章中已有的代碼,使用eureka進行服務治理,producer註冊自身到eureka,consumer從eureka獲取producer的信息並調用.
  首先,咱們要新建一個子模塊,用於充當eureka-server的角色:

  將本模塊加入父項目中:

  而後新增pom.xml中的配置:

  修改配置文件:

  而後在啓動類加上@EnableEurekaServer:

  而後啓動試一試,此時控制檯會有錯誤信息:

  咱們暫時先無論這些錯誤信息,先訪問一下,看看是否能訪問:

  能夠看到,eureka是能正常訪問的,接下來,咱們修改producer的代碼,將producer註冊到eureka-server中.
首先修改pom.xml:

  而後修改配置文件:

  最後在啓動類加上@EnableEurekaClient:

  此時,咱們再啓動producer項目,而後訪問eureka-server,看看是否producer已經註冊成功:

  此時咱們再訪問該頁面,咱們須要關注的主要是筆者使用紅框標識的3條信息,其中第一條咱們暫時先無論(第一次訪問頁面不會出現,但過一下子刷新就能夠看到),待會兒咱們再倒回來講,第二條,表示咱們的producer應用已經註冊到eureka-server,但應用名未設置,因此目 前顯示的是UNKNOWN,所以須要咱們設置應用名.第三條狀態爲UP(1),表示該服務正常啓動,且地址是: DongHP:7001,點擊訪問試一試:

  能夠看到,訪問的域名是donghp(個人電腦名是DongHP):7001,後面跟的是actuator/info,而且頁面報錯,報錯信息提示咱們沒有該頁面(404),所以咱們須要添加spring-actuator,該模塊是spring進行健康檢查的模塊,咱們先分別解決第二和第三個問題:先修改配置文件,新增應用名:dhp-micro-service-producer

  接下來爲了讓咱們看到真實的IP地址,而不是 donghp:7001 ,咱們再加上顯示真實IP的配置:

  最後,再添加spring-actuator健康檢查的依賴:

  再重啓producer,並刷新eureka-server頁面:

  能夠看到,修改後的producer已經成功註冊到eureka-server中了,可是咱們會發現,以前註冊的服務還在,並無消失,這是什麼緣由呢?是緩存嗎?並非,咱們能夠試一試,過一下子再刷新,仍然仍是有,這並非緩存,還記得咱們以前所說的第一條:

提示信息嗎?這是eureka提示咱們觸發了eureka的自我保護機制.

  所謂eureka自我保護機制,就是當服務未按時進行心跳續約時(以前咱們在介紹eureka的時候說了,服務若是註冊到eureka後,會定時向eureka發送心跳)，Eureka會統計服務實例最近15分鐘心跳續約的比例是否低於了85%(eureka.server.renewal-percent-threshold默認狀況下=0.85)。當server在15分鐘內，比值低於percent，即少了15%的微服務心跳，server會進入自我保護狀態，Self-Preservation。在此狀態下，server不會刪除任何註冊信息，這就有可能致使在調用微服務時，實際上服務並不存在。由此咱們能夠分析出eureka自我保護機制的缺點:有可能保留確實已經不可用的微服務,可是相比之下,它的優勢是能最大化保存全部的微服務,由於在生產環境下,網絡問題致使的心跳丟失太常見了,咱們不能簡單以是否收到心跳來判斷一個微服務是否不可用,所以建議生產環境開啓自我保護機制,開發時的測試環境能夠關閉.

  所以上圖中出現的問題就可以解釋了,首先咱們已經關閉了以前的UNKNOWN的微服務,從新修改配置啓動了新的DHP-MICRO-SERVICE-PRODUCER,此時eureka服務器並無重啓,UNKNOWN的微服務再也不向eureka發送心跳(默認30秒發送一次心跳),所以eureka的心跳比例只有50%,低於85%,頁面彈出eureka觸發自我保護機制的提示,而且eureka進入自我保護狀態,不會刪除任何微服務.所以無論咱們如何刷新頁面,UNKNOWN的微服務始終都在,若是須要禁用eureka的自我保護狀態,可使用配置:eureka.server.enable-self-preservation=false(默認是開啓的).

  此時先啓動eureka-server,再還原producer的配置啓動,再修改producer的配置啓動:

  上圖中①提示咱們目前關閉了自我保護模式,②說明目前有兩個已註冊的微服務,可是UNKNOWN已經下線了,所以咱們過一分鐘刷新:

  此時就只有一個了,咱們再訪問一下:

  得出兩個信息: 1.咱們的ip是192.168.1.105,去驗證一下:

2.咱們沒有配置健康檢查的信息,所以咱們在producer中配置相關信息:

  到此,咱們的eureka-server已經成功啓動,而且producer也註冊到eureka了,一切看似很完美了,但你們是否記得以前咱們說eureka-server啓動的時候會報錯的問題呢?

  這是由於eureka-server配置還不完整,咱們還須要添加配置:

  而後再啓動eureka-server和producer:

  能夠看到,producer服務已經成功註冊到eureka中了,而且eureka-server也沒有報錯信息了.

  此時咱們再經過consumer項目驗證一下.修改consumer項目代碼:
  首先consumer也須要添加eureka-client的依賴:

  其次配置eureka相關信息:

  而後在啓動類加上註解:

  最後修改代碼:

  能夠發現,這裏之前是直接使用ip:port,如今經過eureka發現服務,就對應於咱們以前所說的再也不關心對方服務的ip和端口,而且對方服務地址變化也不會再對咱們的代碼形成任何影響了,代碼的優雅性和可維護性大大提高!

  因爲這種方式走eureka服務發現,所以還須要加上@LoadBalanced註解:

  最後測試一下:

  訪問成功!自此,咱們成功使用了eureka註冊中心來解決文章一開始拋出的兩個問題,那是否是這樣就完美了?是否還有值得繼續優化的地方?敬請期待下一篇文章.

  本文的github地址

本文由博客一文多發平臺 OpenWrite 發佈！