這個框架把部署方式變成3道選擇題，開發團隊集體松了口氣

去年有組數據挺有意思：DORA 2024報告顯示，高績效團隊里仍有67%在用單體架構（monolith），但與此同時，微服務相關的技術債務投訴量同比漲了34%。兩邊都在喊疼，問題出在哪？

一個阿根廷開發者從科幻漫畫里找到了答案——《永恒旅人》里有個場景：EMP攻擊后，主角Favalli靠一臺老式柴油車逃出城區。沒有電子系統，意味著沒有可被電磁脈沖摧毀的脆弱點。這哥們突然意識到，技術圈吵了十年的"單體vs微服務"，本質上不是在選架構，而是在逃避一個更深層的問題：剛性（rigidity）。

于是他做了件事：把業務邏輯和運行方式徹底拆開。業務流是穩定的資產，運行拓撲（runtime topology）則可以像換輪胎一樣隨時調整。本地開發用單體，生產環境切微服務，同一套代碼不用重寫。

三種運行形狀，沒有"正確答案"

The Pipeline Framework（TPF）目前支持三種運行拓撲，核心差異在于"誰和誰住在一個進程里"。

全單體模式（Majestic Monolith）：所有步驟（step）和插件（持久化、緩存）都在同一個進程內直接調用。沒有網絡跳轉，調試時堆棧跟蹤干凈得像手術臺。代價也直白——一個組件崩了，全員陪葬。

分組運行時（Pipeline Runtime）：編排器（orchestrator）獨立出去，但業務步驟仍打包運行，插件作為共享服務外置。這是大多數團隊實際在用的"中間態"：有統一的入口，內部組件不外露，又不用吞下分布式系統的全套復雜度。

全微服務模式（Step-per-Service）：每個步驟獨立部署，插件維持共享。隔離性最強，擴容粒度細到單個函數，團隊邊界清晰。賬單和運維復雜度也隨之翻倍。

框架的關鍵設計在于：管道定義（pipeline definition）和運行映射（PipelineRuntimeMapping）完全解耦。一個CSV支付處理的示例管道，可以不經修改地在三種模式下運行——編譯期通過適配輸入輸出格式來匹配目標拓撲，業務邏輯本身零感知。

怎么做到的？把"怎么傳數據"關進黑盒

傳統架構里，一旦選了gRPC或REST，這些傳輸細節會像墨水一樣滲進業務代碼。TPF的做法是分層隔離：

步驟契約（Step Contracts）只聲明意圖，映射器（Mappers）負責邊界轉換，服務層專心做數據轉換。傳輸層的事被壓在運行時映射層處理，本地調用、gRPC、REST、Protobuf-over-whatever，對核心業務來說都是透明的。

生成代碼時，單一語義模型會被投影到不同的執行模式。這意味著團隊可以先寫業務，再決定怎么部署——而不是反過來被技術選型綁架。

有個細節很能說明問題：在CSV支付示例中，同一份管道配置，開發者在筆記本上跑單體調試，CI/CD流水線里切分組模式做集成測試，生產環境再按負載拆成微服務。三次部署，零行代碼改動。

這解決了什么問題？

回到開頭那個矛盾數據。高績效團隊用單體，不是因為微服務不好，而是因為"選了就改不了"的剛性成本太高。技術債務投訴漲34%，也不是微服務本身的錯，而是早期選型被后期需求推翻時，重構代價大到只能硬扛。

TPF的設計哲學是：運行拓撲是變量，不是常量。本地和生產可以共存不同形狀，團隊可以隨業務演進漸進調整，而不是每隔兩年來一次"架構重寫"的死亡行軍。

開發者Andrés在介紹這個框架時打了個比方：「我們不是在選教堂還是帳篷，而是在造一輛能換外殼的車。柴油引擎、混合動力、純電——底盤不變，動力艙隨你換?！?/p>

這個類比或許解釋了為什么項目開源后，金融和物流領域的團隊反饋最積極——這兩個行業有個共同點：監管要求和流量峰值都極度不可預測，"先上線再調整"比"一次選對"更現實。

框架目前還在早期階段，三種拓撲的支持成熟度并不相同。但方向已經清晰：把架構決策從項目啟動時的賭博，變成運營期的常規操作。如果這套思路被更多基礎設施采納，我們會不會看到"架構師"這個職位逐漸消失，變成每個開發團隊都能自助完成的配置項？