建站
咨詢
售后
建站咨詢
新聞中心
圖片來自 Pexels
我們提供的服務(wù)有：網(wǎng)站制作、做網(wǎng)站、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、神池ssl等。為上千企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的神池網(wǎng)站制作公司
更進一步，為了支持彈性擴縮容特性，一個微服務(wù)的提供者的數(shù)量和分布往往是動態(tài)變化的，也是無法預(yù)先確定的。
因此，原本在單體應(yīng)用階段常用的靜態(tài) LB 機制就不再適用了，需要引入額外的組件來管理微服務(wù)提供者的注冊與發(fā)現(xiàn)，而這個組件就是服務(wù)注冊中心。
CAP 理論
CAP 理論是分布式架構(gòu)中重要理論：
- 一致性(Consistency)，所有節(jié)點在同一時間具有相同的數(shù)據(jù)。
- 可用性(Availability)，保證每個請求不管成功或者失敗都有響應(yīng)。
- 分隔容忍(Partition tolerance)，系統(tǒng)中任意信息的丟失或失敗不會影響系統(tǒng)的繼續(xù)運作。
關(guān)于 P 的理解，我覺得是在整個系統(tǒng)中某個部分，掛掉了，或者宕機了，并不影響整個系統(tǒng)的運作或者說使用，而可用性是，某個系統(tǒng)的某個節(jié)點掛了，但是并不影響系統(tǒng)的接受或者發(fā)出請求，CAP 不可能都取，只能取其中 2 個。
原因是如果 C 是第一需求的話，那么會影響 A 的性能，因為要數(shù)據(jù)同步，不然請求結(jié)果會有差異，但是數(shù)據(jù)同步會消耗時間，期間可用性就會降低。
如果 A 是第一需求，那么只要有一個服務(wù)在，就能正常接受請求，但是對與返回結(jié)果變不能保證，原因是，在分布式部署的時候，數(shù)據(jù)一致的過程不可能想切線路那么快。
再如果，同時滿足一致性和可用性，那么分區(qū)容錯就很難保證了，也就是單點，也是分布式的基本核心，好了，明白這些理論，就可以在相應(yīng)的場景選取服務(wù)注冊與發(fā)現(xiàn)了。
服務(wù)注冊中心解決方案
設(shè)計或者選型一個服務(wù)注冊中心，首先要考慮的就是服務(wù)注冊與發(fā)現(xiàn)機制。
縱觀當(dāng)下各種主流的服務(wù)注冊中心解決方案，大致可歸為三類：
- 應(yīng)用內(nèi)：直接集成到應(yīng)用中，依賴于應(yīng)用自身完成服務(wù)的注冊與發(fā)現(xiàn)，最典型的是 Netflix 提供的 Eureka。
- 應(yīng)用外：把應(yīng)用當(dāng)成黑盒，通過應(yīng)用外的某種機制將服務(wù)注冊到注冊中心，最小化對應(yīng)用的侵入性，比如 Airbnb 的 SmartStack，HashiCorp 的 Consul。
- DNS：將服務(wù)注冊為 DNS 的 SRV 記錄，嚴(yán)格來說，是一種特殊的應(yīng)用外注冊方式，SkyDNS 是其中的代表。
注 1：對于第一類注冊方式，除了 Eureka 這種一站式解決方案，還可以基于 ZooKeeper 或者 etcd 自行實現(xiàn)一套服務(wù)注冊機制，這在大公司比較常見，但對于小公司而言顯然性價比太低。
注 2：由于 DNS 固有的緩存缺陷，本文不對第三類注冊方式作深入探討。
除了基本的服務(wù)注冊與發(fā)現(xiàn)機制，從開發(fā)和運維角度，至少還要考慮如下五個方面：
- 測活：服務(wù)注冊之后，如何對服務(wù)進行測活以保證服務(wù)的可用性?
- 負(fù)載均衡：當(dāng)存在多個服務(wù)提供者時，如何均衡各個提供者的負(fù)載?
- 集成：在服務(wù)提供端或者調(diào)用端，如何集成注冊中心?
- 運行時依賴：引入注冊中心之后，對應(yīng)用的運行時環(huán)境有何影響?
- 可用性：如何保證注冊中心本身的可用性，特別是消除單點故障?
主流注冊中心產(chǎn)品
軟件產(chǎn)品特性并非一成不變，如果發(fā)現(xiàn)功能特性有變更，歡迎評論指正：
- Consul 是支持自動注銷服務(wù)實例，在 check 的 DeregisterCriticalServiceAfter 這個參數(shù)。
- 新版本的 Dubbo 也擴展了對 Consul 的支持。
①Apache Zookeeper→CP
與 Eureka 有所不同，Apache ZooKeeper 在設(shè)計時就緊遵 CP 原則，即任何時候?qū)?ZooKeeper 的訪問請求能得到一致的數(shù)據(jù)結(jié)果，同時系統(tǒng)對網(wǎng)絡(luò)分割具備容錯性，但是 ZooKeeper 不能保證每次服務(wù)請求都是可達的。
從 ZooKeeper 的實際應(yīng)用情況來看，在使用 ZooKeeper 獲取服務(wù)列表時，如果此時的 ZooKeeper 集群中的 Leader 宕機了，該集群就要進行 Leader 的選舉。
又或者 ZooKeeper 集群中半數(shù)以上服務(wù)器節(jié)點不可用(例如有三個節(jié)點，如果節(jié)點一檢測到節(jié)點三掛了 ，節(jié)點二也檢測到節(jié)點三掛了，那這個節(jié)點才算是真的掛了)，那么將無法處理該請求。
所以說，ZooKeeper 不能保證服務(wù)可用性。當(dāng)然，在大多數(shù)分布式環(huán)境中，尤其是涉及到數(shù)據(jù)存儲的場景，數(shù)據(jù)一致性應(yīng)該是首先被保證的，這也是 ZooKeeper 設(shè)計緊遵 CP 原則的另一個原因。
但是對于服務(wù)發(fā)現(xiàn)來說，情況就不太一樣了，針對同一個服務(wù)，即使注冊中心的不同節(jié)點保存的服務(wù)提供者信息不盡相同，也并不會造成災(zāi)難性的后果。
因為對于服務(wù)消費者來說，能消費才是最重要的，消費者雖然拿到可能不正確的服務(wù)實例信息后嘗試消費一下，也要勝過因為無法獲取實例信息而不去消費，導(dǎo)致系統(tǒng)異常要好(淘寶的雙十一，京東的 618 就是緊遵 AP 的最好參照)。
當(dāng) Master 節(jié)點因為網(wǎng)絡(luò)故障與其他節(jié)點失去聯(lián)系時，剩余節(jié)點會重新進行 Leader 選舉。
問題在于，選舉 Leader 的時間太長，30~120s，而且選舉期間整個 ZooKeeper 集群都是不可用的，這就導(dǎo)致在選舉期間注冊服務(wù)癱瘓。
在云部署環(huán)境下， 因為網(wǎng)絡(luò)問題使得 ZooKeeper 集群失去 Master 節(jié)點是大概率事件，雖然服務(wù)能最終恢復(fù)，但是漫長的選舉事件導(dǎo)致注冊長期不可用是不能容忍的。
②Spring Cloud Eureka→AP
Spring Cloud Netflix 在設(shè)計 Eureka 時就緊遵 AP 原則(盡管現(xiàn)在 2.0 發(fā)布了，但是由于其閉源的原因 ，但是目前 Ereka 1.x 任然是比較活躍的)。
Eureka Server 也可以運行多個實例來構(gòu)建集群，解決單點問題，但不同于 ZooKeeper 的選舉 Leader 的過程，Eureka Server 采用的是 Peer to Peer 對等通信。
這是一種去中心化的架構(gòu)，無 Master/Slave 之分，每一個 Peer 都是對等的。
在這種架構(gòu)風(fēng)格中，節(jié)點通過彼此互相注冊來提高可用性，每個節(jié)點需要添加一個或多個有效的 serviceUrl 指向其他節(jié)點。每個節(jié)點都可被視為其他節(jié)點的副本。
在集群環(huán)境中如果某臺 Eureka Server 宕機，Eureka Client 的請求會自動切換到新的 Eureka Server 節(jié)點上，當(dāng)宕機的服務(wù)器重新恢復(fù)后，Eureka 會再次將其納入到服務(wù)器集群管理之中。
當(dāng)節(jié)點開始接受客戶端請求時，所有的操作都會在節(jié)點間進行復(fù)制(replicate To Peer)操作，將請求復(fù)制到該Eureka Server當(dāng)前所知的其它所有節(jié)點中。
當(dāng)一個新的 Eureka Server 節(jié)點啟動后，會首先嘗試從鄰近節(jié)點獲取所有注冊列表信息，并完成初始化。
Eureka Server 通過 getEurekaServiceUrls() 方法獲取所有的節(jié)點，并且會通過心跳契約的方式定期更新。
默認(rèn)情況下，如果 Eureka Server 在一定時間內(nèi)沒有接收到某個服務(wù)實例的心跳(默認(rèn)周期為 30 秒)。
Eureka Server 將會注銷該實例(默認(rèn)為 90 秒，eureka.instance.lease-expiration-duration-in-seconds 進行自定義配置)。
當(dāng) Eureka Server 節(jié)點在短時間內(nèi)丟失過多的心跳時，那么這個節(jié)點就會進入自我保護模式。
Eureka 的集群中，只要有一臺 Eureka 還在，就能保證注冊服務(wù)可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)。
除此之外，Eureka 還有一種自我保護機制，如果在 15 分鐘內(nèi)超過 85% 的節(jié)點都沒有正常的心跳，那么 Eureka 就認(rèn)為客戶端與注冊中心出現(xiàn)了網(wǎng)絡(luò)故障。
此時會出現(xiàn)以下幾種情況：
- Eureka 不再從注冊表中移除因為長時間沒有收到心跳而過期的服務(wù)。
- Eureka 仍然能夠接受新服務(wù)注冊和查詢請求，但是不會被同步到其它節(jié)點上(即保證當(dāng)前節(jié)點依然可用)。
- 當(dāng)網(wǎng)絡(luò)穩(wěn)定時，當(dāng)前實例新注冊的信息會被同步到其它節(jié)點中。
因此，Eureka 可以很好的應(yīng)對因網(wǎng)絡(luò)故障導(dǎo)致部分節(jié)點失去聯(lián)系的情況，而不會像 ZooKeeper 那樣使得整個注冊服務(wù)癱瘓。
③Consul
Consul 是 HashiCorp 公司推出的開源工具，用于實現(xiàn)分布式系統(tǒng)的服務(wù)發(fā)現(xiàn)與配置。
Consul 使用 Go 語言編寫，因此具有天然可移植性(支持 Linux、Windows 和 Mac OS X)。
Consul 內(nèi)置了服務(wù)注冊與發(fā)現(xiàn)框架、分布一致性協(xié)議實現(xiàn)、健康檢查、Key/Value 存儲、多數(shù)據(jù)中心方案，不再需要依賴其他工具(比如 ZooKeeper 等)，使用起來也較為簡單。
Consul 遵循 CAP 原理中的 CP 原則，保證了強一致性和分區(qū)容錯性，且使用的是 Raft 算法，比 ZooKeeper 使用的 Paxos 算法更加簡單。
雖然保證了強一致性，但是可用性就相應(yīng)下降了，例如服務(wù)注冊的時間會稍長一些，因為 Consul 的 Raft 協(xié)議要求必須過半數(shù)的節(jié)點都寫入成功才認(rèn)為注冊成功。
在 Leader 掛掉了之后，重新選舉出 Leader 之前會導(dǎo)致 Consul 服務(wù)不可用。
默認(rèn)依賴于 SDK
Consul 本質(zhì)上屬于應(yīng)用外的注冊方式，但可以通過 SDK 簡化注冊流程。而服務(wù)發(fā)現(xiàn)恰好相反，默認(rèn)依賴于 SDK，但可以通過 Consul Template(下文會提到)去除 SDK 依賴。
Consul Template
Consul 默認(rèn)服務(wù)調(diào)用者需要依賴 Consul SDK 來發(fā)現(xiàn)服務(wù)，這就無法保證對應(yīng)用的零侵入性。
所幸通過 Consul Template，可以定時從 Consul 集群獲取最新的服務(wù)提供者列表并刷新 LB 配置(比如 Nginx 的 Upstream)，這樣對于服務(wù)調(diào)用者而言，只需要配置一個統(tǒng)一的服務(wù)調(diào)用地址即可。
Consul 強一致性(C)帶來的是：
- 服務(wù)注冊相比 Eureka 會稍慢一些。因為 Consul 的 Raft 協(xié)議要求必須過半數(shù)的節(jié)點都寫入成功才認(rèn)為注冊成功
- Leader 掛掉時，重新選舉期間整個 Consul 不可用。保證了強一致性但犧牲了可用性。
Eureka 保證高可用(A)和最終一致性：
- 服務(wù)注冊相對要快，因為不需要等注冊信息 Replicate 到其他節(jié)點，也不保證注冊信息是否 Replicate 成功。
- 當(dāng)數(shù)據(jù)出現(xiàn)不一致時，雖然 A，B 上的注冊信息不完全相同，但每個 Eureka 節(jié)點依然能夠正常對外提供服務(wù)，這會出現(xiàn)查詢服務(wù)信息時如果請求 A 查不到，但請求 B 就能查到。如此保證了可用性但犧牲了一致性。
其他方面，Eureka 就是個 servlet 程序，跑在 servlet 容器中;Consul 則是 Go 編寫而成。
④Nacos
Nacos 是阿里開源的，Nacos 支持基于 DNS 和基于 RPC 的服務(wù)發(fā)現(xiàn)。在 Spring Cloud 中使用 Nacos，只需要先下載 Nacos 并啟動 Nacos server，Nacos 只需要簡單的配置就可以完成服務(wù)的注冊發(fā)現(xiàn)。
Nacos 除了服務(wù)的注冊發(fā)現(xiàn)之外，還支持動態(tài)配置服務(wù)。動態(tài)配置服務(wù)可以讓您以中心化、外部化和動態(tài)化的方式管理所有環(huán)境的應(yīng)用配置和服務(wù)配置。
動態(tài)配置消除了配置變更時重新部署應(yīng)用和服務(wù)的需要，讓配置管理變得更加高效和敏捷。
配置中心化管理讓實現(xiàn)無狀態(tài)服務(wù)變得更簡單，讓服務(wù)按需彈性擴展變得更容易。
一句話概括就是 Nacos=Spring Cloud 注冊中心+Spring Cloud 配置中心。
作者：琦彥
編輯：陶家龍
出處：http://45dwz.com/ax2HY
新聞名稱：ZooKeeper、Eureka、Consul、Nacos，怎么選？
當(dāng)前URL：http://www.5511xx.com/article/ccdogpp.html
