通過架構建議流程實現架構決策的去中心化

作者 | Ben Linders

譯者 | 平川

我們的系統架構會隨著技術和開發實踐的發展而變化，但我們實踐架構的方式并沒有跟上這種變化。按照 Andrew Harmel-Law 的說法，架構需要去中心化，就像我們去中心化我們的系統那樣。在哥本哈根舉行的 Goto 大會上，他提出了架構建議流程。

Harmel-Law 說，架構設計的最大挑戰是在恰當的時間做出恰當的選擇。架構決策無處不在，無時無刻不在發生。如果只有少數被指定的人負責并承擔所有決策的責任，那么他們就必須基于完整準確的信息與背景為所有人做出最優決策。他們還需要對所有這些決策負責：

他們不僅要確保每個人都了解他們對架構的理解；他們還必須不斷從實施和運行這些架構所產生的反饋和錯誤中學習。 坦白說，這是不可能的，如果你不想成為一個阻礙流程運轉的人。

Harmel-Law 說，傳統的架構實踐方法（“象牙塔”和“動手型架構師”這兩種思維定式）不具有可擴展性，會阻礙流程的正常運轉，并且沒有充分考慮來自運行（測試）代碼的反饋循環。“架構師”這個傳統角色需要變成對話的發起者和指導者，推動恰到好處的共識形成，并創造學習與快速反饋的空間。

相對于由一位架構師做出并傳達決策，有一個替代方案是“讓任何人都能做決策”。Harmel-Law 解釋說，架構建議流程為此創造了空間：

聲明“任何人都可以做出任何決策，只要他們從所有受影響方和那些有專業知識的人那里尋求建議（這與許可不同）”，這可以將決策的職責和責任轉移給需要它們的人。雖然沒有人有義務做出決策，但它允許那些自己覺得有必要的人這樣做。

接下來發生的事情是，架構對話開始在需要的地點和時間發生。Harmel-Law 提到了兩個案例研究，參見 InfoQ 的文章：“賦予團隊權力：去中心化架構決策”以及“Xapo 銀行的去中心化架構實踐”。

Harmel-Law 說，在這種情況下，“架構師”角色分散到整個組織中，那些傳統上扮演這個角色的人退回到建議者、背景提供者、決策教練和對話策展人的角色。架構實踐擴展到需要實踐架構設計的人，并由具有相關經驗的人提供支持：

對于一個曾經扮演過傳統“架構師”角色的人，這種體驗的變化令人興奮。

使用架構建議流程，任何人都可以做出任何架構決策，只要他們從以下人員那里尋求建議：

• 那些受影響的人

• 那些有專業知識的人

采用架構建議流程是一場革命；這是回歸到軟件系統設計的第一性原理，將重點放在架構實踐上，即在恰當的時間讓恰當的人進行恰當的對話，Harmel-Law 解釋說：

這種實踐將以一種獨特的方式呈現出來，其獨特性體現在你自身、你的同事、現有的系統、你的客戶、技術的總體演變以及市場等諸多方面。

Harmel-Law 提到了一些需要重點注意的失效模式：

• “糟糕的決策”——特別是高層人士介入阻止決策發生。

• “Old guard == new guard”——仍然是同樣的人（高級架構師）在做所有的決策。

• “雷達外決策”——私下或在不遵循流程的情況下做出決策（如不尋求適當的建議，或不將所有內容記錄在架構決策報告[ADR] 中）。

• 不信任——人們彼此都不信任對方會遵循流程并對決策結果負責。

Harmel-Law 說，起初，參與者可能會遇到一些困難，因為他們難以摒棄自己原有的思維模式。架構決策不再需要共識，建議提供者也不是在為決策提供“許可”——決策權始終掌握在發起當前決策流程的人手中。如果所提供的建議未納入最終決策，那也是完全可以接受的。

Harmel-Law 舉了一個例子，有一個團隊想要為他們正在編寫的服務選擇一個新平臺。選項包括：一組 lambda 函數、一個在 Kubernetes pod 上運行的微服務，或者一系列定制的計算節點：

系統架構師就 lambda 選項提供建議，并在相關 ADR 上發表評論。他們指出，根據他們的經驗，lambda 啟動速度慢，并且會增加狀態管理的難度。盡管理解這些擔憂，但團隊仍然可以選擇基于 lambda 的選項。他們會對決策負責。雖然他們可能已經理解了系統架構師的擔憂，但卻不一定要遵循架構師的建議。

這不僅改變了架構實踐，也改變了那些從事架構設計的人的心理模型。Harmel-Law 說，架構實踐從一種等級化、封閉式的半秘密知識體系和權力博弈，轉變為知識共享和經驗共創的實踐。它弱化個人知識儲備（“我知道一些有價值的東西，其他人都不知道，因此我有權力”），推崇集體知識流動（“當正確的信息在恰當的時機傳遞給合適的人群時，我們都能從中受益”）。

https://www.infoq.com/news/2026/03/architecture-advice-process/

聲明：本文為 InfoQ 翻譯，未經許可禁止轉載。