MustOn Cluster - Cluster & Message Layer

 前言:

上次提到想嘗試開發分散式儲存系統 - GreeStorage，分散式儲存系統有很多塊，但不論哪一塊，分散式系統的基底，訊息中心和通訊層是最核心的部份，這部份也是分散式系統的主軸，因此先從這個部份開始。

成果:

整份專案在
https://gitlab.com/mustoncluster/messagelib_clusterapp

設計過程:

在和AI討論的過程和Storage思考設計過程，避免不了WAL，所有儲存系統的資料寫入都是強一致性行為，無法迴避WAL，而在分散式儲存系統中，WAL就不只跨磁碟，也需要跨網路，跨網路的WAL必定會有Cluster和Message Layer，先攻破這塊。
有趣的事情是，在查找WAL時，想先從既有WAL的應用著手，赫然想到DB HA、DB DR，這需求在之前不只一家公司也不只一次遇到，DB和儲存系統很像，也需要WAL，而DB的WAL在DB中都已經做好了，所以也許可以先從DB HA(高可用性)、DB DR(異地備援)應用著手，既能熟悉WAL也能做出一個應用。
MustOn的名稱由來很好玩，查找DB高可用性當然要看Microsoft SQL Server的Solution，赫然發現，Microsoft把SQL Server的高可用性解決方案重新設計了，設計方向感覺跟OpenAI最近PostgreSQL的優化設計有點像，我懷疑Microsoft的SQL Server在針對AI應用情境優化設計，但我沒有證據 😂
喔～離題了，Microsoft新的SQL Server高可用性設計稱為AlwaysOn，於是我就問AI找個always同義詞，Usually不行，頻率比Always低，這表示比較容易故障，那Must如何～於是MustOn名字就出現了。
原本MustOn應該是DB高可用性方案名字，結果AI亂套，把Cluster命名用上了，那就.....這樣吧 😂

實做過程:

這次基本上都是Claude Code搭配GLM-4.7開發，設計階段則是用Google AI Studio聊天方式討論設計的。
因為現在新的Cluster好像從Paxos演算法改用Raft演算法，因此實做就用Raft的Cluster套件實做，但實做發現，Raft演算法只有Leader -> Follower，並沒有Follower -> Leader，所有訊息都是由Leader往外推送，而不是往內收，因此，基本上無法透過Raft層進行資料傳輸，說人話就是，dotNext Raft的實做就是Raft Cluster的實做，不包括其他API訊息處理，因此dotNext自己另外有一包ASP.NET Core的版本，透過ASP.NET HTTP API做這塊，dotNext官方網站也提到它們有多種傳輸方式，顯然意思都是，Raft Cluster只有Raft唷～其他傳輸行為要另外定義API，這既合理又方便。
我在設計選型階段，就考慮用Apache Thrift當API訊息層傳輸，因為Thrift跟gRPC一樣直接有IDL可以定義出API名稱和參數(gRPC是protobuf)，這會讓API設計更乾淨、清楚，我認為這在Cluster的通訊層設計很重要，因為既然是通訊層，就很容易設計一堆通訊用API和Model，如果不透過IDL或protobuf管理，寫到後面就整個大混亂，完全不知道API有哪些，作用是什麼。
而不用gRPC的原因很簡單，Thrift是binary格式，而gRPC是json文字格式，這表示要傳遞檔案或資料，Thrift也能處理，傳輸內容也會稍微小一點。

結論:

GLM-4.7開發後端的確相當不錯，穩定性很好，趁著特價，我也入坑了。😂
最近好像有龍蝦之亂，看起來能用GLM玩龍蝦，最近很熱門，過陣子有心得，如果很特別再貼吧。