上篇文章《ONOS高可用性和可擴展性實現(xiàn)初探》講到了ONOS系統(tǒng)架構(gòu)在高可用旗唁、可擴展方面技術(shù)概況胁赢，提到了系統(tǒng)在分布式集群中如何保證數(shù)據(jù)的一致性。在數(shù)據(jù)最終一致性方面，ONOS采用了Gossip協(xié)議，這一部分的變化不大竭翠，而在強一致性方案的選擇方面則在不斷進行調(diào)整，其主要原因是分布式系統(tǒng)中強一致性對系統(tǒng)性能影響較大，而且現(xiàn)有的支持Paxos算法的實現(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一個開源的實現(xiàn),以C/S方式提供服務(wù)，應(yīng)用場景包括配置維護饵沧、名字服務(wù)锨络、分布式同步、組服務(wù)等?狼牺∠鄱客戶端?與服務(wù)器(Follower/Leader)以Watch/Callback的方式進行交互，如圖1所示流程是钥，可參考相關(guān)實例代碼失受。
Hazelcast是一種內(nèi)存數(shù)據(jù)網(wǎng)格(IMDG: In-Memory Data Grid),網(wǎng)格中所有的節(jié)點是以Peer-to-Peer的方式組建集群,并且所有數(shù)據(jù)置于內(nèi)存中以提高訪問性能[ Hadelcast架構(gòu)介紹文檔]。Hazelcast提供了通用的數(shù)據(jù)結(jié)構(gòu)（如Map, List, Queue等）和簡單的API進行數(shù)據(jù)操作咏瑟，可以直接引入jar包進行實現(xiàn)拂到，可以參考下文提供的相關(guān)實例代碼。
Raft是為了解決Paxos算法的可讀性以及實現(xiàn)中拋棄一些細節(jié)形成的等價于Multi-Paxos算法码泞。它依賴于復(fù)制狀態(tài)機（Replicated?State?Machine）兄旬，通過Replicated?Log將操作指令復(fù)制到各個節(jié)點，然后各節(jié)點在本地按相同的順序執(zhí)行相同的命令余寥，產(chǎn)生一致的狀態(tài),圖2展示的是Raft狀態(tài)機领铐。
根據(jù)上面的介紹，我們對這些方案有了初步的了解∷蜗希現(xiàn)在假設(shè)我們是該系統(tǒng)的設(shè)計者绪撵，面臨對這三個方案技術(shù)方案進行選型，我們首先需要對這些方案進行對比祝蝠，具體如表1所示：
從解決問題的角度來說音诈，這三個方案都可以解決ONOS在分布式一致性協(xié)作方面的問題，因為算法證明了這些方案都是“正確”的绎狭，除非實現(xiàn)上有Bug细溅。就算法的性能來說，差異不是很大儡嘶。Paxos算法(一種基于消息傳遞模型的一致性算法)喇聊，它能保證在一個分布式數(shù)據(jù)庫系統(tǒng)中，如果各節(jié)點的初始狀態(tài)一致蹦狂，每個節(jié)點都執(zhí)行相同的操作序列誓篱，那么他們最后能得到一個一致的狀態(tài)朋贬。而Raft算法是等價于Multi-Paxos的算法，它主要解決的是Paxos晦澀的描述窜骄，以及Paxos的實現(xiàn)不能真正意義上的完全正確（實現(xiàn)上無法用公式證明）锦募。這兩個算法雖然在實現(xiàn)上差別很大，比如一致性實現(xiàn)中角色的定義啊研，比如ZooKeeper中定義了Leader/Follower御滩，Raft定義了Candidate/Leader/Follower角色鸥拧，但其最核心的兩個關(guān)鍵活動党远，一個是選舉，其目的就是從分布的節(jié)點中選出Leader節(jié)點作為一致性的參考標桿富弦，其它的Follower就成為“鏡像”沟娱。選舉只有在初始化或有Leader退出/失效時才發(fā)生，在分布式系統(tǒng)中腕柜，節(jié)點失效出現(xiàn)的頻次很低济似，而且選舉動作都是可以在秒級別能完成的，對系統(tǒng)的性能影響不大盏缤，不明顯砰蠢，實際情況中與系統(tǒng)節(jié)點數(shù)的奇/偶性更相關(guān)，比如4個節(jié)點或6個節(jié)點選舉時間可能比13個節(jié)點選舉時間更長唉铜。另外一個是同步台舱，其目的是通過復(fù)制數(shù)據(jù)/操作來達到所有的Follower都能產(chǎn)生一致的結(jié)果，只要狀態(tài)有更新（比如寫操作）潭流，那么就會觸發(fā)同步動作竞惋，同步意味著數(shù)據(jù)的復(fù)制以及消息的傳遞，從分布式架構(gòu)來說灰嫉，在讀寫IO方面這三種實現(xiàn)方式都相差不多拆宛。從這個角度來說，算法不是決定因素讼撒。
大家可能會問：既然算法都差不多了浑厚，就沒有必要在ONOS實現(xiàn)上大動手腳了。其實根盒，從上表我們可以知道瞻颂，當初選擇ZooKeeper作為Prototype?1的首選，主要是因為ZooKeeper成熟穩(wěn)定郑象，它在Hadoop生態(tài)圈是鼎鼎有名的高性能贡这、分布式的應(yīng)用協(xié)調(diào)服務(wù)的首選。從ONOS的Prototype?1的實現(xiàn)來看厂榛，ZooKeeper確實滿足了分布式集中控制的需求盖矫，另外一方面丽惭，在其實驗過程中，驗證系統(tǒng)的性能時辈双，很多數(shù)據(jù)是全局靜態(tài)的责掏，比如Flow?Rule在實際的應(yīng)用中是通過控制器以Lazy的方式下發(fā)到交換設(shè)備中，那么這些數(shù)據(jù)可以提前在ZooKeeper中準備好湃望，只要實驗中不進行交換設(shè)備的動態(tài)增加或者移除换衬，不會影響到整體性能。也就是說证芭，在Prototype?1中主要關(guān)注SDN的概念在ONOS上能發(fā)揮到何種程度瞳浦，而不關(guān)心交換設(shè)備動態(tài)增加、刪除等場景废士。
也就是說當有數(shù)據(jù)大量更新時叫潦，ZooKeeper則會出現(xiàn)性能問題，這主要因為ZooKeeper是以服務(wù)的形式來保障數(shù)據(jù)的一致性的官硝。相對于ONOS來說矗蕊，ZooKeeper是它的一個依賴子系統(tǒng)，因此在部署ONOS之外還要單獨部署ZooKeeper服務(wù)氢架，如圖3所示的Client與Server之間的讀寫模型傻咖。由于ZooKeeper中所有的數(shù)據(jù)都以ZNode表示，這些ZNode存儲在ZooKeeper的Server上岖研，Client要讀的數(shù)據(jù)需要跨JVM訪問Server卿操。這樣ONOS?Instance就變成了zClient，那么當ONOS不同實例間需要同步數(shù)據(jù)時缎玫，需要通過TCP的方式從zServer上請求數(shù)據(jù)硬纤，這就導(dǎo)致了ONOS的性能會急劇下降，另外赃磨，ZooKeeper的zNode對數(shù)據(jù)大小有限制(zNode數(shù)據(jù)大小不能超過1M)筝家。所以說ZooKeeper以服務(wù)的模式提供分布式一致性，對于ONOS有太多限制邻辉，而這時Hazelcast解決了這些問題溪王。
Hazelcast是peer-to-peer的模式，直接應(yīng)用其library以embedded的方式來實現(xiàn)值骇，也就是每個ONOS Instance可以作為一個peer莹菱，ONOS的業(yè)務(wù)數(shù)據(jù)就在同一個JVM中，如圖4所示（Hazelcast也能提供C/S模式的服務(wù)）吱瘩。更重要的是道伟，Hazelcast是一個IMDG(In-Memory Data Grid)，提供了很方便的接口進行數(shù)據(jù)操作，在性能上得到了很大的提升蜜徽。但是祝懂，Hazelcast有個致命的問題，它還很不成熟拘鞋，在版本升級中可能會不兼容砚蓬。比如在ONOS1.1.0中依然有很多Hazelcast相關(guān)的Bug，這就意味著ONOS依賴于一個不成熟的庫盆色，風險會很大灰蛙。實際上關(guān)鍵的因素是：Hazelcast是否能正確地實現(xiàn)Paxos算法還是一個未知數(shù)，包括ZooKeeper的實現(xiàn)也不能被證明在算法上正確的隔躲，因為Paxos實在是太復(fù)雜了摩梧，能正確理解算法的人不多，更別談實現(xiàn)了蹭越。有人會覺得障本，不管怎樣Hazelcast會不斷改進的教届，如果有問題直接提交Bug給Hazelcast不就解決了响鹃？或者說咱們也是做開源的，幫Hazelcast改進為什么不行案训？原因是當ONOS有了Hazelcast的Bug后就成了ONOS的Bug买置，解決這樣的Bug一方面是存在時間上的風險，另外一方面也取決于Hazelcast是否會因為支持ONOS而進行升級强霎。萬一版本升級忿项，出現(xiàn)不兼容現(xiàn)象，那么已經(jīng)部署的ONOS風險就更大了城舞。把風險控制在自己能掌控的范圍之中才是ONOS社區(qū)首先考慮的轩触。在這種情況下，Raft就成了不二之選了家夺。
Raft是Multi-Paxos的一種等價算法脱柱，其實現(xiàn)可以通過狀態(tài)機（一種容錯機制）、日志副本和一致性模塊（Raft協(xié)議）之間的協(xié)同完成拉馋，這種簡單的模型抽象容易實現(xiàn)客戶端和數(shù)據(jù)在同一個JVM上榨为，以實現(xiàn)Embedded的方案，具體架構(gòu)如圖5所示煌茴。由于目前在ONOS代碼中還沒有與Raft相關(guān)的實現(xiàn)随闺，但我們可以從ONOS項目的Sprint可以看出，在ONOS中首先需要解決的是替換掉Hazelcast蔓腐，并且保留可擴展的強一致性的存儲矩乐。另外，在維護設(shè)備的主從關(guān)系上回论，也需要Raft來實現(xiàn)散罕，因為選舉服務(wù)是Raft必備的功能撒璧。上篇文章也提到過Intent需要強一致性來保障，Intent數(shù)據(jù)是通過分布式隊列發(fā)送笨使，因此也需要支持基于Raft的數(shù)據(jù)庫服務(wù)卿樱。
到目前為止，我們了解到了ONOS系統(tǒng)架構(gòu)中的高可用方案演進的整個過程硫椰。在系統(tǒng)POC初期繁调，ONOS關(guān)注的是SDN概念上的驗證，選擇了ZooKeeper滿足了基本的需求靶草；接下來發(fā)現(xiàn)在HA方面存在性能問題蹄胰，為了保證與ZooKeeper有同樣功能，而且性能優(yōu)先的原則奕翔，選擇了Hazelcast裕寨，而且它確實做到了。而Hazelcast的問題在于它是一個沒有被廣泛驗證過派继、不成熟的宾袜、還在不斷改進的方案，ONOS不能依賴于這樣的一個方案驾窟，因此最終選擇了Raft庆猫。雖然要在ONOS中全面實現(xiàn)Raft還需要時日，但在這個時候選擇Raft是正確的绅络、合理的月培。
ONOS已經(jīng)將Raft的實現(xiàn)提上日程，請參考官方的任務(wù)列表恩急，我們共同期待ONOS中的Raft實現(xiàn)吧杉畜！個人認為，ONOS在項目管理上做得非常優(yōu)秀衷恭，這也是ONOS脫穎而出的原因此叠。?如果您有興趣，也加入到ONOS的開源社區(qū)吧匾荆，關(guān)注ONOS的成長拌蜘，一起推動SDN的發(fā)展！
參考資料
ZooKeeper官方網(wǎng)站：http://zookeeper.apache.org/
ZooKeeper相關(guān)介紹：http://www.oschina.net/p/zookeeper
ZooKeeper的客戶端Kazoo：http://openinx.github.io/2014/06/07/learning-from-kazoo/
ZooKeeper分布式鎖實例代碼：http://ifeve.com/zookeeper-lock/
Hazelcast官方網(wǎng)站：http://hazelcast.org/
Hadelcast架構(gòu)介紹文檔：http://docs.hazelcast.org/docs/latest/manual/html/overview.html
