Reliability, Scalability, Maintainability：重新理解 Go 開發的三個維度

從 Go 的「節制」說起

Go 是我第一個認真鑽研的語言。起初，我覺得許多設計理所當然——沒有繼承、錯誤要一個個處理、Interface 不需要顯式宣告。直到後來接觸了其他語言，回頭再讀 Rob Pike 在 2012 年寫的 Less is exponentially more，我才發現這背後有一套極其嚴密的工程邏輯。

我意識到：這些設計並非功能缺失，而是設計者刻意的留白與偏執的限制。

他們的核心假設是：一個具備高度可維護性的系統，其生命週期與價值將遠超一個功能強大但難以更動的系統。 很多人會問：這種語法上的「節制」，如何轉化為生產環境中的抗風險能力？這就要從 RSM 框架說起。

重新丈量系統：從生命週期的角度審視

在《Designing Data-Intensive Applications》（DDIA）中，Martin Kleppmann 提出了 RSM 框架。我傾向從系統生命週期的維度來定義這三個指標，並用三個問題來檢視它們：

Reliability（可靠性）：對「當下」的驗收

「現在這一秒，系統崩潰了嗎？」

這是最基本的工程要求。它關乎系統在面對網路波動、硬體故障或無效輸入時，是否還能維持預期功能。如果系統無法在「當下」生存，任何長遠規劃都缺乏基礎。

Scalability（擴展性）：對「成長」的預留

「如果明天流量多一個零，我們會倒下嗎？」

壓力會從單點故障轉向資源瓶頸。Scalability 考驗的是架構的彈性——當負載增加時，我們是否有除了「重寫系統」以外的技術手段。

Maintainability（可維護性）：對「持續演進」的保障

「三個月後，這段程式碼是資產還是債務？」

維護性決定了你的系統是一個能持續演進的「活體」，還是一個只能維持現狀、等待重構的「古蹟」。

視角反轉：從平行維度到基石模型

在開發初期，我們常誤以為 R、S、M 像是桌上三個可以獨立調整的旋鈕。為了趕進度，我們傾向調低 Maintainability，將資源專注於實現功能與支撐流量。

但當系統進入長期維護階段，我發現這三個旋鈕之間，竟連著一根隱形的鋼絲：當你把維護性關到零，另外兩個旋鈕很快就會卡死。

理由很簡單：維護性，是可靠性與擴展性的「複利」；反之，它就是摧毀這兩者的「高利貸」。

沒有 M 的可靠性只是運氣。 當程式碼混亂到無人敢動，修復 Bug 就像在黑盒子裡盲操，任何改動都可能引發不可預知的副作用。沒有維護性的可靠，只是運氣好而已。

沒有 M 的擴展性只是重寫。 如果模組耦合過深，當需要拆分服務以應對流量時，你會發現架構僵化到無法拆解。這時你做的不是擴展，而是重寫。

Maintainability 是金字塔的最底層。地基不穩，上面的 R 和 S 蓋得越高，倒塌時的代價就越慘烈。

Go 語言的解答：以簡約支撐複雜

理解了這個框架，Go 的設計決策就顯得非常合理：它透過限制開發者的「小聰明」，換取極致的維護性，進而支撐起長期的 R 與 S。

顯式的代價換取 Reliability。 Go 強迫開發者處理每一個 if err != nil。這種「顯式的繁瑣」確保了錯誤路徑的透明度，防止異常狀態在系統中靜默傳遞。

正交的設計成就 Scalability。 Goroutines 與 Channels 實現了併發模型與業務邏輯的解耦。這種正交性讓開發者能以較低的成本實施並行處理，應對規模化需求。

發現而非設計守護 Maintainability。 隱式接口（Implicit Interfaces）鼓勵在開發過程中「發現」抽象而非預先設計。這讓系統保持了極高的重構彈性，避免了因過度設計導致的架構僵化。

Go 是一門讓你「沒辦法寫得太聰明」的語言，這正是它最高明的地方：它確保三個月後的你，能以最低的認知負擔接手任何一段程式碼。

當理想碰撞現實：成功帶來的「債務」覆盤

即使選用了 Go，如果忽視了架構邊界，依然會面臨技術債的崩潰。

Segment：微服務架構的指標性實踐者。 他們曾為了追求擴展性將系統切成上百個微服務，最終卻發現維護成本高到難以負荷：改動一個共通欄位需要發上百個 PR、跑上百次 CI。這是一個典型的「擴展性紅利被維護成本吞噬」的案例，最終他們選擇回歸單體架構以降低複雜度。

Uber：兩階段的架構進化。 第一階段他們選擇 Go 是為了語言標準化；但當服務規模突破臨界點，混亂的依賴關係依然導致維護崩潰。第二階段的 DOMA 架構轉型則證明了：Go 能提供好讀的程式碼，但只有明確的領域邊界（Domain Boundary）能保證系統的好改與好延展。

結語：選擇你願意承擔的代價

技術選型從來不是在選「哪門語言最強」，而是在選「哪種代價對系統長遠有利」。

身為 Go 工程師，我們選擇了顯式的錯誤處理與簡約的接口。這並非出於對功能的妥協，而是我們深知：唯有守住維護性這個基石，Reliability 與 Scalability 才具備真實的意義。

如果你想在技術路上走得遠，請停止追求「極限效能」，轉而追求「極限的可維護性」。

接下來：實戰中的 RSM

在接下來的三篇專題中，我將深入探討 Go 在這三個維度的核心技術實踐：

Reliability：在 Go 裡預期失敗的藝術 —— 深入分析 Error Handling 與 Context 的生產實踐。

Scalability：Go 服務的擴展策略與陷阱 —— 探討併發模型與分散式系統的取捨。

Maintainability：寫出讓人改得動的 Go 程式碼 —— 接口發現與領域驅動架構的實戰。

讓我從「會寫 Go」，成為「會用 Go 構建系統」。