Go 讓我跑得快，Rust 讓我用心，AWS 讓我付出。

多年來，我的雲端架構一直感覺……還算合理。

• Go 服務

• AWS 基礎設施

• 到處都是貨櫃

• 上面撒了一些Lambda

• 儀錶板大部分為綠色

部署速度很快，工程師們工作效率很高，沒有人抱怨。

現在回想起來，這應該是我的第一個警示訊號。

因為在雲端，系統通常不會發生明顯的故障。

它們在財務上失敗了。

舒適階段：當 Go + AWS 感覺像超能力一樣強大

Go 有一種危險的魔力，它能讓人感覺一切都在掌控之中。

你寫一個服務。

它能立即編譯。

部署過程非常順利。

它會一直運作下去。

這種語言賦予你：

• 一個簡單的並發模型

• 強大的標準庫

• 可預測的結構

• 小型靜態二進位文件

AWS 為您提供：

• 無限容量（理論上）

• 一切都安排妥當了。

• 自動縮放

• 警報器只有在為時已晚時才會響起

它們共同營造出一種強大的幻象：

“這套系統之所以高效，是因為它很簡單。”

早期，這種錯覺大多是正確的。

為什麼 Go 語言在雲端後端領域佔據主導地位（而且實至名歸）

公平地說，Go 成為雲端平台的預設語言絕非偶然。

1. 開發人員吞吐量至關重要

Go 可以最大限度地減少決策疲勞：

• 一種格式樣式

• 一個依賴系統

• 實現並發的一種方法是

• 一個明顯的部署工件

你不會花幾週時間爭論架構設計，直接發布產品就行了。

在雲端環境中，上線時間往往比微優化更重要。

2. 冷啟動很友好

與基於 JVM 的技術堆疊相比，Go 二進位檔案：

• 快速啟動

• 載入最小執行時狀態

• 與 Lambda 和容器自動擴縮容良好配合

單憑這一點，Go 就足以成為 AWS 的首選。

3. 執行可預測性

大多數 Go 服務都以乏味的方式失敗：

• 恐慌顯而易見

• 記憶體使用情況基本穩定。

• 績效斷崖式下跌是漸進的。

這樣一來，輪班待命製度就變得可以承受了。

所以，Go 配得上它的地位。

慢燃效應：當「夠好」開始讓你付出代價

關於雲端系統，有以下幾點要注意：

他們不會立即懲罰效率低下的行為。

相反，他們悄悄地進行著：

• 這裡 CPU 使用率 +10%。

• 那裡有+200MB內存

• 再舉一個例子，「以防萬一」。

• 更大的任務規模，因為「這樣比較安全」。

沒有哪一項決定是令人憤慨的。

它們共同作用，會形成複合體。

您的AWS帳單不會飆升。

它悄悄地爬。

而悄悄增加的成本最難應付——因為表面上看不出有什麼問題。

垃圾收集：你看不見的稅，直到你真正需要它的時候才會發現。

Go 的垃圾回收機制是它最偉大的成就之一。

這也是其最大的雲端運算隱患之一。

現代圍棋GC是：

• 低延遲

• 並行

• 針對大多數工作負載進行了最佳化

但「調校良好」並不意味著免費。

AWS 中的 GC 實際成本是多少？

• 額外的記憶體空間以避免壓力

• 標記清除期間的 CPU 週期

• 負載下延遲不可預測

• 降低貨櫃密度

單就這一點而言，沒問題。

從規模來看，這就變成了基礎設施政策。

你不會直接注意到垃圾回收。

你會在以下情況下注意到這一點：

• 你為了「安全起見」增加了任務記憶體。

• 避免了更緊密的實例打包

• 你的水平縮放比預期要早。

AWS 並不在乎你為什麼需要更多資源。

它只是負責開立發票。

當鏽蝕出現時（並非出於自願）

我並非某天起床突然想到：

“我應該用 Rust 重寫一下，純粹是為了好玩。”

當 Go 不再默默無聞時，Rust 就出現了。

特定的工作負載導致了這個問題：

• 高吞吐量攝取服務

• 流式管道

• 即時資料處理

• 熱點路徑每秒執行數百萬次操作

這些服務並非業務邏輯密集型服務。

它們是物理密集型服務。

正是從那時開始，圍棋開始出現摩擦。

Rust 預設並非更快（這是謊言）

讓我們現在來破除一個迷思：

Rust 並不能神奇地讓你的系統運作速度變快。

它的作用是消除藉口。

Rust 迫使你面對：

• 分配模式

• 所有權邊界

• 記憶體佈局

• 快取行為

• 線程通信

在 Go 語言中，你可以長時間忽略這些事情。

在 Rust 中，這是不可能做到的。

這就是關鍵所在。

第一次鏽蝕服務糟透了

說實話。

我的第一個 Rust 微服務：

• 寫作時間延長了3倍

• 編譯器錯誤比實際程式碼還多

• 這讓我開始反思自己的人生選擇。

但是一旦它執行起來……就發生了奇怪的事情。

這些指標很無聊

• 記憶體使用情況

• 穩定的延遲

• CPU 位置完全符合預期

• 負載下未出現意外

該服務表現得像一個實體物件。

可預測的。可衡量的。誠實的。

Rust 改變了你設計雲端系統的方式

Rust 不僅僅是修改程式碼。

它改變了建築結構。

1. 停止過度分配「以防萬一」的資源

因為分配是明確的，所以你：

• 重複使用緩衝區

• 串流資料

• 以世代為單位思考，而不是以數量為單位思考。

這直接減少了記憶體佔用。

2. 設計時要考慮資料流，而不是便利性

Rust 會引導你走向：

• 明確的所有權邊界

• 預設情況下不可更改的資料

• 顯性突變點

這有助於形成更簡單的並發思考模型。

3. 先進行垂直縮放，再進行水平縮放

當服務有效率時，您可以：

• 每個實例可以打包更多工作負載

• 延遲自動縮放

• 減少跨服務通信

AWS定價注重垂直整合效率。

AWS 視角：語言選擇的影響

事情到這裡變得令人不安地具體起來了。

EC2

• Rust 服務在較小的實例類型上也能流暢運作。

• Go 服務需要更多記憶體餘裕

• 快取效率比原始核心數更重要

ECS/EKS

• Rust 提高了容器密度

• 更少的記憶體溢出死亡

• 更可預測的自動擴縮容行為

Lambda

• 鏽蝕冷啟動性能始終較低

• 記憶體與效能比更好

• 降低 CPU 密集型功能的成本

單憑基準測試無法反映這些特點。

它出現在每月的發票上。

混合實境：別再把這看成是圍棋與Rust之爭

這不是語言之爭。

這是一個資源分配問題。

真正奏效的是精心設計的語言運用。

Go 語言仍然非常適合

• 蜜蜂

• 控制平面

• 行政服務

• 膠水程式碼

• 原型製作

• 業務邏輯

Rust 更適合

• 資料管道

• 高吞吐量服務

• 延遲敏感元件

• CPU密集型工作負載

• 邊緣服務

AWS 並不在乎你喜歡哪種語言。

它很在意你如何有效率地利用矽。

可觀察性最終會揭示真相

當 Go 和 Rust 服務並排執行後，可觀測性就不再是抽象的概念了。

指標使這些差異顯而易見：

• 記憶曲線

• 尾延遲

• CPU飽和度

• 縮放行為

這些系統之間不存在競爭關係。

它們揭示了權衡取捨。

真正的教訓：語言編碼價值觀

Go 值：

• 簡單

• 發展速度

• 團隊可擴展性

Rust 價值觀：

• 正確性

• 明確性

• 長期效率

AWS 值：

• 使用率

• 可預測性

• 你沒有問有關價格的問題。

選擇一種語言，就是選擇你想為哪些價值觀付費。

為什麼規模擴大後這一點變得更重要

早期團隊絕對應該優先考慮速度。

去那裡玩很棒。

但隨著系統日趨成熟：

• 利潤率收緊

• 負荷增加

• 法案不再只是理論。

那時效率就不再是「過早優化」了。

並開始進行基礎設施衛生工作。

結論：雲是一台誠信機器

雲端並不在意美觀。

它不在乎潮流。

它不在乎你喜歡用什麼語言。

它測量的是：

• CPU週期

• 記憶體使用情況

• 網路流量

• 時間

然後它會按此收費。

Go 能幫助你快速行動。

Rust 可以幫助您了解成本。

AWS 會確保您了解其中的差異。

原文出處：Go Made Me Fast, Rust Made Me Care, AWS Made Me Pay