🔧 阿川の電商水電行
多年來，我的雲端架構一直感覺……還算合理。
-
Go 服務
-
AWS 基礎設施
-
到處都是貨櫃
-
上面撒了一些Lambda
-
儀錶板大部分為綠色
部署速度很快，工程師們工作效率很高，沒有人抱怨。
現在回想起來，這應該是我的第一個警示訊號。
因為在雲端，系統通常不會發生明顯的故障。
它們在財務上失敗了。
舒適階段：當 Go + AWS 感覺像超能力一樣強大
Go遊戲有一種危險的魔力，它能讓人感覺一切都在掌控之中。
你寫一個服務。
它能立即編譯。
部署過程非常順利。
它會一直運作下去。
這種語言賦予你：
-
一個簡單的並發模型
-
強大的標準庫
-
可預測的結構
-
小型靜態二進位文件
AWS 為您提供：
-
無限容量（理論上）
-
一切都安排妥當了。
-
自動縮放
-
警報器只有在為時已晚時才會響起
它們共同營造出一種強大的幻象：
“這套系統之所以高效，是因為它很簡單。”
早期，這種錯覺大多是正確的。
為什麼 Go 語言在雲端後端領域佔據主導地位（而且實至名歸）
公平地說，Go 成為雲端平台的預設語言絕非偶然。
1. 開發人員吞吐量至關重要
Go 可以最大限度地減少決策疲勞：
-
一種格式樣式
-
一個依賴系統
-
實現並發的一種方法是
-
一個明顯的部署工件
你不會花幾週時間爭論架構設計，直接發布產品就行了。
在雲端環境中，上線時間往往比微優化更重要。
2. 冷啟動很友好
與基於 JVM 的技術堆疊相比，Go 二進位檔案：
-
快速啟動
-
載入最小執行時狀態
-
與 Lambda 和容器自動擴縮容良好配合
單憑這一點，Go 就足以成為 AWS 的首選。
3. 執行可預測性
大多數 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 Shines at:
-
資料管道
-
高吞吐量服務
-
延遲敏感元件
-
CPU密集型工作負載
-
邊緣服務
AWS 並不在乎你喜歡哪種語言。
它很在意你如何有效率地利用矽。
可觀察性最終會揭示真相
當 Go 和 Rust 服務並排執行後，可觀測性就不再是抽象的概念了。
指標使這些差異顯而易見：
-
記憶曲線
-
尾延遲
-
CPU飽和度
-
縮放行為
這些系統之間不存在競爭關係。
它們揭示了權衡取捨。
真正的教訓：語言編碼價值觀
Go 值：
-
簡單
-
發展速度
-
團隊可擴展性
Rust 價值觀：
-
正確性
-
明確性
-
長期效率
AWS 值：
-
使用率
-
可預測性
-
你沒有問有關價格的問題。
選擇一種語言，就是選擇你想為哪些價值觀付費。
為什麼規模擴大後這一點變得更重要
早期團隊絕對應該優先考慮速度。
去那裡玩很棒。
但隨著系統日趨成熟：
-
利潤率收緊
-
負荷增加
-
法案不再只是理論。
那時效率就不再是「過早優化」了。
並開始進行基礎設施衛生工作。
結論：雲是一台誠信機器
雲端並不在意美觀。
它不在乎潮流。
它不在乎你喜歡用什麼語言。
它測量的是：
-
CPU週期
-
記憶體使用情況
-
網路流量
-
時間
然後它會按此收費。
Go 能幫助你快速行動。
Rust 可以幫助您了解成本。
AWS 會確保您了解其中的差異。
原文出處：https://dev.to/art_light/go-made-me-fast-rust-made-me-care-aws-made-me-pay-2f82
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
