沒想到！一個不起眼的架構優(yōu)化，節(jié)省了超1000萬美元云成本……
這不是一個關于花哨的機器學習或億級用戶規(guī)模的故事。
這是一個關于某個架構決策的故事，它悄然無聲，幾乎不為人知，卻在三年內最終為公司節(jié)省了超過1000萬美元。
- 它并不引人注目
- 它沒有贏得獎項
- 但它改變了一切
如果你從事高流量服務的工作，如果你的數據庫賬單持續(xù)攀升，或者如果你的 Kubernetes 集群持續(xù)消耗越來越多的云積分，卻沒有明確原因……
這個故事可能會改變你對架構的思考方式。
圖片
我們基礎設施賬單無故激增的那個月
那是一個周五的下午。儀表盤亮起了紅色——不是因為服務中斷，而是因為我們當月的 AWS 費用預測比上個月暴漲了 38%。
- 我們沒有運行批量作業(yè)
- 沒有重大的產品發(fā)布
- 沒有新增區(qū)域
- 僅僅是流量略有增加
但不知何故，我們的基礎設施成本爆炸式增長了。
我收到了通常的 Slack 消息：
"有新的自動擴縮容配置嗎？"
"有人改了實例類型嗎？"
"也許只是 CloudWatch 抽風了？"
不，都不是！
我們即將通過艱難的方式，學習關于數據庫連接的昂貴一課。
連接洪泛的隱藏成本
我們的架構在紙面上看起來"沒問題"。
我們有幾十個 Spring Boot 微服務。每個服務都有自己的到 PostgreSQL 的連接池。
自動擴縮容是開啟的。流量上升，Pod 會啟動，一切都會彈性擴展。
除了……每一個新的 Pod 都會帶來 50-100 個新的數據庫連接。
而且我們在 4 個區(qū)域部署。
我們來算一下：
- 12 個微服務
- 每個服務 3 個副本
- 4 個區(qū)域
- 每個 Pod 100 個連接（默認的 Hikari 連接池大?。?/li>
這相當于對同一個數據庫集群有超過 14,000 個潛在的并發(fā)連接。
而我們的數據庫呢？
它正悄無聲息地在重壓下窒息。
我們的架構原來是這樣的：
┌─────────────┐
│ Service A ├─────────┐
└─────────────┘ │
┌─────────────┐ │
│ Service B ├────────────┐
└─────────────┘ │ │
┌─────────────┐ ▼ ▼
│ Service C ├──────? PostgreSQL
└─────────────┘ ▲ ▲
... │ │
┌─────────────┐ │ │
│ Service N ├─────────┘ │
└─────────────┘ │
Hundreds of long-lived connections每個 Pod 都是一個滴答作響的成本炸彈
理論上，連接池是高效的。
但實際上？
隨著自動擴縮容、部署、回滾以及藍綠策略——同時存在的連接數量會激增，即使流量沒有增加。
我們當時在支付：
- 我們并未使用的連接
- 數據庫內存峰值
- 更多的只讀副本
- 更大的實例
- 更高的網絡傳輸費用
我們的 PostgreSQL 集群開始靜默地故障。
延遲上升。垃圾回收活動加劇。
突然間，每個微服務看起來都像是罪魁禍首。
但真正的罪魁禍首是我們的架構。
改變一切的決策
我們沒有重寫我們的服務。
我們沒有更換數據庫。
我們沒有轉向 NoSQL 或者引入 Kafka 來"解耦"。
我們所做的一切只是引入了一個共享連接代理——PgBouncer，以事務池模式運行在我們的 Kubernetes 集群內部。
現在，每個微服務不再直接與 PostgreSQL 對話，而是與 PgBouncer 對話。
PgBouncer 復用了連接，它匯集了它們，并給了 PostgreSQL 喘息的空間。
幾乎一夜之間，我們的成本圖表變成了這樣：
┌──────────────┐
│ Service A ├──────┐
└──────────────┘ │
┌──────────────┐ ▼
│ Service B ├──? PgBouncer ──? PostgreSQL
└──────────────┘ ▲
... │
┌──────────────┐ │
│ Service N ├──────┘
└──────────────┘
Connection pooling handled outside the app為什么 PgBouncer 效果如此之好
- 它及早終止連接（事務模式意味著它一旦查詢完成就將連接返回給池。）
- 它顯著減少了打開的連接數量（從約 14,000 個減少到 < 400 個穩(wěn)定連接。）
- 它保護 PostgreSQL 免受連接風暴的沖擊（在部署或故障轉移期間不再出現峰值。）
- 它讓服務啟動更快（不再需要等待完整的連接池或數據庫握手。）
而所有這些，都是在沒有觸碰任何一行應用邏輯代碼的情況下完成的。
我們如何部署它（Spring Boot 設置示例）
從服務端來看就是這么簡單：
yaml
# application.yml (Spring Boot)
spring:
datasource:
url: jdbc:postgresql://pgbouncer-cluster:6432/mydb
username: myuser
password: ${DB_PASSWORD}
hikari:
maximum-pool-size: 20
minimum-idle: 5
idle-timeout: 30000
connection-timeout: 20000
max-lifetime: 600000注意端口號——6432。
那是 PgBouncer 的默認端口。
業(yè)務邏輯無需改變。只是把 JDBC 連接字符串指向了 PgBouncer。
我們的實際收益（沒有基準測試，只有真實結果）
我們沒有編寫合成的基準測試。
我們在上線后觀察了真實的生產指標：
- 數據庫內存使用量下降了 47%
- Pod 啟動時間減少了 22%
- 負載下的數據庫 CPU 使用率從 75% 降至 38%
- 數據庫集群規(guī)模減半（從 12 個節(jié)點減少到 6 個節(jié)點）
- 云賬單每月下降了超過 30 萬美元
將這些收益推算三年？
節(jié)省了 1080 萬美元。
沒有新的框架，沒有戲劇性的重寫，僅僅是一個小小的架構轉變。
為什么沒人談論這個
因為它很無聊。
沒有工程師想在 LinkedIn 上發(fā)帖說：
"我們添加了 PgBouncer，節(jié)省了數百萬美元。"
- 它不是"顛覆性"的
- 它不是一種新范式
- 但它是我們做過的影響最深遠的改變之一
架構并不總是關乎創(chuàng)新。有時候，它關乎消除那些甚至沒人意識到的摩擦。
你什么時候應該使用這個？
在以下情況下，你應該考慮使用 PgBouncer（或 RDS Proxy，或任何連接池代理）：
- 你運行著 10 個以上具有自動擴縮容功能的微服務
- 你的數據庫在部署期間顯示高內存或 CPU 使用率
- 你經常遇到 max_connections 錯誤
- 你支付更大的數據庫集群費用只是為了避免隨機超時
- 你的服務有時在啟動時因等待數據庫而掛起
如果你正在經歷以上任何一種情況，那你可能正在悄無聲息地浪費資金，就像我們當初一樣。
我們學到的（但沒人告訴我們的）經驗
1、默認的連接池大小是危險的
HikariCP 允許設置為 100 并不意味著你應該這么做。
2、自動擴縮容可能會破壞你的數據庫
可以擴展計算資源，但應該集中管理連接。
3、架構才是真正節(jié)省成本的地方
不是在代碼里。不是在緩存里。而是在服務之間通信的方式里。
4、沒人會因為解決看不見的問題而獲得贊譽
但看不見的問題往往是代價最高的。
為什么這個故事對我很重要
我們在代碼審查期間沒有發(fā)現這個問題。
它沒有出現在我們的單元測試中。
也沒有出現在我們的負載測試中。
也沒有出現在我們的 CI/CD 儀表盤中。
它出現在我們的財務報表上。
這就是架構變得真實的地方。
當它不再是理論——而是開始以百萬美元的條目出現時。
最后一點想法
你不需要重寫你的后端來節(jié)省數百萬美元。
你只需要審視你正在擴展的是什么——以及它是在幫助你還是在傷害你。
而如果你正在擴展的是連接數而不是吞吐量？
你可能已經在付出代價了。
你是否遇到過類似的擴展瓶頸？
你使用了 PgBouncer、RDS Proxy 還是其他方案？
歡迎留下您的評論，讓我們一同分享那些雖未收獲足夠贊譽，卻始終在幕后為我們系統(tǒng)保駕護航的故事。
作者丨The Atomic Architect 編譯丨Rio
來源丨網址：https://medium.com/@the_atomic_architect/how-one-architecture-decision-quietly-saved-us-10-million-and-nobody-noticed-until-it-was-gone-b4ddf0e0d874
