前言
服務註冊中心本質上是爲了解耦服務提供者和服務消費者。對於任何一個微服務,原則上都應存在或者支持多個提供者,這是由微服務的分佈式屬性決定的。
更進一步,爲了支持彈性擴縮容特性,一個微服務的提供者的數量和分佈往往是動態變化的,也是無法預先確定的。
因此,原本在單體應用階段常用的靜態LB機制就不再適用了,需要引入額外的組件來管理微服務提供者的註冊與發現,而這個組件就是服務註冊中心。
CAP理論
CAP理論是分佈式架構中重要理論
- 一致性(Consistency) (所有節點在同一時間具有相同的數據)
- 可用性(Availability) (保證每個請求不管成功或者失敗都有響應)
- 分隔容忍(Partition tolerance) (系統中任意信息的丟失或失敗不會影響系統的繼續運作)
關於P的理解,我覺得是在整個系統中某個部分,掛掉了,或者宕機了,並不影響整個系統的運作或者說使用,
而可用性是,某個系統的某個節點掛了,但是並不影響系統的接受或者發出請求,CAP 不可能都取,只能取其中2個
原因是如果C是第一需求的話,那麼會影響A的性能,因爲要數據同步,不然請求結果會有差異,但是數據同步會消耗時間,期間可用性就會降低。
如果A是第一需求,那麼只要有一個服務在,就能正常接受請求,但是對與返回結果變不能保證,原因是,在分佈式部署的時候,數據一致的過程不可能想切線路那麼快。
再如果,同事滿足一致性和可用性,那麼分區容錯就很難保證了,也就是單點,也是分佈式的基本核心,好了,明白這些理論,就可以在相應的場景選取服務註冊與發現了
服務註冊中心解決方案
設計或者選型一個服務註冊中心,首先要考慮的就是服務註冊與發現機制。縱觀當下各種主流的服務註冊中心解決方案,大致可歸爲三類:
- 應用內:直接集成到應用中,依賴於應用自身完成服務的註冊與發現,最典型的是Netflix提供的Eureka
- 應用外:把應用當成黑盒,通過應用外的某種機制將服務註冊到註冊中心,最小化對應用的侵入性,比如Airbnb的SmartStack,HashiCorp的Consul
- DNS:將服務註冊爲DNS的SRV記錄,嚴格來說,是一種特殊的應用外註冊方式,SkyDNS是其中的代表
注1:對於第一類註冊方式,除了Eureka這種一站式解決方案,還可以基於ZooKeeper或者Etcd自行實現一套服務註冊機制,這在大公司比較常見,但對於小公司而言顯然性價比太低。
注2:由於DNS固有的緩存缺陷,本文不對第三類註冊方式作深入探討。
除了基本的服務註冊與發現機制,從開發和運維角度,至少還要考慮如下五個方面:
- 測活:服務註冊之後,如何對服務進行測活以保證服務的可用性?
- 負載均衡:當存在多個服務提供者時,如何均衡各個提供者的負載?
- 集成:在服務提供端或者調用端,如何集成註冊中心?
- 運行時依賴:引入註冊中心之後,對應用的運行時環境有何影響?
- 可用性:如何保證註冊中心本身的可用性,特別是消除單點故障?
主流注冊中心產品
軟件產品特性並非一成不變,如果發現功能特性有變更,歡迎評論指正
Nacos | Eureka | Consul | CoreDNS | Zookeeper | |
---|---|---|---|---|---|
一致性協議 | CP+AP | AP | CP | — | CP |
健康檢查 | TCP/HTTP/MYSQL/Client Beat | Client Beat | TCP/HTTP/gRPC/Cmd | — | Keep Alive |
負載均衡策略 | 權重/ metadata/Selector | Ribbon | Fabio | RoundRobin | — |
雪崩保護 | 有 | 有 | 無 | 無 | 無 |
自動註銷實例 | 支持 | 支持 | 支持 | 不支持 | 支持 |
訪問協議 | HTTP/DNS | HTTP | HTTP/DNS | DNS | TCP |
監聽支持 | 支持 | 支持 | 支持 | 不支持 | 支持 |
多數據中心 | 支持 | 支持 | 支持 | 不支持 | 不支持 |
跨註冊中心同步 | 支持 | 不支持 | 支持 | 不支持 | 不支持 |
SpringCloud集成 | 支持 | 支持 | 支持 | 不支持 | 支持 |
Dubbo集成 | 支持 | 不支持 | 支持 | 不支持 | 支持 |
K8S集成 | 支持 | 不支持 | 支持 | 支持 | 不支持 |
- Consul是支持自動註銷服務實例, 請見文檔: https://www.consul.io/api-docs/agent/service,在check的 DeregisterCriticalServiceAfter 這個參數。
- 新版本的Dubbo也擴展了對 Consul 的支持。 參考: https://github.com/apache/dubbo/tree/master/dubbo-registry
Apache Zookeeper -> CP
與 Eureka 有所不同,Apache Zookeeper 在設計時就緊遵CP原則,即任何時候對 Zookeeper 的訪問請求能得到一致的數據結果,同時系統對網絡分割具備容錯性,但是 Zookeeper 不能保證每次服務請求都是可達的。
從 Zookeeper 的實際應用情況來看,在使用 Zookeeper 獲取服務列表時,如果此時的 Zookeeper 集羣中的 Leader 宕機了,該集羣就要進行 Leader 的選舉,又或者 Zookeeper 集羣中半數以上服務器節點不可用(例如有三個節點,如果節點一檢測到節點三掛了 ,節點二也檢測到節點三掛了,那這個節點纔算是真的掛了),那麼將無法處理該請求。所以說,Zookeeper 不能保證服務可用性。
當然,在大多數分佈式環境中,尤其是涉及到數據存儲的場景,數據一致性應該是首先被保證的,這也是 Zookeeper 設計緊遵CP原則的另一個原因。
但是對於服務發現來說,情況就不太一樣了,針對同一個服務,即使註冊中心的不同節點保存的服務提供者信息不盡相同,也並不會造成災難性的後果。
因爲對於服務消費者來說,能消費纔是最重要的,消費者雖然拿到可能不正確的服務實例信息後嘗試消費一下,也要勝過因爲無法獲取實例信息而不去消費,導致系統異常要好(淘寶的雙十一,京東的618就是緊遵AP的最好參照)。
當master節點因爲網絡故障與其他節點失去聯繫時,剩餘節點會重新進行leader選舉。問題在於,選舉leader的時間太長,30~120s,而且選舉期間整個zk集羣都是不可用的,這就導致在選舉期間註冊服務癱瘓。
在雲部署環境下, 因爲網絡問題使得zk集羣失去master節點是大概率事件,雖然服務能最終恢復,但是漫長的選舉事件導致註冊長期不可用是不能容忍的。
Spring Cloud Eureka -> AP
Spring Cloud Netflix 在設計 Eureka 時就緊遵AP原則(儘管現在2.0發佈了,但是由於其閉源的原因 ,但是目前 Ereka 1.x 任然是比較活躍的)。
Eureka Server 也可以運行多個實例來構建集羣,解決單點問題,但不同於 ZooKeeper 的選舉 leader 的過程,Eureka Server 採用的是Peer to Peer 對等通信。這是一種去中心化的架構,無 master/slave 之分,每一個 Peer 都是對等的。在這種架構風格中,節點通過彼此互相註冊來提高可用性,每個節點需要添加一個或多個有效的 serviceUrl 指向其他節點。每個節點都可被視爲其他節點的副本。
在集羣環境中如果某臺 Eureka Server 宕機,Eureka Client 的請求會自動切換到新的 Eureka Server 節點上,當宕機的服務器重新恢復後,Eureka 會再次將其納入到服務器集羣管理之中。當節點開始接受客戶端請求時,所有的操作都會在節點間進行復制(replicate To Peer)操作,將請求複製到該 Eureka Server 當前所知的其它所有節點中。
當一個新的 Eureka Server 節點啓動後,會首先嚐試從鄰近節點獲取所有註冊列表信息,並完成初始化。Eureka Server 通過 getEurekaServiceUrls() 方法獲取所有的節點,並且會通過心跳契約的方式定期更新。
默認情況下,如果 Eureka Server 在一定時間內沒有接收到某個服務實例的心跳(默認週期爲30秒),Eureka Server 將會註銷該實例(默認爲90秒, eureka.instance.lease-expiration-duration-in-seconds 進行自定義配置)。
當 Eureka Server 節點在短時間內丟失過多的心跳時,那麼這個節點就會進入自我保護模式。
Eureka的集羣中,只要有一臺Eureka還在,就能保證註冊服務可用(保證可用性),只不過查到的信息可能不是最新的(不保證強一致性)。除此之外,Eureka還有一種自我保護機制,如果在15分鐘內超過85%的節點都沒有正常的心跳,那麼Eureka就認爲客戶端與註冊中心出現了網絡故障,此時會出現以下幾種情況:
- Eureka不再從註冊表中移除因爲長時間沒有收到心跳而過期的服務;
- Eureka仍然能夠接受新服務註冊和查詢請求,但是不會被同步到其它節點上(即保證當前節點依然可用);
- 當網絡穩定時,當前實例新註冊的信息會被同步到其它節點中;
因此,Eureka可以很好的應對因網絡故障導致部分節點失去聯繫的情況,而不會像zookeeper那樣使得整個註冊服務癱瘓。
Consul:
Consul 是 HashiCorp 公司推出的開源工具,用於實現分佈式系統的服務發現與配置。Consul 使用 Go 語言編寫,因此具有天然可移植性(支持Linux、windows和Mac OS X)。
Consul 內置了服務註冊與發現框架、分佈一致性協議實現、健康檢查、Key/Value 存儲、多數據中心方案,不再需要依賴其他工具(比如 ZooKeeper 等),使用起來也較爲簡單。
Consul 遵循CAP原理中的CP原則,保證了強一致性和分區容錯性,且使用的是Raft算法,比zookeeper使用的Paxos算法更加簡單。雖然保證了強一致性,但是可用性就相應下降了,例如服務註冊的時間會稍長一些,因爲 Consul 的 raft 協議要求必須過半數的節點都寫入成功才認爲註冊成功 ;在leader掛掉了之後,重新選舉出leader之前會導致Consul 服務不可用。
Consul本質上屬於應用外的註冊方式,但可以通過SDK簡化註冊流程。而服務發現恰好相反,默認依賴於SDK,但可以通過Consul Template(下文會提到)去除SDK依賴。
Consul Template
Consul,默認服務調用者需要依賴Consul SDK來發現服務,這就無法保證對應用的零侵入性。
所幸通過Consul Template,可以定時從Consul集羣獲取最新的服務提供者列表並刷新LB配置(比如nginx的upstream),這樣對於服務調用者而言,只需要配置一個統一的服務調用地址即可。
Consul強一致性(C)帶來的是:
- 服務註冊相比Eureka會稍慢一些。因爲Consul的raft協議要求必須過半數的節點都寫入成功才認爲註冊成功
- Leader掛掉時,重新選舉期間整個consul不可用。保證了強一致性但犧牲了可用性。
Eureka保證高可用(A)和最終一致性:
- 服務註冊相對要快,因爲不需要等註冊信息replicate到其他節點,也不保證註冊信息是否replicate成功
- 當數據出現不一致時,雖然A, B上的註冊信息不完全相同,但每個Eureka節點依然能夠正常對外提供服務,這會出現查詢服務信息時如果請求A查不到,但請求B就能查到。如此保證了可用性但犧牲了一致性。
其他方面,eureka就是個servlet程序,跑在servlet容器中; Consul則是go編寫而成。
Nacos:
Nacos是阿里開源的,Nacos 支持基於 DNS 和基於 RPC 的服務發現。在Spring Cloud中使用Nacos,只需要先下載 Nacos 並啓動 Nacos server,Nacos只需要簡單的配置就可以完成服務的註冊發現。
Nacos除了服務的註冊發現之外,還支持動態配置服務。動態配置服務可以讓您以中心化、外部化和動態化的方式管理所有環境的應用配置和服務配置。動態配置消除了配置變更時重新部署應用和服務的需要,讓配置管理變得更加高效和敏捷。配置中心化管理讓實現無狀態服務變得更簡單,讓服務按需彈性擴展變得更容易。
一句話概括就是Nacos = Spring Cloud註冊中心 + Spring Cloud配置中心。
參考鏈接:
https://yq.aliyun.com/articles/698930
作者:琦彥
鏈接:https://blog.csdn.net/fly910905/article/details/100023415
版權聲明:本文爲博主原創文章,遵循 CC 4.0 BY-SA 版權協議,轉載請附上原文出處鏈接和本聲明。 近期熱文推薦:
1.600+ 道 Java面試題及答案整理(2021最新版)
2.終於靠開源項目弄到 IntelliJ IDEA 激活碼了,真香!
3.阿里 Mock 工具正式開源,幹掉市面上所有 Mock 工具!
4.Spring Cloud 2020.0.0 正式發佈,全新顛覆性版本!
覺得不錯,別忘了隨手點贊+轉發哦!