MustOn Cluster - Cluster & PostgresqlLib & DeployLib & FSM Sample

前言:

延續上次的 MustOn Cluster。
實做進行中，這次先把開發中的PostgresqlLib、DeployLib以及FSM Sample Code放上來。
另外，覺得MustOn這名字不錯，順手把mustoncluster.com註冊了。

成果:

https://gitlab.com/mustoncluster/messagelib_clusterapp
https://gitlab.com/mustoncluster/postgresqllib
https://gitlab.com/mustoncluster/deploylib
https://gitlab.com/ycfunet/my_csharp_fsm_test

實做過程:

幾個點，首先，上次放上gitlab的MessagesLib & ClusterApp有問題，AI騙了我，我跟它說要用Raft Cluster的Metadata進行狀態共享，結果AI偷雞用Thrift API實做，好笑的是，我跟它說：「你好髒喔」，它還知道用Thrift API偷雞是不正確的作法。
這次一樣是用Claude Code搭配GLM-4.7開發，寫到後來基本上有點崩。Cluster目錄\用submodule的方式加入MessagesLib、PostgresqlLib、DeployLib，AI光是用git就差點把本地程式碼和遠端repo(家裡的)的程式碼給刪了。
再來，這樣的架構目前開發，AI經常卡住，改程式碼容易亂改，要嘛改錯東西，要嘛刪除無關的程式碼。感覺這樣的程式碼體積和複雜度，GLM-4.7就有點頂不住了，正好最近GLM-5.0剛發表，初步可能伺服器資源不太夠，反應非常慢，一個問題可能要5分鐘才回覆，但品質看起來不錯，等它穩定性好些，反應速度快些，說不定能提昇目前的處理能力。
再一點是，我嘗試用OpenCode替代Claude-Code進行開發，變成OpenCode + GLM的開發模式，目前還在熟悉和習慣中，OpenCode有不少特異功能，它直接內置Server，讓界面和操作可分離，界面可以是應用程式，也可以是CLI，Model不綁定，可直接用Google Gemini、GLM系列，彈性比較大。

程式還在開發中，正如上面講的，架構比較大，程式碼比較複雜，開始寫得卡卡的，今天情人節，就用這些更新來過吧，農曆新年也要繼續努力。

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玩龍蝦，最近很熱門，過陣子有心得，如果很特別再貼吧。