springcloud學習筆記2：eureka

在以前，沒有學習springcloud以前，學習了dubbo，dubbo是一個遠程調用(RPC)框架，當時使用的是zookeeper註冊中心，可是在springcloud2.x以前，springcloud是沒有zookeeper的，那麼是如何實現遠程調用的呢？

1.eureka（springcloud1.x版本的註冊中心）

　　springcloud在2019年也就是springcloud2以後才添加的zookeeper，在這以前，都是使用的springcloud自帶的eureka註冊中心實現的遠程調用。

　　eureka是springcloud的核心，許多的服務都須要依賴eureka實現。

　　eureka與zookeeper的比較：

　　在以前使用的是zookeeper，如今學習eureka瞭解到，eureka也是一個註冊中心，那麼兩個註冊中心有什麼區別呢？（若是都同樣的話，爲何要開發它）

　　首先回顧zookeeper：

　　zookeeper保證的是數據的一致性（CP特性），zookeeper是一主多從機制，也就是三臺zookeeper只有一臺是leader，其餘的兩臺是follower，消費者請求進來後，不管是進入leader仍是follower，都會被移交給leader進行處理。

　　zookeeper的缺陷：由於保證了數據的一致性，那麼若是leader宕機的話，就會讀取到髒數據，以前zookeeper中有詳細的介紹

　　Eureka：

　　eureka保證的是服務的可用性（AP特性），eureka集羣中每一個節點都是平等的，所以在服務註冊時，就須要在每一個節點都註冊一份，三臺節點中的數據都是同樣的。這樣就不會出現zookeeper中leader宕機讀取髒數據的狀況。解決了zookeeper的缺陷。

　　eureka的自我保護機制：

　　若是長時間不激活eureka的時候就會出現自我保護機制。

　　eureka在啓動後，生產者每隔一段時間就會向eureka中發送心跳，eureka接收生產者的心跳，當網絡延遲/服務器宕機等狀況發生後，生產者不在向eureka發送心跳，eureka從接收不到心跳開始，默認90後，就會踢出這個生產者（Provider），可是若是出現大面積的生產者宕機——生產者的機房停電了，全部的服務器都沒法發送心跳，這時eureka就不會踢出任何一個服務（會將全部的服務都保留下來，這就是AP性）

　　Eureka爲何不會踢出大量的服務？

　　若是把eureka中的全部服務都踢出，當consumer進來後，發現沒有可用的服務了，就會報錯500，整個項目於就癱瘓了。

　　當大面積服務沒有心跳，可是eureka不踢出的話，consumer進來後，仍然能夠獲取到服務，能夠獲取到數據，這個數據可能不是最新的數據（假如說由於網絡延遲，致使eureka沒有接收到心跳，這樣eureka不會講服務所有踢出，也就是說consumer仍然能夠找到provider，provider仍然能夠工做，只是由於網絡延遲的緣由，可能如今獲取的數據，其實已經被刪除了，只不過刪除的操做發生網絡擁堵尚未到生產者中，這就會形成數據的不一致）

　　AP性：保證服務的可用性，不保證數據的一致性

　　CP性：保證數據的一致性，不保證服務的可用性

如何關閉eureka的自我保護機制

　　能夠關，可是不能這麼作

　　若是如今有一個服務就是不須要eureka的自我保護機制，那麼能夠想辦法讓eureka的自我保護失效。

　　方法：provider告訴eureka我每隔5秒給你發送一次心跳，若是你八秒後仍沒有接受到個人心跳，那麼你就將我踢出。

# 規定本身向eureka發送心跳的時間
# 單位是秒
eureka.instance.lease-renewal-interval-in-seconds=5
# 當eureka最後一次檢測到心跳的時間間隔(單位是秒)
# eg:15:05:20是最後一次檢測到心跳-->檢測8秒以後仍是沒法檢測心跳的時候直接剔除
eureka.instance.lease-expiration-duration-in-seconds=8

　　　　　　eureka中設置，默認等待provider10秒，10秒後尚未接受到心跳，就將provider踢出

# eureka本身檢測服務的心跳時間(90秒)
# 單位是毫秒，先把eureka檢測心跳的時間縮短爲10秒
# 也就是說每一個10秒就會檢測一次服務的心跳
eureka.server.eviction-interval-timer-in-ms=10000

 具體使用：https://github.com/Zs-xiazhi/springcloud-parent