怎么使用SOFAStack

這篇文章主要講解了“怎么使用SOFAStack”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“怎么使用SOFAStack”吧！

一、背景知識：Raft 共識性算法是什么？

Raft 是一種分布式系統(tǒng)中易于理解的共識算法，該協(xié)議本質上是 Paxos 算法的精簡版，而不同的是依靠 Raft 模塊化的拆分以及更加簡化的設計，其實現(xiàn)起來更加容易和方便。[1]

模塊化的拆分主要體現(xiàn)在 Raft 把一致性協(xié)議劃分為如下幾部分：

1. Leader 選舉；

2. Membership 變更；

3. 日志復制；

4. Snapshot。

而更加簡化的設計則體現(xiàn)在：Raft 不允許類似 Paxos 中的亂序提交、簡化系統(tǒng)中的角色狀態(tài)（算法定義 Leader、Follower 和 Candidate 三種角色）、限制僅 Leader 可寫入、采用隨機超時觸發(fā) Leader Election 機制來避免“瓜分選票”等等。[2]

1.1 Raft 算法的整體結構概覽

cdn.nlark.com/yuque/0/2019/png/439987/1565080443481-be36948c-ecee-46cc-ad3a-c5c9d5b5799c.png">

從上面的 Raft 算法整體結構圖中可以看出，整個分布式系統(tǒng)中同一時刻有且僅有一個 Leader 角色的節(jié)點（如圖最右邊的服務器），只有 Leader 節(jié)點可以接受 Client 發(fā)送過來的請求。Leader 節(jié)點負責主動與所有 Follower 節(jié)點進行網(wǎng)絡通信（如圖左邊兩個服務器），負責將本地的日志發(fā)送給所有 Follower 節(jié)點，并收集分布式系統(tǒng)中多數(shù)派的 Follower 節(jié)點的響應。此外，Leader 節(jié)點，還需向所有 Follower 節(jié)點主動發(fā)送心跳維持領導地位（即：保持存在感）。

所以，只要各個節(jié)點上的日志保持內容和順序是一致的，那么節(jié)點上的狀態(tài)機就能以相同的順序執(zhí)行相同的命令，這樣它們執(zhí)行的結果也都是一樣的。

1.2 Raft 算法的三種角色及轉換

1. Follower：完全被動，不能發(fā)送任何請求，只接受并響應來自 Leader 和 Candidate 的 Message，每個節(jié)點啟動后的初始狀態(tài)一般都是 Follower；

2. Leader：處理所有來自客戶端的請求、復制 Log 到所有 Follower，并且與 Follower 保持心跳請求；

3. Candidate：節(jié)點競選 Leader 時的狀態(tài)。Follower 節(jié)點在參與選舉之前，會將自己的狀態(tài)轉換為 Candidate。

1.3 任期與邏輯時鐘概念

1. 時間被劃分為多個任期 term（如同總統(tǒng)選舉一樣），term id 按時間軸單調遞增；

2. 每一個任期開始后要做的第一件事都是選舉 Leader 節(jié)點，選舉成功之后，Leader 負責在該任期內管理整個分布式集群，“日志復制”、“通過心跳維護自己的角色”；

3. 每個任期至多只有一個 Leader 節(jié)點，也可能沒有 Leader (由于“分票”導致)。

1.4 Raft 算法的實際應用實現(xiàn)

目前，Raft 算法已經成熟地應用于諸多知名的開源項目中。業(yè)界非常著名的 Etcd(Kubernetes 高可用強一致性的服務發(fā)現(xiàn)組件)和 TiKV (高性能開源 KV 存儲)均是 Raft 算法的實現(xiàn)。

二、BC-MQ 基于 Raft 的高可用設計

為滿足企業(yè)上云和構建萬物相連的物聯(lián)網(wǎng)業(yè)務需求，中國移動蘇州研發(fā)中心結合自身在云計算產品和技術的較多積累，研發(fā)了大云消息隊列中間件產品 BC-MQ。該產品基于 Apache 開源社區(qū)的 RocketMQ 內核，同時結合云端 PAAS 產品架構和消息中間件的應用業(yè)務需求進行深度優(yōu)化和定制化的研發(fā)，提供了一款可以滿足于云端場景的高性能、高可靠、低延遲和高可用的工業(yè)級產品。

本節(jié)從解決原有高可用技術方案的問題視角出發(fā)，同時結合選型 SOFAJRaft 庫的緣由，將詳細闡述 BC-MQ 產品中的安全認證和 API 計量采集服務的高可用設計方案（注：這里不會涉及到安全認證和 API 計量采集組件本身的技術方案細節(jié)）。

2.1 GlusterFS+Keepalived 高可用方案與問題

1. GlusterFS+Keepalived 高可用設計方案

在BC-MQ原有的方案中，多組安全認證服務各自獨立部署組建集群，各個安全認證服務相互獨立，沒有主從關聯(lián)，服務本身無狀態(tài)，可水平任意擴展。安全認證服務的高可用依賴于RPC通信的客戶端保證，其主要通過負載均衡算法從安全認證服務集群選擇一個節(jié)點發(fā)送RPC請求來實現(xiàn)租戶級鑒權認證元數(shù)據(jù)的獲取。在生產環(huán)境中，如果出現(xiàn)其中一個安全認證節(jié)點宕機不可用時，客戶端的RPC通信層能夠及時感知并從本地的Node列表中剔除不可用節(jié)點。

集群中有狀態(tài)的租戶級安全認證元數(shù)據(jù)的強一致性由GlusterFS分布式文件存儲的同步機制來保證。安全認證服務組建高可用集群的具體設計方案圖如下所示：

而 BC-MQ 中 API 計量采集服務組件的高可用性則是依靠 Keepalived 組件的冷備模式結合 GlusterFS 分布式文件存儲的同步機制共同保證，從而在一定程度上解決了 API 計量采集服務的單點不可用問題。API 計量采集服務的具體高可用設計方案圖如下所示：

2. GlusterFS+Keepalived 高可用方案遇到的問題

初步看上面的這種高可用技術方案挺完美的。但是經過驗證和仔細推敲后就發(fā)現(xiàn)在生產環(huán)境中可能會存在如下幾個問題：

1. 上面所述的高可用設計方案中引入了 GlusterFS 分布式文件存儲系統(tǒng)和 Keepalived 組件，這增加了系統(tǒng)整體的運維復雜度，給運維人員帶來很多人工介入排查和部署的工作負擔；另一方面，GlusterFS 和 Keepalived 本身的可靠性、穩(wěn)定性和性能指標等問題也需要軟件研發(fā)人員重點關注，這增加了系統(tǒng)整體設計的復雜度；

2. 在實際的生產環(huán)境中，Keepalived 組件采用冷備方式作為高可用方案需要考慮主機故障宕機后切換到備機的時間成本消耗。在這段時間內，API 計量服務是短暫不可用的。因此，Keepalived 組件的主備切換會造成業(yè)務感知影響，導致一些業(yè)務的風險發(fā)生。

2.2 基于 SOFAJRaft 庫的高可用設計方案

由于“GlusterFS+Keepalived”的高可用方案存在上一節(jié)闡述的兩個問題，所以我們考慮是否可以采用其他的高可用方案來解決這兩個問題？目標：即使生產環(huán)境出現(xiàn)部分節(jié)點故障后，安全認證和 API 計量組件依舊能夠正常提供服務，做到業(yè)務無感知。

為了實現(xiàn)當分布式集群中的部分節(jié)點出現(xiàn)故障停服后，集群仍然能夠自動選主繼續(xù)正常對外提供服務，使得故障對外部業(yè)務不會產生任何影響，同時高可用方案又不能依賴外部系統(tǒng)，那我們也就想到了 Raft 算法。Raft 算法設計，簡潔易懂，沒有任何外部依賴，可以完成一個高可靠、高可用、強一致的數(shù)據(jù)復制系統(tǒng)，解決我們前面遇到的問題。

業(yè)界有一些 Raft 算法的實現(xiàn)，目前比較流行的主要有百度開源的Braft和螞蟻金服開源的 SOFAJRaft。從官方 Github 上對兩款開源 Raft 實現(xiàn)框架支持的功能和特性來看，基本相近，但 Braft 是 C/C++ 語言實現(xiàn)的，而 SOFAJRaft 是 JAVA 語言實現(xiàn)的，因此我們從技術棧、集成難易和運維成本等角度綜合考慮，最終選擇了 SOFAJRaft。

1. 為何技術選型 SOFAJRaft 庫？

SOFAJRaft 是一個基于 Raft 一致性算法的生產級高性能 JAVA 實現(xiàn)，支持 MULTI-RAFT-GROUP，適用于高負載低延遲的場景。使用 SOFAJRaft，使用者可以更加專注于自己的業(yè)務領域，由 SOFAJRaft 負責處理所有與 Raft 算法相關的技術難題，并且 SOFAJRaft 比較易于使用，用戶可以通過 Github 上的幾個示例在很短的時間內掌握并使用它。下面先簡單介紹下 SOFAJRaft 的特性和增強功能點：

其中：

1. Membership change 成員管理：集群內成員的加入和退出不會影響集群對外提供服務。

2. Transfer leader：除了集群根據(jù)算法自動選出 Leader 之外，還支持通過指令強制指定一個節(jié)點成為 Leader。

3. Fault tolerance 容錯性：當集群內有節(jié)點因為各種原因不能正常運行時，不會影響整個集群的正常工作。

4. 多數(shù)派故障恢復：當集群內半數(shù)以上的節(jié)點都不能正常服務的時候，正常的做法是等待集群自動恢復，不過 SOFAJRaft 也提供了 Reset 的指令，可以讓整個集群立即重建。

5. Metrics：SOFAJRaft 內置了基于 Metrics 類庫的性能指標統(tǒng)計，具有豐富的性能統(tǒng)計指標，利用這些指標數(shù)據(jù)可以幫助用戶更容易找出系統(tǒng)性能瓶頸。

為了提供支持生產環(huán)境運行的高性能，SOFAJRaft 主要做了如下幾部分的性能優(yōu)化，其中：

1. 并行 append log：在 SOFAJRaft 中 Leader 本地持久化 Log 和向 Follower 發(fā)送 Log 是并行的。

2. 并發(fā)復制 Leader 向所有 Follwers 發(fā)送 Log 也是完全相互獨立和并發(fā)的。

3. 異步化：SOFAJRaft 中整個鏈路幾乎沒有任何阻塞，完全異步的，是一個完全的 Callback 編程模型。

因此，綜上所述我們最終選用 SOFAJRaft 的理由如下：

1. SOFAJRaft 基于 JAVA 實現(xiàn)，能夠很方便的與 BC-MQ 中安全認證服務和 API 計量服務組件進行集成。

2. SOFAJRaft 作為一個實現(xiàn) Raft 協(xié)議的框架，提供了易于實現(xiàn)的狀態(tài)機接口，只需要實現(xiàn)它提供的接口即可完成高可用的改造。

3. 從實際的驗證結果來說，SOFAJRaft 的性能和穩(wěn)定性能夠完全滿足甚至超過我們的預期。

4. SOFAJRaft 的功能性能夠解決上面篇幅中 BC-MQ 原有“GlusterFS+Keepalived”高可用方案中所遇到的問題。

2. BC-MQ 組件集成 SOFAJRaft 的優(yōu)化設計

BC-MQ在集成SOFAJRaft庫后在部署架構、數(shù)據(jù)持久化和高可用模式上都進行了能力升級，較好地解決了“GlusterFS+Keepalived”中的問題。

1. 部署架構：集成SOFAJRaft庫后，BC-MQ的安全認證和API計量服務的高可用部署不再依賴“GlusterFS+Keepalived”這兩個外部組件；安全認證和API計量服務組件按照配置文件獨立部署組成相應的RaftGroup即可對外提供服務；

2. 數(shù)據(jù)持久化：數(shù)據(jù)的強一致性不再依賴“GlusterFS分布式文件存儲”。通過SOFAJRaft的日志復制和狀態(tài)機，實現(xiàn)集群中Leader節(jié)點和Follower節(jié)點的數(shù)據(jù)同步保證主備節(jié)點的數(shù)據(jù)一致性；

3. 高可用模式：從原有的“KeepaLived冷備切換”轉變?yōu)椤癛aft自動Leader選舉”，發(fā)生故障后，API計量服務仍然能夠對外正常提供服務，故障轉移的過程無需運維人員介入；

組件服務端的狀態(tài)機接口實現(xiàn)

針對具體的業(yè)務應用而言（對 BC-MQ 來說，就是 API 計量統(tǒng)計和安全認證鑒權），狀態(tài)機（StateMachine）是業(yè)務邏輯實現(xiàn)的主要接口，狀態(tài)機運行在每個Raft節(jié)點上，提交的 任務 Task 如果成功，最終都會復制應用到分布式集群中的每個節(jié)點的狀態(tài)機上。

在 SOFAJRaft 中提供了一個已經具備絕大部分默認實現(xiàn)的抽象適配類— StateMachineAdapter，直接繼承它可以使得業(yè)務應用避免實現(xiàn)所有的接口。我們根據(jù) BC-MQ 組件改造的需求，對部分接口做了如下的實現(xiàn)：

1. void onApply(Iterator iter)：該方法是 SOFAJRaft 中最為核心的接口。在整個分布式集群環(huán)境中，待同步的數(shù)據(jù)會封裝成 LogEntry 復制到其他節(jié)點。在數(shù)據(jù)同步完成之后，進程會提交到自身狀態(tài)機的這個方法中執(zhí)行。在 BC-MQ 中，API 計量采集服務在計量統(tǒng)計數(shù)據(jù)日志同步至 Follower 節(jié)點后，SOFAJRaft 在業(yè)務狀態(tài)機的 onApply 方法中調用 API 計量采集服務組件的存儲接口進行持久化。

2. void onLeaderStart(long term)/void onLeaderStop(Status status)：這個兩個方法是在節(jié)點通過選舉成為 Leader 和失去 Leader 資格時調用，BC-MQ 的安全認證和 API 計量服務組件本身也維護了 Raft 的角色狀態(tài)（這里的角色狀態(tài)與 SOFAJRaft 本身的是保持一致的）。在節(jié)點的角色發(fā)生轉變的時候，需要調用這個方法，將組件的角色和狀態(tài)轉變一致。這樣實現(xiàn)主要是與 BC-MQ 的業(yè)務場景相關，在集群中經過重新選舉后節(jié)點角色轉變時，只有API 計量組件服務的 Leader 節(jié)點才能夠執(zhí)行消息隊列的 API 計量采集相關的定時任務。

3. void onSnapshotSave(SnapshotWriter writer, Closure done)/boolean onSnapshotLoad(SnapshotReader reader)：這兩個方法是 SOFAJRaft 快照相關的接口調用，快照本身的作用就是在有新的節(jié)點加入到 SOFAJRaft Group 時，不需要加載全部的 Log 日志數(shù)據(jù)，而只需要從最近的 index 開始加載，這可以節(jié)省從 Leader 節(jié)點同步大量日志信息所造成的網(wǎng)絡通信開銷。BC-MQ 的安全認證和 API 計量采集服務組件實現(xiàn)了這兩個方法，用于實現(xiàn)快照的特性。

客戶端請求重定向機制優(yōu)化

SOFAJRaft 中默認只有 Leader 節(jié)點能夠被客戶端訪問到，所有的日志提交都需要先提交到集群的 Leader 節(jié)點，然后由Leader節(jié)點同步到其他的 Follower 節(jié)點。BC-MQ 的安全認證服務和 API 計量服務組件通過 SOFAJRaft 改造后，在 BC-MQ 中原有的客戶端 RPC 請求訪問方式也需要經過一些優(yōu)化設計，為了讓客戶端能夠實時感知到分布式集群環(huán)境中當前的 Leader 節(jié)點，因此需要在客戶端緩存一個集群的節(jié)點列表 NodeList 和 LeaderId。

僅僅在客戶端維護一個本地緩存還不夠，因為如果集群中的 Leader 節(jié)點出現(xiàn)了宕機的故障時，集群會發(fā)生重新選舉，那么客戶端緩存的 Leader 節(jié)點信息就會過期，這就需要客戶端就能夠感知到 Leader 節(jié)點的變化。為解決這個問題，我們采用了 RPC 請求重定向機制來保證，一旦RPC請求發(fā)送到了集群中的 Follower 節(jié)點，那么 Follower 會將該請求重定向到 Leader。以下為 BC-MQ 客戶端通信重定向機制優(yōu)化設計圖：

三、BC-MQ 的高可用與節(jié)點管理性驗證

下面展示的是 BC-MQ 的安全認證服務和 API 計量服務組件的部分測試用例，從用例的實際執(zhí)行情況來看，與我們的預期結果完全一致可以滿足生產環(huán)境高可用的業(yè)務場景。

感謝各位的閱讀，以上就是“怎么使用SOFAStack”的內容了，經過本文的學習后，相信大家對怎么使用SOFAStack這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！