? ? ? ? ? ?上一篇文章《ONOS高可用性和可擴(kuò)展性實(shí)現(xiàn)初探》講到了ONOS系統(tǒng)架構(gòu)在高可用、可擴(kuò)展方面技術(shù)概況，提到了系統(tǒng)在分布式集群中怎樣保證數(shù)據(jù)的一致性。在數(shù)據(jù)終于一致性方面，ONOS採用了Gossip協(xié)議。這一部分的變化不大，而在強(qiáng)一致性方案的選擇方面則在不斷進(jìn)行調(diào)整，其主要原因是分布式系統(tǒng)中強(qiáng)一致性對系統(tǒng)性能影響較大，并且現(xiàn)有的支持Paxos算法的實(shí)現(xiàn)不多。

本文承接上一篇提出的一個問題：ONOS為什么從開始使用ZooKeeper轉(zhuǎn)到Hazelcast，而終于選擇了Raft？是不是之前的選擇導(dǎo)致系統(tǒng)缺陷？亦或是在某些條件下無法滿足性能需求？且看下文為你慢慢道來。

在開始之前，先簡單的介紹一下ZooKeeper、Hazelcast和Raft，提供一些資料方便大家閱讀。?

????ZooKeeper，Hadoop生態(tài)系統(tǒng)中知名的分布式協(xié)作系統(tǒng),?是Google的Chubby一個開源的實(shí)現(xiàn),以C/S方式提供服務(wù)。應(yīng)用場景包含配置維護(hù)、名字服務(wù)、分布式同步、組服務(wù)等?。client?與server(Follower/Leader)以Watch/Callback的方式進(jìn)行交互，如圖1所看到的流程，可參考相關(guān)實(shí)例代碼。

?

??Hazelcast是一種內(nèi)存數(shù)據(jù)網(wǎng)格(IMDG:?In-Memory?Data?Grid),網(wǎng)格中全部的節(jié)點(diǎn)是以Peer-to-Peer的方式組建集群,而且全部數(shù)據(jù)置于內(nèi)存中以提高訪問性能[?Hadelcast架構(gòu)介紹文檔]。Hazelcast提供了通用的數(shù)據(jù)結(jié)構(gòu)（如Map,?List,?Queue等）和簡單的API進(jìn)行數(shù)據(jù)操作，能夠直接引入jar包進(jìn)行實(shí)現(xiàn)。能夠參考下文提供的相關(guān)實(shí)例代碼。

????Raft是為了解決Paxos算法的可讀性以及實(shí)現(xiàn)中拋棄一些細(xì)節(jié)形成的等價(jià)于Multi-Paxos算法。

它依賴于復(fù)制狀態(tài)機(jī)（Replicated?State?Machine），通過Replicated?Log將操作指令拷貝到各個節(jié)點(diǎn)，然后各節(jié)點(diǎn)在本地按同樣的順序運(yùn)行同樣的命令，產(chǎn)生一致的狀態(tài),圖2展示的是Raft狀態(tài)機(jī)。

?

依據(jù)上面的介紹，我們對這些方案有了初步的了解。如今如果我們是該系統(tǒng)的設(shè)計(jì)者，面臨對這三個方案技術(shù)方案進(jìn)行選型。我們首先須要對這些方案進(jìn)行對照，詳細(xì)如表1所看到的：

? ??從解決這個問題的角度來說，這三個方案都能夠解決ONOS在分布式一致性協(xié)作方面的問題，由于算法證明了這些方案都是“正確”的，除非實(shí)現(xiàn)上有Bug。

就算法的性能來說，差異不是非常大。Paxos算法(一種基于消息傳遞模型的一致性算法)，它能保證在一個分布式數(shù)據(jù)庫系統(tǒng)中，假設(shè)各節(jié)點(diǎn)的初始狀態(tài)一致，每一個節(jié)點(diǎn)都運(yùn)行同樣的操作序列，那么他們最后能得到一個一致的狀態(tài)。而Raft算法是等價(jià)于Multi-Paxos的算法，它主要解決的是Paxos晦澀的描寫敘述。以及Paxos的實(shí)現(xiàn)不能真正意義上的全然正確（實(shí)現(xiàn)上無法用公式證明）。這兩個算法盡管在實(shí)現(xiàn)上區(qū)別非常大，比方一致性實(shí)現(xiàn)中角色的定義，比方ZooKeeper中定義了Leader/Follower，Raft定義了Candidate/Leader/Follower角色，但其最核心的兩個關(guān)鍵活動。一個是選舉，其目的就是從分布的節(jié)點(diǎn)中選出Leader節(jié)點(diǎn)作為一致性的參考標(biāo)桿，其他的Follower就成為“鏡像”。選舉僅僅有在初始化或有Leader退出/失效時(shí)才發(fā)生，在分布式系統(tǒng)中，節(jié)點(diǎn)失效出現(xiàn)的頻次非常低。并且選舉動作都是能夠在秒級別能完畢的。對系統(tǒng)的性能影響不大，不明顯，實(shí)際情況中與系統(tǒng)節(jié)點(diǎn)數(shù)的奇/偶性更相關(guān)。比方4個節(jié)點(diǎn)或6個節(jié)點(diǎn)選舉時(shí)間可能比13個節(jié)點(diǎn)選舉時(shí)間更長。另外一個是同步，其目的是通過復(fù)制數(shù)據(jù)/操作來達(dá)到全部的Follower都能產(chǎn)生一致的結(jié)果，僅僅要狀態(tài)有更新（比方寫操作）。那么就會觸發(fā)同步動作。同步意味著數(shù)據(jù)的復(fù)制以及消息的傳遞，從分布式架構(gòu)來說，在讀寫IO方面這三種實(shí)現(xiàn)方式都相差點(diǎn)兒相同。

從這個角度來說，算法不是決定因素。

????大家可能會問：既然算法都差點(diǎn)兒相同了，就沒有必要在ONOS實(shí)現(xiàn)上大動手腳了。事實(shí)上。從上表我們能夠知道，當(dāng)初選擇ZooKeeper作為Prototype?1的首選，主要是由于ZooKeeper成熟穩(wěn)定，它在Hadoop生態(tài)圈是鼎鼎有名的高性能、分布式的應(yīng)用協(xié)調(diào)服務(wù)的首選。

從ONOS的Prototype?1的實(shí)現(xiàn)來看，ZooKeeper確實(shí)滿足了分布式集中控制的需求，另外一方面，在事實(shí)上驗(yàn)過程中，驗(yàn)證系統(tǒng)的性能時(shí)，非常多數(shù)據(jù)是全局靜態(tài)的。比方Flow?Rule在實(shí)際的應(yīng)用中是通過控制器以Lazy的方式下發(fā)到交換設(shè)備中，那么這些數(shù)據(jù)能夠提前在ZooKeeper中準(zhǔn)備好，僅僅要實(shí)驗(yàn)中不進(jìn)行交換設(shè)備的動態(tài)添加或者移除，不會影響到總體性能。

也就是說，在Prototype?1中主要關(guān)注SDN的概念在ONOS上能發(fā)揮到何種程度。而不關(guān)心交換設(shè)備動態(tài)添加、刪除等場景。

????也就是說當(dāng)有數(shù)據(jù)大量更新時(shí)。ZooKeeper則會出現(xiàn)性能問題，這主要由于ZooKeeper是以服務(wù)的形式來保障數(shù)據(jù)的一致性的。相對于ONOS來說，ZooKeeper是它的一個依賴子系統(tǒng)，因此在部署ONOS之外還要單獨(dú)部署ZooKeeper服務(wù)，如圖3所看到的的Client與Server之間的讀寫模型。

由于ZooKeeper中全部的數(shù)據(jù)都以ZNode表示，這些ZNode存儲在ZooKeeper的Server上，Client要讀的數(shù)據(jù)須要跨JVM訪問Server。

這樣ONOS?Instance就變成了zClient，那么當(dāng)ONOS不同實(shí)例間須要同步數(shù)據(jù)時(shí)，須要通過TCP的方式從zServer上請求數(shù)據(jù)，這就導(dǎo)致了ONOS的性能會急劇下降，另外，ZooKeeper的zNode對數(shù)據(jù)大小有限制(zNode數(shù)據(jù)大小不能超過1M)。所以說ZooKeeper以服務(wù)的模式提供分布式一致性，對于ONOS有太多限制，而這時(shí)Hazelcast攻克了這些問題。

? ?Hazelcast是peer-to-peer的模式，直接應(yīng)用其library以embedded的方式來實(shí)現(xiàn)，也就是每一個ONOS?Instance能夠作為一個peer，ONOS的業(yè)務(wù)數(shù)據(jù)就在同一個JVM中，如圖4所看到的（Hazelcast也能提供C/S模式的服務(wù)）。

更重要的是，Hazelcast是一個IMDG(In-Memory?Data?Grid)，提供了非常方便的接口進(jìn)行數(shù)據(jù)操作。在性能上得到了非常大的提升。可是，Hazelcast有個致命的問題，它還非常不成熟，在版本號升級中可能會不兼容。比方在ONOS1.1.0中依舊有非常多Hazelcast相關(guān)的Bug，這就意味著ONOS依賴于一個不成熟的庫，風(fēng)險(xiǎn)會非常大。實(shí)際上關(guān)鍵的因素是：Hazelcast能否正確地實(shí)現(xiàn)Paxos算法還是一個未知數(shù)。包含ZooKeeper的實(shí)現(xiàn)也不能被證明在算法上正確的。由于Paxos實(shí)在是太復(fù)雜了，能正確理解算法的人不多。更別談實(shí)現(xiàn)了。

有人會認(rèn)為。無論如何Hazelcast會不斷改進(jìn)的，假設(shè)有問題直接提交Bug給Hazelcast不就攻克了？或者說咱們也是做開源的，幫Hazelcast改進(jìn)為什么不行？原因是當(dāng)ONOS有了Hazelcast的Bug后就成了ONOS的Bug，解決這種Bug一方面是存在時(shí)間上的風(fēng)險(xiǎn)，另外一方面也取決于Hazelcast是否會由于支持ONOS而進(jìn)行升級。萬一版本號升級，出現(xiàn)不兼容現(xiàn)象，那么已經(jīng)部署的ONOS風(fēng)險(xiǎn)就更大了。把風(fēng)險(xiǎn)控制在自己能掌控的范圍之中才是ONOS社區(qū)首先考慮的。在這種情況下。Raft就成了不二之選了。

? ?Raft是Multi-Paxos的一種等價(jià)算法，事實(shí)上現(xiàn)能夠通過狀態(tài)機(jī)（一種容錯機(jī)制）、日志副本和一致性模塊（Raft協(xié)議）之間的協(xié)同完畢，這樣的簡單的模型抽象easy實(shí)現(xiàn)client和數(shù)據(jù)在同一個JVM上。以實(shí)現(xiàn)Embedded的方案，詳細(xì)架構(gòu)如圖5所看到的。由于眼下在ONOS代碼中還沒有與Raft相關(guān)的實(shí)現(xiàn)，但我們能夠從ONOS項(xiàng)目的Sprint能夠看出，在ONOS中首先須要解決的是替換掉Hazelcast。而且保留可擴(kuò)展的強(qiáng)一致性的存儲。另外，在維護(hù)設(shè)備的主從關(guān)系上。也須要Raft來實(shí)現(xiàn)，由于選舉服務(wù)是Raft必備的功能。上篇文章也提到過Intent須要強(qiáng)一致性來保障，Intent數(shù)據(jù)是通過分布式隊(duì)列發(fā)送，因此也須要支持基于Raft的數(shù)據(jù)庫服務(wù)。

到眼下為止。我們了解到了ONOS系統(tǒng)架構(gòu)中的高可用方案演進(jìn)的整個過程。

在系統(tǒng)POC初期，ONOS關(guān)注的是SDN概念上的驗(yàn)證，選擇了ZooKeeper滿足了主要的需求。接下來發(fā)如今HA方面存在性能問題，為了保證與ZooKeeper有相同功能，并且性能優(yōu)先的原則，選擇了Hazelcast，并且它確實(shí)做到了。而Hazelcast的問題在于它是一個沒有被廣泛驗(yàn)證過、不成熟的、還在不斷改進(jìn)的方案。ONOS不能依賴于這種一個方案，因此終于選擇了Raft。

盡管要在ONOS中全面實(shí)現(xiàn)Raft還須要時(shí)日，但在這個時(shí)候選擇Raft是正確的、合理的。

????ONOS已經(jīng)將Raft的實(shí)現(xiàn)提上日程，請參考官方的任務(wù)列表，我們共同期待ONOS中的Raft實(shí)現(xiàn)吧！

個人覺得。ONOS在項(xiàng)目管理上做得很優(yōu)秀，這也是ONOS脫穎而出的原因。

?假設(shè)您有興趣，也增加到ONOS的開源社區(qū)吧，關(guān)注ONOS的成長。一起推動SDN的發(fā)展！

參考資料

ZooKeeper官方站點(diǎn)：http://zookeeper.apache.org/

?ZooKeeper相關(guān)介紹：http://www.oschina.net/p/zookeeper

?ZooKeeper的clientKazoo：http://openinx.github.io/2014/06/07/learning-from-kazoo/

?ZooKeeper分布式鎖實(shí)例代碼：http://ifeve.com/zookeeper-lock/

?Hazelcast官方站點(diǎn)：http://hazelcast.org/

?Hadelcast架構(gòu)介紹文檔：http://docs.hazelcast.org/docs/latest/manual/html/overview.html

版權(quán)聲明：本文博客原創(chuàng)文章，博客，未經(jīng)同意，不得轉(zhuǎn)載。

轉(zhuǎn)載于:https://www.cnblogs.com/hrhguanli/p/4755829.html

總結(jié)

以上是生活随笔為你收集整理的ONOS系统架构演进，实现高可用性解决方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。