摘要:服務器用作服務注冊服務器。此時,這個節點對于新的服務還能提供注冊服務,對于死亡的仍然保留,以防還有客戶端向其發起請求。的構架保證了它能夠成為發現服務。
本帖最后由 yqw_gz_java 于 2019-8-15 14:26 編輯
與ZooKeeper 一樣eureka 都可以注冊服務發現服務
CAP定理
在分布式系統領域有個著名的CAP定理(C-數據一致性;A-服務可用性;P-服務對網絡分區故障的容錯性,這三個特性在任何分布式系統中不能同時滿足,最多同時滿足兩個);
Zookeeper 之CAP
ZooKeeper是個CP的,即任何時刻對ZooKeeper的訪問請求能得到一致的數據結果,同時系統對網絡分割具備容錯性;但是它不能保證每次服務請求的可用性(注:也就是在極端環境下,ZooKeeper可能會丟棄一些請求,消費者程序需要重新請求才能獲得結果)但是別忘了,ZooKeeper是分布式協調服務,它的職責是保證數據(注:配置數據,狀態數據)在其管轄下的所有服務之間保持同步、一致;所以就不難理解為什么ZooKeeper被設計成CP而不是AP特性的了,如果是AP的,那么將會帶來恐怖的后果(注:ZooKeeper就像交叉路口的信號燈一樣,你能想象在交通要道突然信號燈失靈的情況嗎?)。而且,作為ZooKeeper的核心實現算法Zab,就是解決了分布式系統下數據如何在多個服務之間保持同步問題的。作為一個分布式協同服務,ZooKeeper非常好,但是對于Service發現服務來說就不合適了;因為對于Service發現服務來說就算是返回了包含不實的信息的結果也比什么都不返回要好;再者,對于Service發現服務而言,寧可返回某服務5分鐘之前在哪幾個服務器上可用的信息,也不能因為暫時的網絡故障而找不到可用的服務器,而不返回任何結果。所以說,用ZooKeeper來做Service發現服務是肯定錯誤的,如果你這么用就慘了!
Eureka
Eureka由Netflix公司開發。(注:Eureka由兩個組件組成:Eureka服務器和Eureka客戶端。Eureka服務器用作服務注冊服務器。Eureka客戶端是一個java客戶端,用來簡化與服務器的交互、作為輪詢負載均衡器,并提供服務的故障切換支持。)Eureka一開始就被設計成高可用與可伸縮的Service發現服務,這兩個特點也是Netflix公司開發所有平臺的兩個特色。首先,在Eureka平臺中,如果某臺服務器宕機,Eureka不會有類似于ZooKeeper的選舉leader的過程;客戶端請求會自動切換到新的Eureka節點;當宕機的服務器重新恢復后,Eureka會再次將其納入到服務器集群管理之中;而對于它來說,所有要做的無非是同步一些新的服務注冊信息而已。所以,再也不用擔心有“掉隊”的服務器恢復以后,會從Eureka服務器集群中剔除出去的風險了。Eureka甚至被設計用來應付范圍更廣的網絡分割故障,并實現“0”宕機維護需求。當網絡分割故障發生時,每個Eureka節點,會持續的對外提供服務(注:ZooKeeper不會):接收新的服務注冊同時將它們提供給下游的服務發現請求。這樣一來,就可以實現在同一個子網中(same side of partition),新發布的服務仍然可以被發現與訪問。
但是,Eureka做到的不止這些。正常配置下,Eureka內置了心跳服務,用于淘汰一些“瀕死”的服務器;如果在Eureka中注冊的服務,它的“心跳”變得遲緩時,Eureka會將其整個剔除出管理范圍(這點有點像ZooKeeper的做法)。這是個很好的功能,但是當網絡分割故障發生時,這也是非常危險的;因為,那些因為網絡問題(注:心跳慢被剔除了)而被剔除出去的服務器本身是很”健康“的,只是因為網絡分割故障把Eureka集群分割成了獨立的子網而不能互訪而已。
幸運的是,Netflix考慮到了這個缺陷。如果Eureka服務節點在短時間里丟失了大量的心跳連接(注:可能發生了網絡故障),那么這個Eureka節點會進入”自我保護模式“,同時保留那些“心跳死亡“的服務注冊信息不過期。此時,這個Eureka節點對于新的服務還能提供注冊服務,對于”死亡“的仍然保留,以防還有客戶端向其發起請求。當網絡故障恢復后,這個Eureka節點會退出”自我保護模式“。所以Eureka的哲學是,同時保留”好數據“與”壞數據“總比丟掉任何”好數據“要更好,所以這種模式在實踐中非常有效。
最后,Eureka還有客戶端緩存功能(注:Eureka分為客戶端程序與服務器端程序兩個部分,客戶端程序負責向外提供注冊與發現服務接口)。所以即便Eureka集群中所有節點都失效,或者發生網絡分割故障導致客戶端不能訪問任何一臺Eureka服務器;Eureka服務的消費者仍然可以通過Eureka客戶端緩存來獲取現有的服務注冊信息。甚至最極端的環境下,所有正常的Eureka節點都不對請求產生相應,也沒有更好的服務器解決方案來解決這種問題時;得益于Eureka的客戶端緩存技術,消費者服務仍然可以通過Eureka客戶端查詢與獲取注冊服務信息,這點很重要。
Eureka的構架保證了它能夠成為Service發現服務。它相對與ZooKeeper來說剔除了Leader節點的選取或者事務日志機制,這樣做有利于減少使用者維護的難度也保證了Eureka的在運行時的健壯性。而且Eureka就是為發現服務所設計的,它有獨立的客戶端程序庫,同時提供心跳服務、服務健康監測、自動發布服務與自動刷新緩存的功能。但是,如果使用ZooKeeper你必須自己來實現這些功能。Eureka的所有庫都是開源的,所有人都能看到與使用這些源代碼,這比那些只有一兩個人能看或者維護的客戶端庫要好。
維護Eureka服務器也非常的簡單,比如,切換一個節點只需要在現有EIP下移除一個現有的節點然后添加一個新的就行。Eureka提供了一個web-based的圖形化的運維界面,在這個界面中可以查看Eureka所管理的注冊服務的運行狀態信息:是否健康,運行日志等。Eureka甚至提供了Restful-API接口,方便第三方程序集成Eureka的功能
[SQL] 純文本查看 復制代碼
?
1
2
3
4
5
6
7
8
9
eureka:
instance:
hostname: eureka7003.com #eureka服務端的實例名稱
client:
register-with-eureka: false #false表示不向注冊中心注冊自己。 fetch-registry: false #false表示自己端就是注冊中心,我的職責就是維護服務實例,并不需要去檢索服務 service-url: #defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ #設置與Eureka Server交互的地址查詢服務和注冊服務都需要依賴這個地址。 defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/
eureka的簡要配置
結論
我們來比較一下,在CAP理論中,zk更看重C和P,即一致性和分區容錯性。但Eureka更在意的是A和P,A為高可用。zk中有master和follower區別,當進入選舉模式時,就無法正常對外提供服務。但Eureka中,集群是對等的,地位是相同的,雖不能保證一致性,但至少可以提供注冊服務。 根據不同的業務場景,各有取舍吧。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/76204.html
摘要:注意注解能注冊到服務上,是因為該注解包含了客戶端的注解,該是一個復合注解。包含了客戶端注解,同時也包含了斷路器模塊注解,還包含了網關模塊。 SpringCloud(第 027 篇)集成異構微服務系統到 SpringCloud 生態圈中(比如集成 nodejs 微服務) - 一、大致介紹 1、在一些稍微復雜點系統中,往往都不是單一代碼寫的服務,而恰恰相反集成了各種語言寫的系統,并且我們還...
摘要:在微服務架構中,注冊中心是核心的基礎服務之一。在微服務架構流行之前,注冊中心就已經開始出現在分布式架構的系統中。服務提供者注冊到注冊中心,服務消費者到注冊中心訂閱,同時,注冊中心中的變更也會通知服務消費者。 在微服務架構中,注冊中心是核心的基礎服務之一。在微服務架構流行之前,注冊中心就已經開始出現在分布式架構的系統中。Dubbo是一個在國內比較流行的分布式框架,被大量的中小型互聯網公司...
摘要:注意注解能注冊到服務上,是因為該注解包含了客戶端的注解,該是一個復合注解。地址可以查看該微服務網關代理了多少微服務的。 SpringCloud(第 018 篇)Zuul 服務 API 網關微服務之代理與反向代理 - 一、大致介紹 1、API 服務網關顧名思義就是統一入口,類似 nginx、F5 等功能一樣,統一代理控制請求入口,弱化各個微服務被客戶端記憶功能; 2、本章節主要講解了使用...
摘要:筆者也是初學者,本文從創建項目工程開始,一步一步開始講解如何創建服務端和客戶端,一起學習,共同進步。下面我們使用工具創建相關項目。配置其中兩個屬性表明這個應用是端,而不是端。至此,端和端已經部署成功。 前言 spring cloud為互聯企業構建微服務提供了一整套的技術組件,其中Eureka是Spring Cloud體系中的核心。Netfix不是一個技術概念,它原本是國外一個視頻網站的...
摘要:系統中的各個微服務可被獨立部署,各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好地完成該任務。傳統架構升級困難。新的輕量級協議容器化的出現。熔斷處理在微服務出現問題時防止出現雪崩效應。 聊完Spring Boot,我們來看看Spring Boot最重要的一方面的應用——Spring Cloud。 Spring Cloud 再聊SpringCloud之前我們先聊聊微服務。 ...
閱讀 3537·2021-10-09 09:41
閱讀 2742·2021-10-08 10:18
閱讀 2178·2021-09-10 10:51
閱讀 2677·2021-09-10 10:50
閱讀 773·2021-09-09 09:33
閱讀 3380·2021-09-06 15:14
閱讀 3014·2019-08-30 11:06
閱讀 3244·2019-08-29 14:04