怎么使用SOFAStack

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

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

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

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

1. Leader 選舉；

2. Membership 變更；

3. 日志復制；

4. Snapshot。

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

1.1 Raft 算法的整體結構概覽

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

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

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

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

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

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

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

1.3 任期與邏輯時鐘概念

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

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

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

1.4 Raft 算法的實際應用實現

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 為何技術選型 SOFAJRaft 庫？

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

其中：

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

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

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

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

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

為了提供支持生產環境運行的高性能，SOFAJRaft 主要做了如下幾部分的性能優化，其中：

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

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

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

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

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

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

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

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

2. BC-MQ 組件集成 SOFAJRaft 的優化設計

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

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

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

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

組件服務端的狀態機接口實現

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

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

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

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

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

客戶端請求重定向機制優化

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

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

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

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

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