MsgMesh — 多租戶事件總線平台

把 Kafka 收斂在閘道之後,對外只提供 HTTP／SSE／WebSocket／MCP,讓應用與 AI agent「一句話接入」事件流——鑑權、限流、多租戶隔離全由平台收斂,客戶端永不直連 broker。

● 已上線 · public beta 單人開發~5 週密集Go monorepok8s-readyMCP 原生

即時 Demo（免註冊）↗ 產品站 ↗ SDK 範例 ↗

~30K

行 Go

424

commits

測試檔

服務邊界

01 問題 · The problem

Kafka 很強,但直接攤給每個應用或租戶去用是重擔:每個 client 得自己處理鑑權、計量、租戶隔離、限流、schema 相容,還要能連到 broker——重、危險、又難維護。同時,新一代的 AI agent 需要一個「一句話就訂閱到事件流」的簡單介面,而不是自己搞一套 Kafka consumer。

MsgMesh 的賭注:用一個閘道把 Kafka 收斂在後面,對外只給 HTTP／SSE／WebSocket／MCP;所有跨切面(鑑權、多租戶、限流、可靠投遞、schema 契約)都由平台統一收斂,client 只管「發事件 / 收事件」。

02 核心架構決策與取捨 · Decisions

這一段是我認為最能代表工程判斷的部分——不只「做了什麼」,而是「為什麼這樣選、放棄了什麼」。

客戶端永不直連 Kafka,一切走閘道

為什麼Kafka 對外要自己做鑑權/計量/隔離/限流,又得暴露 broker——重且危險。閘道收斂後對外只給 HTTP/SSE/WS/MCP,平台統一處理跨切面。取捨:多一跳延遲與一個必須高可用的閘道,換來對外介面極簡、安全面收斂。相對 per-tenant cluster 更省維運。

at-least-once + 冪等,而非追求 exactly-once

為什麼webhook 重試必然重送,分散式下 exactly-once 代價極高。選擇 at-least-once + 讓消費端冪等:webhook 帶 HMAC 簽章、失敗進 DLQ 可 replay;計量聚合以位移高水位去重達成冪等。用冪等鍵逼近 exactly-once 的效果,而不付它的成本。

跨副本 presence:fail-open,可用性優先於全域一致

為什麼多個 realtime pod 要共享「誰在線」。presence 存 Redis ZSET(member=連線、score=心跳時間),過期靠掃描。Redis 不可用時 fail-open 回退本地——寧可 presence 短暫不精確,也不讓即時連線整個掛掉。這是刻意選的 CAP 取捨。

契約防漂移:「文件即測試」

為什麼API 文件最容易跟實作漂移。用 chi.Walk 取實際註冊的路由,與 OpenAPI 規格雙向比對——多一條路由沒寫進規格、或規格有而路由沒實作,測試就紅。文件不再是善意的謊言,而是被 CI 強制的真相。

模組化單體:一個 binary,但保留服務邊界

為什麼單人專案,一開始就拆微服務是過早最佳化。選 Go monorepo 模組化單體:allinone 單一 binary 部署、降維運成本,但內部嚴守 6 個服務邊界(control-plane / gateway / realtime / worker / webhook-worker)+ 嚴格分層與 DIP。已備妥 Compose／Helm 拆分路徑——要拆分時不用重寫。

03 關鍵工程亮點 · Highlights

可靠訊息投遞

webhook HMAC 簽章 + 重試 + 死信佇列(DLQ)+ replay,達成 at-least-once;位移高水位去重做到冪等。Kafka · franz-go

即時 + 分散式狀態

SSE 與 WebSocket 共用 live-tail hub;跨副本 presence 以 Redis ZSET 心跳維護、fail-open 回退本地。SSE / WebSocket · Redis

多租戶控制面

租戶 / topic 命名空間、Schema 註冊+版控+BACKWARD 相容檢查、API key(producer/consumer/admin scope)+ 數量上限與方案。PostgreSQL · etcd

為 k8s 水平擴充而生

無狀態服務 + 外部狀態、etcd 設定、advisory-lock 冪等 migration(多 pod 同啟安全);Helm chart + HPA 就緒。Helm/K8s · etcd

接入 DX / 差異化

原生 MCP server,讓 AI agent 直接 watch_topic 訂閱事件流;TS SDK 為唯一 HTTP 契約真相源、自動 OpenAPI + Swagger UI、CLI。MCP · TypeScript SDK

安全縱深

SSRF 防護(urlguard 擋私網,webhook 端)、人機憑證分軌(httpOnly session vs API key)、能力鍵 + 短期 data-plane token、argon2id。chi · JWT · argon2id

04 我怎麼確保品質 · Engineering discipline

這是 AI 輔助開發最容易被質疑的地方,所以我把護欄做在流程裡——這幾道護欄本身,就是「這不是 AI slop」的證明:

TDD + 整合測試 + 端對端 smoke:核心邏輯先寫測試;86 個測試檔覆蓋關鍵路徑。
契約防漂移測試:實際路由 ↔ OpenAPI 雙向比對,API 文件由 CI 強制與實作同步。
合併前 code-review gate:每個 PR 過審查門檻才進 main,即使是單人專案也不放行未審查的碼。
可觀測性內建:Prometheus /metrics + consumer lag(kadm.Lag)+ Sentry + 告警規則,上線即可觀測。

05 技術棧 · Stack

Go 1.25 · Kafka(franz-go)· PostgreSQL(pgx)· Redis · etcd
SSE / WebSocket · MCP · chi · JWT · argon2id · 分層架構 + DIP
Helm / Kubernetes · Docker Compose · Prometheus · Sentry

誠實邊界 · Honest framing

這是一個以 AI 輔助、單人在約 5 週內從 0 打造並持續維運的專案(public beta,非生產規模商用服務)。我的角色是架構決策、規範制定、審查把關與全流程 owner;大量實作碼由 AI(Claude Code)在我的方向與把關下產生。上面那些護欄——契約測試、code-review gate、TDD、DLQ、冪等——正是我用來確保它「不是 vibe-coded slop」的方式。深層實作我審過方向、細節可現場打開驗證。

這個專案要證明的一件事:我能一個人,從架構決策、實作、上線到監控維運,把一套多租戶後端系統端到端交付——並且用工程紀律,而不是靠運氣,守住品質。這正是遠端、高自主團隊需要的能力。

聯絡我 → 先看即時 Demo ↗ 回首頁