【微服務(wù)】Nacos?致性協(xié)議-創(chuàng)新互聯(lián)

創(chuàng)新互聯(lián)從2013年創(chuàng)立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項目成都網(wǎng)站設(shè)計、做網(wǎng)站、成都外貿(mào)網(wǎng)站建設(shè)公司網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元磴口做網(wǎng)站,已為上家服務(wù),為磴口各地企業(yè)和個人服務(wù),聯(lián)系電話:18982081108

目錄

一、為什么 Nacos 需要?致性協(xié)議

二、為什么 Nacos 選擇了 Raft 以及 Distro

1、從服務(wù)注冊發(fā)現(xiàn)來看

2、從配置管理來看

3、為什么是 Raft 和 Distro 呢

三、早期的 Nacos ?致性協(xié)議

四、當前 Nacos 的?致性協(xié)議層

💖?Spring家族及微服務(wù)系列文章?

一、為什么 Nacos 需要?致性協(xié)議

? Nacos 在開源支持就定下了?個目標，盡可能的減少用戶部署以及運維成本，做到用戶只需要?個程序包，就可以快速以單機模式啟動 Nacos 或者以集群模式啟動 Nacos。而 Nacos 是?個需要存儲數(shù)據(jù)的?個組件，因此，為了實現(xiàn)這個目標，就需要在 Nacos 內(nèi)部實現(xiàn)數(shù)據(jù)存儲。單機下其實問題不大，簡單的內(nèi)嵌關(guān)系型數(shù)據(jù)庫即可；但是集群模式下，就需要考慮如何保障各個節(jié)點之間的數(shù)據(jù)?致性以及數(shù)據(jù)同步，而要解決這個問題，就不得不引入共識算法，通過算法來保障各個節(jié)點之間的數(shù)據(jù)的?致性。

二、為什么 Nacos 選擇了 Raft 以及 Distro

為什么 Nacos 會在單個集群中同時運行 CP 協(xié)議以及 AP 協(xié)議呢？這其實要從 Nacos 的場景出發(fā)的：Nacos 是?個集服務(wù)注冊發(fā)現(xiàn)以及配置管理于?體的組件，因此對于集群下，各個節(jié)點之間的數(shù)據(jù)?致性保障問題，需要拆分成兩個方面

1、從服務(wù)注冊發(fā)現(xiàn)來看

? 服務(wù)發(fā)現(xiàn)注冊中心，在當前微服務(wù)體系下，是十分重要的組件，服務(wù)之間感知對方服務(wù)的當前可正常提供服務(wù)的實例信息，必須從服務(wù)發(fā)現(xiàn)注冊中心進行獲取，因此對于服務(wù)注冊發(fā)現(xiàn)中心組件的可用性，提出了很高的要求，需要在任何場景下，盡大可能保證服務(wù)注冊發(fā)現(xiàn)能力可以對外提供服務(wù)；同時 Nacos 的服務(wù)注冊發(fā)現(xiàn)設(shè)計，采取了心跳可自動完成服務(wù)數(shù)據(jù)補償?shù)臋C制。如果數(shù)據(jù)丟失的話，是可以通過該機制快速彌補數(shù)據(jù)丟失。

? 因此，為了滿足服務(wù)發(fā)現(xiàn)注冊中心的可用性，強?致性的共識算法這里就不太合適了，因為強?致性共識算法能否對外提供服務(wù)是有要求的，如果當前集群可用的節(jié)點數(shù)沒有過半的話，整個算法直接“罷工”，而最終?致共識算法的話，更多保障服務(wù)的可用性，并且能夠保證在?定的時間內(nèi)各個節(jié)點之間的數(shù)據(jù)能夠達成?致。

? 上述的都是針對于 Nacos 服務(wù)發(fā)現(xiàn)注冊中的非持久化服務(wù)而言（即需要客戶端上報心跳進行服務(wù)實例續(xù)約）。而對于 Nacos 服務(wù)發(fā)現(xiàn)注冊中的持久化服務(wù)，因為所有的數(shù)據(jù)都是直接使用調(diào)用 Nacos服務(wù)端直接創(chuàng)建，因此需要由 Nacos 保障數(shù)據(jù)在各個節(jié)點之間的強?致性，故而針對此類型的服務(wù)數(shù)據(jù)，選擇了強?致性共識算法來保障數(shù)據(jù)的?致性。

2、從配置管理來看

配置數(shù)據(jù)，是直接在 Nacos 服務(wù)端進行創(chuàng)建并進行管理的，必須保證大部分的節(jié)點都保存了此配置數(shù)據(jù)才能認為配置被成功保存了，否則就會丟失配置的變更，如果出現(xiàn)這種情況，問題是很嚴重的，如果是發(fā)布重要配置變更出現(xiàn)了丟失變更動作的情況，那多半就要引起嚴重的現(xiàn)網(wǎng)故障了，因此對于配置數(shù)據(jù)的管理，是必須要求集群中大部分的節(jié)點是強?致的，而這里的話只能使用強?致性共識算法。

3、為什么是 Raft 和 Distro 呢

? 對于強?致性共識算法，當前工業(yè)生產(chǎn)中，最多使用的就是 Raft 協(xié)議，Raft 協(xié)議更容易讓人理解，并且有很多成熟的工業(yè)算法實現(xiàn)，比如螞蟻金服的 JRaft、Zookeeper 的 ZAB、Consul 的 Raft、百度的 braft、Apache Ratis；因為 Nacos 是 Java 技術(shù)棧，因此只能在 JRaft、ZAB、ApacheRatis 中選擇，但是 ZAB 因為和 Zookeeper 強綁定，再加上希望可以和 Raft 算法庫的支持團隊隨時溝通交流，因此選擇了 JRaft，選擇 JRaft 也是因為 JRaft 支持多 RaftGroup，為 Nacos 后面的多數(shù)據(jù)分片帶來了可能。

? 而 Distro 協(xié)議是阿里巴巴自研的?個最終?致性協(xié)議，而最終?致性協(xié)議有很多，比如 Gossip、Eureka 內(nèi)的數(shù)據(jù)同步算法。而 Distro 算法是集 Gossip 以及 Eureka 協(xié)議的優(yōu)點并加以優(yōu)化而出來的，對于原生的 Gossip，由于隨機選取發(fā)送消息的節(jié)點，也就不可避免的存在消息重復(fù)發(fā)送給同?節(jié)點的情況，增加了網(wǎng)絡(luò)的傳輸?shù)膲毫?，也給消息節(jié)點帶來額外的處理負載，而 Distro 算法引入了權(quán)威 Server 的概念，每個節(jié)點負責?部分數(shù)據(jù)以及將自己的數(shù)據(jù)同步給其他節(jié)點，有效的降低了消息冗余的問題。

三、早期的 Nacos ?致性協(xié)議

我們先來看看早起的 Naocs 版本的架構(gòu)

? 在早期的 Nacos 架構(gòu)中，服務(wù)注冊和配置管理?致性協(xié)議是分開的，沒有下沉到 Nacos 的內(nèi)核模塊作為通用能力演進，服務(wù)發(fā)現(xiàn)模塊?致性協(xié)議的實現(xiàn)和服務(wù)注冊發(fā)現(xiàn)模塊的邏輯強耦合在?起，并且充斥著服務(wù)注冊發(fā)現(xiàn)的?些概念。這使得 Nacos 的服務(wù)注冊發(fā)現(xiàn)模塊的邏輯變得復(fù)雜且難以維護，耦合了?致性協(xié)議層的數(shù)據(jù)狀態(tài)，難以做到計算存儲徹底分離，以及對計算層的無限水平擴容能力也有?定的影響。因此為了解決這個問題，必然需要對 Nacos 的?致性協(xié)議做抽象以及下沉，使其成為 Core 模塊的能力，徹底讓服務(wù)注冊發(fā)現(xiàn)模塊只充當計算能力，同時為配置模塊去外部數(shù)據(jù)庫存儲打下了架構(gòu)基礎(chǔ)。

四、當前 Nacos 的?致性協(xié)議層

? 正如前面所說，在當前的 Nacos 內(nèi)核中，我們已經(jīng)做到了將?致性協(xié)議的能力，完全下沉到了內(nèi)核模塊作為 Nacos 的核心能力，很好的服務(wù)于服務(wù)注冊發(fā)現(xiàn)模塊以及配置管理模塊，我們來看看當前 Nacos 的架構(gòu)。

? 可以發(fā)現(xiàn)，在新的 Nacos 架構(gòu)中，已經(jīng)完成了將?致性協(xié)議從原先的服務(wù)注冊發(fā)現(xiàn)模塊下沉到了內(nèi)核模塊當中，并且盡可能的提供了統(tǒng)?的抽象接口，使得上層的服務(wù)注冊發(fā)現(xiàn)模塊以及配置管理模塊，不再需要耦合任何?致性語義，解耦抽象分層后，每個模塊能快速演進，并且性能和可用性都大幅提升。

💖?Spring家族及微服務(wù)系列文章?

?【Spring】一文帶你吃透IOC容器技術(shù)

?【微服務(wù)】SpringCloud中OpenFeign請求處理及負載均衡流程

?【微服務(wù)】SpringCloud中Ribbon的WeightedResponseTimeRule策略

?【微服務(wù)】SpringCloud中Ribbon的輪詢(RoundRobinRule)與重試(RetryRule)策略

?【微服務(wù)】SpringCloud中Ribbon集成Eureka實現(xiàn)負載均衡

?【微服務(wù)】SpringCloud輪詢拉取注冊表及服務(wù)發(fā)現(xiàn)源碼解析

?【微服務(wù)】SpringCloud微服務(wù)續(xù)約源碼解析

?【微服務(wù)】SpringCloud微服務(wù)注冊源碼解析

?【微服務(wù)】Nacos2.x服務(wù)發(fā)現(xiàn)？RPC調(diào)用？重試機制？

?【微服務(wù)】Nacos通知客戶端服務(wù)變更以及重試機制

?【微服務(wù)】Nacos服務(wù)發(fā)現(xiàn)源碼分析

?【微服務(wù)】SpringBoot監(jiān)聽器機制以及在Nacos中的應(yīng)用

?【微服務(wù)】Nacos服務(wù)端完成微服務(wù)注冊以及健康檢查流程

?【微服務(wù)】Nacos客戶端微服務(wù)注冊原理流程

?【微服務(wù)】SpringCloud中使用Ribbon實現(xiàn)負載均衡的原理

?【微服務(wù)】SpringBoot啟動流程注冊FeignClient

?【微服務(wù)】SpringBoot啟動流程初始化OpenFeign的入口

?Spring Bean的生命周期

?Spring事務(wù)原理

?SpringBoot自動裝配原理機制及過程

?SpringBoot獲取處理器流程

?SpringBoot中處理器映射關(guān)系注冊流程

?Spring5.x中Bean初始化流程

?Spring中Bean定義的注冊流程

?Spring的處理器映射器與適配器的架構(gòu)設(shè)計

?SpringMVC執(zhí)行流程圖解及源碼

你是否還在尋找穩(wěn)定的海外服務(wù)器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機房具備T級流量清洗系統(tǒng)配攻擊溯源，準確流量調(diào)度確保服務(wù)器高可用性，企業(yè)級服務(wù)器適合批量采購，新人活動首月15元起，快前往官網(wǎng)查看詳情吧

當前題目：【微服務(wù)】Nacos?致性協(xié)議-創(chuàng)新互聯(lián)
文章出自：http://bm7419.com/article18/heodp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、虛擬主機、營銷型網(wǎng)站建設(shè)、App開發(fā)、ChatGPT、微信小程序

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)

成都網(wǎng)站建設(shè)公司