微服務帶來大量決策——技術數量、語言慣例、服務該拆該合……架構師的角色也得跟著改變。本章對「架構師到底該做什麼」採取一個強硬主張：離開象牙塔。

名字裡有玄機#

「軟體工程師」「軟體架構師」這些名字都是借來的。傳統建築師、工程師有數千年的知識累積、有嚴格的執照制度——出錯要負法律責任。軟體業才 75 年左右，連「什麼算好」都還沒共識，借名字卻不見得能借到那份嚴謹。

借「架構師」這個詞最大的副作用是：讓人誤以為架構師像建築師那樣，畫好圖、其他人按圖施工。實際上：

• 軟體變更成本遠低於建築（你能改 code，但無法把混凝土倒回去）
• 軟體本來就不該停止演化
• 一張完美藍圖無法預測未來

軟體架構是什麼？#

Ralph Johnson 的完整定義（不是常被引用的那個短句）：

「架構是專家開發者對系統設計的共同理解——這個理解包含系統如何拆分元件，以及這些元件如何透過介面互動。架構是社會建構（social construct）。」

Martin Fowler 的常見句子：「architecture is things that people perceive as hard to change.」也對，但只看這句會錯失「架構應該為變更創造空間」這個核心。

為變更創造空間#

Mies van der Rohe 設計的 Seagram Building：外牆不承重、所有 lift / 樓梯 / 水電 / 空調集中在中央核心——每層樓內部沒有結構牆，可隨需求重新配置。

這就是架構師的工作：界定哪些地方變更便宜（universal space），哪些地方一旦定下就難以改動。

演化型架構師的願景#

Erik Doernenburg（Thoughtworks）：把架構師想成城市規劃師（town planner），而不是建築師。

城市規劃師不會說「這裡要蓋哪棟樓」，而是劃定區域（工業區、住宅區）並設下規範。實際蓋什麼、由哪些人決定，留給該區的人。

城市會演化、會被使用者塑形——規劃師接受這點，把心力放在區域之間的連結，而不是強控所有細節。

把這個比喻搬到微服務：

• 區域 = 微服務的邊界（或一群微服務）
• 區域內部的細節，留給該團隊決定
• 架構師關注區域之間的互動：服務介面、整體系統健康、資料流

定義系統邊界#

• 區域內部：自由
• 區域之間：約束（共通介面協定、版本策略、認證機制）
• 對應「Team API」概念——團隊邊界即架構邊界

「Be worried about what happens between the boxes, and be liberal in what happens inside.」

跨服務之間如果一個用 REST、一個 gRPC、一個 Java RMI——整合會變成噩夢。所以協定、整合方式要有約束；但服務內部的技術棧可以更寬鬆。

至於要寬鬆到什麼程度：Netflix 即使能用各種資料庫，仍然主要採用 Cassandra——因為運維、訓練、工具的成本，比「為每個任務挑最佳工具」的好處更重要。

架構是社會建構#

「No plan survives contact with the enemy.」

——Helmuth von Moltke

Grady Booch：「In the beginning, architecture is a statement of vision. In the end, the architecture of every system is a reflection of the billions upon billions of small and large, intentional and accidental design decisions made along the way.」

架構是「發生了什麼」，不是「規劃了什麼」。

• 架構師若不沉浸在團隊裡 → 你只是個夢想家
• Comcast 的做法：仿 IETF 的開放標準制定流程，建立「架構公會（Architecture Guild）」由各團隊代表協作決策

宜居性（Habitability）#

Richard Gabriel《Patterns of Software》：「Habitability 是讓後續來到這份程式碼的工程師能輕鬆理解其結構與意圖、並有信心改動的特性。」

軟體生態系不只是程式碼——還有工具、流程、實踐方式。架構師若不下場使用團隊的工具，就無法理解他們的痛苦。

強烈建議架構師定期親自寫 code、和團隊配對程式設計。例如四個團隊——每月跟每個團隊配半天，做真實工作。

不下場 = 失去判斷力。

原則導向#

決策需要**框架（framing）**幫助：

原則不要超過 10 條——太多會互相矛盾、人記不住。

範例：戰略目標「縮短上市時間」→ 原則「交付團隊全程掌握自己軟體」→ 實踐「每微服務獨立 CI、獨立部署」。

演化型架構的指引：Fitness Functions#

Neal Ford 等人《Building Evolutionary Architectures》：用 Fitness Function 度量架構的「健康度」。

例：「服務回應 < 100ms」就是一個 fitness function——可在效能測試或 production 持續量測。當數值跑出邊界，架構師就知道要介入。

Fitness function 不是萬靈丹——它和與團隊密切合作互補，而不是取代後者。

Stream-Aligned 組織中的架構師#

• 架構師最自然的位置是Enabling Team：少數常駐架構師 + 各團隊技術負責人輪流參與
• 工作內容：表達技術願景、串連團隊、辨識挑戰、適應願景

何時該否決團隊？#

「教孩子騎腳踏車」比喻——他騎不穩你不要插手；但他要衝向池塘時必須立刻接住。

架構師多數時候要相信團隊的決策，否決會耗損信任。但有少數情況「衝向池塘」時必須出聲——而你常常會發現自己後來才明白團隊那條路其實走得通。

跨切活動與短期決策的衝突#

REA 的解法：把產品負責人也納入對技術品質負責——讓他們得理解效能、安全等議題，並與技術領袖協商優先順序。光把技術債丟給 tech lead 是錯的設計。

建立團隊#

• 微服務的多個獨立 codebase 提供了讓人「擔當」一塊的好機會
• 把單一微服務交給某人擁有 → 是培養下一代技術領袖的好途徑
• 「Great software comes from great people」——只看技術等於只看一半

必要的標準（Required Standard）#

哪些事情必須跨服務一致？作者列出三個高優先：

監控（Monitoring）#

一致的健康指標、一致的 log 格式、推到中央——這是非妥協的。否則你做不出「跨服務的整體健康觀」。

介面（Interfaces）#

選一兩種整合協定（HTTP/REST + 訊息）、再加上版本策略、分頁、命名慣例。20 種風格不行。

架構安全（Architectural Safety）#

• 強制 circuit breaker、time-out
• 嚴守 HTTP 回應碼語意：200/4xx/5xx 不能亂用——熔斷器靠這些區分

治理與鋪好的路（Governance and the Paved Road）#

COBIT 對治理的定義：透過評估持份者需求、設定方向、監控執行成效，確保企業目標達成。

技術治理 = 確保實作符合技術願景。但作者主張輕量化、群體化：

• 一群人協作（不是個人發號施令）
• 把原則討論當作日常活動
• 「鋪好的路」：清楚說明該怎麼做 + 提供讓人輕鬆做對的工具——但不強制

範例（Exemplars）#

文件好，但工程師更愛 code。找出系統內表現好的微服務當示範——而不是另寫「完美的範例」（因為脫離現實）。

量身訂做的微服務模板#

• Spring Boot 等框架可預先配好健康檢查、metrics、JWT 驗證、circuit breaker
• 通常由平台團隊維護
• Netflix 用 JVM 模板與 sidecar，Monzo 用 Go 模板

強推單一模板會壓垮團隊士氣。一些組織採極端做法：把模板程式碼用「複製」而非依賴的方式放進每個服務——升級慢，但避免共享代碼帶來的耦合。

技術債#

• 短期妥協會累積技術債——本身不是錯，但要被看見、被追蹤
• 技術願景變了，原本符合的部分變成新的技術債
• 架構師要看大圖；視組織風格決定是輕量提醒，還是維持正式債務追蹤表

例外處理（Exception Handling）#

• 偶爾會有不照原則的決策——把它記下來
• 同類例外累積到一定程度 → 修改原則反映新理解
• 例：原則「資料庫一律用 MySQL」→ 反覆例外後改為「一般用 MySQL，需要超大規模時用 Cassandra」

演化型架構師的核心職責#

小結#

• 「架構師」這個詞容易誤導——別當建築師，當城市規劃師
• 架構是社會建構：在發生中，不在規劃中
• 為變更創造空間比一次規劃完美更重要
• 用 Fitness Function 量測架構是否還在健康狀態
• Enabling team + 鋪好的路是現代架構師的工具箱
• 架構師必須與團隊一起寫 code，否則只是夢想家
• 推薦延伸閱讀：Neal Ford 等《Building Evolutionary Architectures》、Gregor Hohpe《The Software Architect Elevator》