微服務(wù)之eureka

Dean 發(fā)布于2019-08-19 10:32 / 2644人閱讀

摘要：服務(wù)器用作服務(wù)注冊服務(wù)器。此時(shí)，這個(gè)節(jié)點(diǎn)對于新的服務(wù)還能提供注冊服務(wù)，對于死亡的仍然保留，以防還有客戶端向其發(fā)起請求。的構(gòu)架保證了它能夠成為發(fā)現(xiàn)服務(wù)。

本帖最后由 yqw_gz_java 于 2019-8-15 14:26 編輯

與ZooKeeper 一樣eureka 都可以注冊服務(wù)發(fā)現(xiàn)服務(wù)
CAP定理
在分布式系統(tǒng)領(lǐng)域有個(gè)著名的CAP定理（C-數(shù)據(jù)一致性；A-服務(wù)可用性；P-服務(wù)對網(wǎng)絡(luò)分區(qū)故障的容錯(cuò)性，這三個(gè)特性在任何分布式系統(tǒng)中不能同時(shí)滿足，最多同時(shí)滿足兩個(gè)）；
Zookeeper 之CAP

ZooKeeper是個(gè)CP的，即任何時(shí)刻對ZooKeeper的訪問請求能得到一致的數(shù)據(jù)結(jié)果，同時(shí)系統(tǒng)對網(wǎng)絡(luò)分割具備容錯(cuò)性；但是它不能保證每次服務(wù)請求的可用性（注：也就是在極端環(huán)境下，ZooKeeper可能會丟棄一些請求，消費(fèi)者程序需要重新請求才能獲得結(jié)果）但是別忘了，ZooKeeper是分布式協(xié)調(diào)服務(wù)，它的職責(zé)是保證數(shù)據(jù)（注：配置數(shù)據(jù)，狀態(tài)數(shù)據(jù)）在其管轄下的所有服務(wù)之間保持同步、一致；所以就不難理解為什么ZooKeeper被設(shè)計(jì)成CP而不是AP特性的了，如果是AP的，那么將會帶來恐怖的后果（注：ZooKeeper就像交叉路口的信號燈一樣，你能想象在交通要道突然信號燈失靈的情況嗎？）。而且，作為ZooKeeper的核心實(shí)現(xiàn)算法Zab，就是解決了分布式系統(tǒng)下數(shù)據(jù)如何在多個(gè)服務(wù)之間保持同步問題的。作為一個(gè)分布式協(xié)同服務(wù)，ZooKeeper非常好，但是對于Service發(fā)現(xiàn)服務(wù)來說就不合適了；因?yàn)閷τ赟ervice發(fā)現(xiàn)服務(wù)來說就算是返回了包含不實(shí)的信息的結(jié)果也比什么都不返回要好；再者，對于Service發(fā)現(xiàn)服務(wù)而言，寧可返回某服務(wù)5分鐘之前在哪幾個(gè)服務(wù)器上可用的信息，也不能因?yàn)闀簳r(shí)的網(wǎng)絡(luò)故障而找不到可用的服務(wù)器，而不返回任何結(jié)果。所以說，用ZooKeeper來做Service發(fā)現(xiàn)服務(wù)是肯定錯(cuò)誤的，如果你這么用就慘了！
Eureka
Eureka由Netflix公司開發(fā)。（注：Eureka由兩個(gè)組件組成：Eureka服務(wù)器和Eureka客戶端。Eureka服務(wù)器用作服務(wù)注冊服務(wù)器。Eureka客戶端是一個(gè)java客戶端，用來簡化與服務(wù)器的交互、作為輪詢負(fù)載均衡器，并提供服務(wù)的故障切換支持。）Eureka一開始就被設(shè)計(jì)成高可用與可伸縮的Service發(fā)現(xiàn)服務(wù)，這兩個(gè)特點(diǎn)也是Netflix公司開發(fā)所有平臺的兩個(gè)特色。首先，在Eureka平臺中，如果某臺服務(wù)器宕機(jī)，Eureka不會有類似于ZooKeeper的選舉leader的過程；客戶端請求會自動切換到新的Eureka節(jié)點(diǎn)；當(dāng)宕機(jī)的服務(wù)器重新恢復(fù)后，Eureka會再次將其納入到服務(wù)器集群管理之中；而對于它來說，所有要做的無非是同步一些新的服務(wù)注冊信息而已。所以，再也不用擔(dān)心有“掉隊(duì)”的服務(wù)器恢復(fù)以后，會從Eureka服務(wù)器集群中剔除出去的風(fēng)險(xiǎn)了。Eureka甚至被設(shè)計(jì)用來應(yīng)付范圍更廣的網(wǎng)絡(luò)分割故障，并實(shí)現(xiàn)“0”宕機(jī)維護(hù)需求。當(dāng)網(wǎng)絡(luò)分割故障發(fā)生時(shí)，每個(gè)Eureka節(jié)點(diǎn)，會持續(xù)的對外提供服務(wù)（注：ZooKeeper不會）：接收新的服務(wù)注冊同時(shí)將它們提供給下游的服務(wù)發(fā)現(xiàn)請求。這樣一來，就可以實(shí)現(xiàn)在同一個(gè)子網(wǎng)中（same side of partition），新發(fā)布的服務(wù)仍然可以被發(fā)現(xiàn)與訪問。
但是，Eureka做到的不止這些。正常配置下，Eureka內(nèi)置了心跳服務(wù)，用于淘汰一些“瀕死”的服務(wù)器；如果在Eureka中注冊的服務(wù)，它的“心跳”變得遲緩時(shí)，Eureka會將其整個(gè)剔除出管理范圍（這點(diǎn)有點(diǎn)像ZooKeeper的做法）。這是個(gè)很好的功能，但是當(dāng)網(wǎng)絡(luò)分割故障發(fā)生時(shí)，這也是非常危險(xiǎn)的；因?yàn)椋切┮驗(yàn)榫W(wǎng)絡(luò)問題（注：心跳慢被剔除了）而被剔除出去的服務(wù)器本身是很”健康“的，只是因?yàn)榫W(wǎng)絡(luò)分割故障把Eureka集群分割成了獨(dú)立的子網(wǎng)而不能互訪而已。
幸運(yùn)的是，Netflix考慮到了這個(gè)缺陷。如果Eureka服務(wù)節(jié)點(diǎn)在短時(shí)間里丟失了大量的心跳連接（注：可能發(fā)生了網(wǎng)絡(luò)故障），那么這個(gè)Eureka節(jié)點(diǎn)會進(jìn)入”自我保護(hù)模式“，同時(shí)保留那些“心跳死亡“的服務(wù)注冊信息不過期。此時(shí)，這個(gè)Eureka節(jié)點(diǎn)對于新的服務(wù)還能提供注冊服務(wù)，對于”死亡“的仍然保留，以防還有客戶端向其發(fā)起請求。當(dāng)網(wǎng)絡(luò)故障恢復(fù)后，這個(gè)Eureka節(jié)點(diǎn)會退出”自我保護(hù)模式“。所以Eureka的哲學(xué)是，同時(shí)保留”好數(shù)據(jù)“與”壞數(shù)據(jù)“總比丟掉任何”好數(shù)據(jù)“要更好，所以這種模式在實(shí)踐中非常有效。
最后，Eureka還有客戶端緩存功能（注：Eureka分為客戶端程序與服務(wù)器端程序兩個(gè)部分，客戶端程序負(fù)責(zé)向外提供注冊與發(fā)現(xiàn)服務(wù)接口）。所以即便Eureka集群中所有節(jié)點(diǎn)都失效，或者發(fā)生網(wǎng)絡(luò)分割故障導(dǎo)致客戶端不能訪問任何一臺Eureka服務(wù)器；Eureka服務(wù)的消費(fèi)者仍然可以通過Eureka客戶端緩存來獲取現(xiàn)有的服務(wù)注冊信息。甚至最極端的環(huán)境下，所有正常的Eureka節(jié)點(diǎn)都不對請求產(chǎn)生相應(yīng)，也沒有更好的服務(wù)器解決方案來解決這種問題時(shí)；得益于Eureka的客戶端緩存技術(shù)，消費(fèi)者服務(wù)仍然可以通過Eureka客戶端查詢與獲取注冊服務(wù)信息，這點(diǎn)很重要。
Eureka的構(gòu)架保證了它能夠成為Service發(fā)現(xiàn)服務(wù)。它相對與ZooKeeper來說剔除了Leader節(jié)點(diǎn)的選取或者事務(wù)日志機(jī)制，這樣做有利于減少使用者維護(hù)的難度也保證了Eureka的在運(yùn)行時(shí)的健壯性。而且Eureka就是為發(fā)現(xiàn)服務(wù)所設(shè)計(jì)的，它有獨(dú)立的客戶端程序庫，同時(shí)提供心跳服務(wù)、服務(wù)健康監(jiān)測、自動發(fā)布服務(wù)與自動刷新緩存的功能。但是，如果使用ZooKeeper你必須自己來實(shí)現(xiàn)這些功能。Eureka的所有庫都是開源的，所有人都能看到與使用這些源代碼，這比那些只有一兩個(gè)人能看或者維護(hù)的客戶端庫要好。
維護(hù)Eureka服務(wù)器也非常的簡單，比如，切換一個(gè)節(jié)點(diǎn)只需要在現(xiàn)有EIP下移除一個(gè)現(xiàn)有的節(jié)點(diǎn)然后添加一個(gè)新的就行。Eureka提供了一個(gè)web-based的圖形化的運(yùn)維界面，在這個(gè)界面中可以查看Eureka所管理的注冊服務(wù)的運(yùn)行狀態(tài)信息：是否健康，運(yùn)行日志等。Eureka甚至提供了Restful-API接口，方便第三方程序集成Eureka的功能
[SQL] 純文本查看復(fù)制代碼
?
1
2
3
4
5
6
7
8
9
eureka:
instance:

hostname: eureka7003.com #eureka服務(wù)端的實(shí)例名稱

client:

register-with-eureka: false     #false表示不向注冊中心注冊自己。
fetch-registry: false     #false表示自己端就是注冊中心，我的職責(zé)就是維護(hù)服務(wù)實(shí)例，并不需要去檢索服務(wù)
service-url: 
  #defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/       #設(shè)置與Eureka Server交互的地址查詢服務(wù)和注冊服務(wù)都需要依賴這個(gè)地址。
  defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/

eureka的簡要配置
結(jié)論
我們來比較一下，在CAP理論中，zk更看重C和P，即一致性和分區(qū)容錯(cuò)性。但Eureka更在意的是A和P，A為高可用。zk中有master和follower區(qū)別，當(dāng)進(jìn)入選舉模式時(shí)，就無法正常對外提供服務(wù)。但Eureka中，集群是對等的，地位是相同的，雖不能保證一致性，但至少可以提供注冊服務(wù)。根據(jù)不同的業(yè)務(wù)場景，各有取舍吧。