A New Model for Backend Infrastructure (後端基礎設施的新模型)

原始來源與檔名：2026-06-02T092319+0800-A New Model for Backend Infrastructure.md

NAPKIN | 餐巾纸

餐巾纸公式

傳統整合稅 (Integration Tax) = N 個服務的平方級複雜度 iii 共享運行時 (Shared Runtime) = 所有 Worker (API/佇列/Agent) × 1 個中央 WebSocket 引擎

與其在不同的服務、佇列、狀態儲存和 AI 代理之間寫滿點對點 (Point-to-point) 的膠水程式碼，不如讓所有模組都作為 Worker 連接到同一個共享運行時，實現跨語言的無縫函式呼叫。

一句话

iii 提出了一種全新的後端架構範式：透過單一的 WebSocket 引擎取代微服務間繁瑣的 API 整合，讓 TypeScript、Python 與 AI 代理能像呼叫本地函式一樣互相協作。

餐巾纸草图

[ Traditional ]                   [ iii Shared Runtime ]
SvcA <-> SvcB <-> Queue                 |--> SvcA (TS)
 ^                  ^                   |--> SvcB (Python)
 |                  |             Engine|<-- Queue Worker
SvcC <-> Agent <-> SvcD                 |--> AI Agent
(N^2 複雜度, 滿是 API SDK)               |--> State Worker
                                   (所有節點透過 WebSocket 註冊與呼叫函式)

ROUND 1: SKELETON | 骨架掃描

“這篇文章在說什麼”

• 核心问题: 在傳統後端架構中，每增加一個新功能（佇列、狀態管理、觀測性平台或 AI 代理），就會帶來龐大的「整合稅」。開發者必須花費大量時間撰寫不同語言的 SDK、配置重試機制與處理分散的 Trace 記錄。
• 核心答案: 開源專案 iii 提出了一種「共享運行時 (Shared Runtime)」模型，將所有的微服務與基礎設施都視為透過 WebSocket 連接的 “Workers”，由單一的 Rust 引擎負責路由、序列化與事件觸發。
• 论证结构: 架構比較與概念驗證 (PoC) 展示

章节骨架

1. 問題陳述: 傳統後端架構的點對點整合導致複雜度呈平方級增長。
2. 共享運行時模型: 介紹 iii 引擎的中央集線器概念。
3. AI Agent 的一等公民地位: Agent 不再是外部呼叫者，而是系統內部的原生 Worker。
4. 三大基石: Workers (工作節點), Functions (函式), Triggers (觸發器)。
5. 與傳統方法的差異: 將 API、佇列與排程都收斂到統一的函式目錄背後。
6. 架構演進對比: 以新增一個 Queue 為例，展示「整合前」與「整合後」的巨大差異。
7. 實作演練: 10 分鐘內建立跨語言 (Python/TS) 的多 Worker 系統。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

论证链

服務間的溝通依賴特定的 HTTP 協定與序列化邏輯 --> 系統越龐大，維護各個節點通訊的「膠水代碼」就越多 --> 引入一個用 Rust 撰寫的高效中央引擎 (Engine) --> 所有 Worker (不論語言) 只需透過 WebSocket 連接並註冊自己擁有的 Function --> 引擎統一代管呼叫路由、序列化、重試與追蹤 (Tracing) --> 整合稅降為零，甚至連 AI Agent 都能無縫加入。

关键证据

1. 跨語言無縫呼叫：文章展示了具體的程式碼，TypeScript Worker 可以直接透過 iii.trigger({function_id: 'math::add'}) 呼叫定義在 Python Worker 內的函式，開發者無需處理 HTTP 請求。
2. 基於 Rust 的高效核心：引擎程式碼庫有 74.8% 為 Rust，確保了路由與狀態管理的高效能，而提供給使用者的 SDK 則極度輕量化。
3. 動態擴充：執行 iii worker add queue 即可將佇列能力熱插拔 (Hot-plug) 進入系統，其他節點立即可用，完全不需要修改現有的業務代碼。

隐形假设与边界

• 隐形假设:
  • 中央引擎 (Engine) 必須具備極高的可用性與極低的延遲，否則它將成為整個系統的單點故障 (SPOF) 與效能瓶頸。
  • WebSocket 連線在雲端環境或負載平衡器後方能保持長連線穩定。
• 边界条件:
  • 目前 iii 仍缺乏清晰的大規模容錯語義 (Failure semantics)，例如：當一個 Worker 在執行中途斷線，或者跨節點呼叫失敗時的重試保證。
  • 效能標竿 (Scale characteristics) 尚未發布，面對每秒數萬次請求的大型分散式系統，單一引擎的擴展性仍有待驗證。

ROUND 3: SOUL | 靈魂提取

“還能怎麼用”

• 作者盲点: 儘管宣稱消除了「整合稅」，但這實質上是將系統綁定到了一個新的供應商 (iii Engine) 的生態圈上。如果生態圈不夠大，缺乏特定的功能 Worker，團隊還是得自己用底層 API 刻一個。
• 知识连接: 這種架構在概念上非常類似於 Actor Model (如 Erlang/Akka) 或 Enterprise Service Bus (ESB)，只是它使用了現代化的 WebSocket 與更易用的開發者介面，並且將 AI Agent 原生納入。
• 行动触发: 對於需要頻繁在 Python (AI/ML) 與 TypeScript (前端/API) 之間交換資料的團隊，可以考慮在小型內部工具或 PoC 專案中引入 iii，以取代笨重的 REST API 或 gRPC。

跨域映射

• 在 分散式系統，這叫 遠端程序呼叫 (RPC) 總線
• 在 前端開發，這叫 事件匯流排 (Event Bus) 或全域狀態管理

A New Model for Backend Infrastructure (Architectural Deep Dive)

前言/背景

在現代後端開發中，隨著微服務、佇列、狀態庫以及近期 AI Agent 的加入，系統的「整合複雜度 (Integration Tax)」呈指數級上升。開源專案 iii 提出了一種顛覆性的「共享運行時 (Shared Runtime)」架構，試圖透過一個中央 WebSocket 引擎，徹底消除微服務與基礎設施之間點對點的膠水代碼，實現真正的跨語言函式呼叫。

章節詳細總結

傳統整合的痛點與 iii 的解法

• 整合的平方級複雜度：傳統架構下，服務 A 呼叫服務 B 需實作 HTTP Client，發布到佇列又需另一套 SDK。各種組件不共享重試語義或 Trace 格式。
• 共享運行時 (Shared Runtime)：iii 引入了一個（以 Rust 撰寫的）單一引擎。所有服務透過 WebSocket 連接到該引擎，並將自身註冊為 “Worker”。這使得任何服務都能透過單一的連接點，呼叫其他節點上具名的函式。

三大核心基石 (Three Building Blocks)

1. Workers (工作節點)：任何連接到引擎的進程，無論是 TypeScript API、Python ML 腳本還是 AI Agent，都是平等的 Worker。它們可以部署在本地或雲端，引擎只關心連線狀態。
2. Functions (函式)：擁有穩定命名空間的執行單元（例如 math::add）。開發者只需呼叫該名稱，引擎會自動處理跨語言、跨進程的路由與序列化。
3. Triggers (觸發器)：宣告式地定義函式何時執行。觸發器可以是直接的函式呼叫、HTTP Request、Cron 排程或佇列訂閱。同一個函式處理常式 (Handler) 可以無縫掛載多種觸發器。

AI Agent 的一等公民地位 (Agents as First-class Citizens)

傳統架構中，AI Agent 通常以外部系統的形式存在，需透過特定的 Tool-call 介面與系統互動。 在 iii 模型中，Agent 本身就是一個 Worker。它透過 WebSocket 註冊，直接探索函式目錄 (Function Catalog)，並與其他微服務生成相同格式的 Trace。當 Agent 需要新能力時，甚至可以在運行時透過 iii worker add sandbox 動態載入新模組，實現無需重啟的系統擴展。

實作範例與跨語言呼叫

文章提供了一個具體的實戰演練：

• Python Worker 註冊函式：

  @iii.register_function({"id": "math::add"})
  def add_handler(payload):
      return {"c": payload.get("a", 0) + payload.get("b", 0)}

• TypeScript Worker 直接呼叫：

  const result = await iii.trigger({
      function_id: 'math::add',
      payload: { a: 10, b: 20 },
  });

開發者無需撰寫任何 HTTP Client 或 JSON 解析代碼，引擎包辦了底層通訊。

系統限制與架構考量 (Tradeoffs)

作者在文末誠實地指出了該架構面臨的挑戰：

1. 容錯語義 (Failure Semantics)：目前官方文件對於 Worker 中途斷線、跨節點呼叫的重試保證等分散式系統常見的失敗情境，尚缺乏清晰的規範。
2. 生態系依賴：共享運行時的價值取決於有多少「開箱即用」的預建 Workers (如 iii-http, iii-state)。目前其生態系仍在早期階段。
3. 大規模效能未知：面對數千個 Worker 的高負載、跨區域 (Multi-region) 部署與網路分割 (Network partition) 時，單一引擎的效能特徵仍需生產環境的壓力測試證明。

總結與結論

• 消除整合稅：iii 架構證明了將基礎設施（佇列、排程）與微服務抽象為統一的 Function Catalog，能大幅降低團隊在維護跨系統通訊上的成本。
• 統一的觀測性 (Observability)：因為所有呼叫都流經單一引擎，系統天生具備完美的全局 Tracing 能力，消除了傳統架構中日誌斷鏈的痛點。
• AI 原生架構的雛形：將 AI Agent 視為與普通 API 同等的系統節點，並允許其動態加載工具，展示了下一代「代理驅動 (Agent-driven)」後端架構的可能樣貌。
• 架構建議：對於極高吞吐量的金融或交易系統，目前不建議將核心依賴於這類新型運行時。但對於充滿異質語言 (如 Python AI 模型與 TS 前端) 的新創專案，這是取代傳統 API Gateway 加上 Message Queue 的極佳輕量化替代方案。