🔧 阿川の電商水電行
當我們第一次將單體應用程式拆分成微服務時，感覺就像取得了一場勝利。
更小的服務。獨立部署。清晰的邊界。我們甚至畫了一張有方框和箭頭的圖表，讓我們感覺自己像Netflix的工程師。
然後生產流量就來了。
服務擴展性良好。
Kubernetes 很滿意。
自動縮放功能完全符合宣傳效果。
資料庫徹底崩潰了。
起初，我們把一切都歸咎於顯而易見的原因。
“或許我們需要更多複製品。”
“讓我們擴大連接池。”
“Postgres 的可擴展性遠不如 NoSQL。”
但真相更簡單，也更令人不安：
我們的微服務本身沒有問題。
我們共享的資料庫是。
微服務讓擴充看起來很容易（直到它並非如此）
微服務傳遞了一個極具誘惑力的理念：系統的每個部分都可以獨立擴展。理論上，這確實能夠實現。
實際上，大多數團隊都是這樣做的：
-
將應用程式拆分為 10-20 個服務
-
將它們全部指向同一個資料庫
-
不妨稱為「微服務架構」。
恭喜。
你剛剛建立了一個具有網路延遲的分散式單體應用。
每個服務都可以橫向擴展，但所有服務的流量最終都會匯聚到同一個瓶頸。當負載增加時，資料庫看到的不是“微服務”，而是一片混亂。
更多聯繫
更多並發查詢
更多鎖
更多爭議
資料庫並不會因為你的服務橫向擴展而隨之擴展，它只會發出更大的壓力。
「再多查詢一次」的隱性成本
最初的問題表現為延遲峰值。
沒有錯誤，沒有崩潰，只是請求速度越來越慢……越來越慢……越來越慢。
事情的真相是這樣的：
-
服務 A 新增了一個端點 → +3 次查詢
-
服務 B 新增了「僅連接」→ +2 個查詢
-
服務 C 開始每 5 秒輪詢一次 → 糟糕
-
讀取副本數量落後於寫入數量。
-
連線池已滿
-
在一些無人監管的地方，鎖具堆積如山。
單獨來看，這些變化似乎都不危險。
他們共同將資料庫改造成了共享的創傷中心。
這就是微服務的陷阱：局部決策，全局影響。
擴展服務加劇資料庫痛苦
接下來這部分內容讓團隊裡的新工程師感到驚訝。
將服務從 2 個 Pod 擴展到 20 個 Pod 不僅會倍增吞吐量，它還會倍增：
-
開放連接
-
閒置交易
-
並發寫入
-
快取未命中
-
鎖爭
資料庫無法辨識這些進程屬於同一服務，而是將它們視為18個陌生的、咄咄逼人的進程，試圖引起使用者的注意。
因此，雖然您的儀錶板顯示：
“服務延遲看起來沒問題！”
資料庫這邊正在思考：
“你們為什麼這麼多人？”
為什麼「加入快取」通常不夠？
這時總是會有人建議快取。
沒錯，快取確實有幫助。
但這並不能解決根本問題。
大多數球隊還會增加：
-
用於讀取的 Redis
-
或許需要一些 HTTP 快取。
-
他們情感上選擇的TTL
現在系統運作速度更快了…直到它不再運作為止。
為什麼？
因為：
-
寫入操作仍然會存取同一個資料庫。
-
快取失效很快就會變得很混亂。
-
跨服務資料一致性變成了一場猜謎遊戲
-
你增加了操作複雜性，卻沒有消除耦合性。
緩存就像止痛藥。
資料庫問題是結構性的。
真正的問題：資料的共享所有權
我恍然大悟的那一刻是意識到這一點：
我們當時還沒有微服務架構。
我們之前有過微服務共享相同狀態的情況。
這違背了該架構的核心承諾。
當提供多種服務時：
-
讀取相同的表格
-
寫入同一行
-
依賴相同的交易
它們不再是獨立的。它們透過資料庫緊密耦合在一起，只是這種耦合方式更隱蔽，也更難除錯。
您的服務可以獨立部署。
您的資料無法存取。
哪些方法真正有效（哪些無效）
以下方法並未解決問題：
-
更大的資料庫實例
-
更多複製品
-
更高的連線限制
-
在站會上大喊“優化查詢”
以下方法確實有效：
-
明確的資料所有權
每個服務都擁有自己的資料。就這麼簡單。
如果其他服務需要：
-
它呼叫了一個API
-
或消耗一個事件
-
或從專門建立的讀取模型中讀取資料
別搞什麼「跨服務合併」這種事。那樣的話，又要開始抱怨了。
-
跨服務交易減少
分散式交易看起來很優雅，直到你真正嘗試操作它們時才會發現問題。
我們將同步依賴項替換為：
-
活動
-
非同步工作流程
-
最終一致性更新
並非所有事情都需要即時完成。大多數系統只需要可靠即可。
-
資料庫載入優先設計
我們不再問了：
這項服務可以規模化嗎？
然後開始問：
“流量增加 10 倍會對資料庫造成什麼影響？”
那一個問題徹底改變了建築設計評審的方式。
-
接受微服務是一種權衡取捨
微服務並不會自動帶來可擴充性。它們提供的是選擇——但代價是缺乏自律。
如果沒有嚴格的界限，它們只會加劇資料庫問題，而不是解決問題。
慘痛的教訓
微服務沒有讓我們失望。
我們的資料庫設計做到了。
我們早期為了追求開發速度而優化，結果後期卻為此付出了維運上的代價。這並非錯誤，而是一種權衡。真正的錯誤在於，我們以為微服務能夠神奇地消除擴展限制。
他們不。
他們把這些限制轉移到不太顯眼的地方。
通常會匯入到您的資料庫中。
最後想說的話
如果你的系統每次流量增加時都會變慢，不要只檢查你的服務。
請看：
-
資料所有者是誰
-
有多少服務會接觸到同一張桌子
-
擴展 Pod 如何倍增資料庫負載
-
你的建築設計是否與你的交通模式相匹配
因為十有八九，「微服務無法擴展」…
確實如此。
你的資料庫簡直快要崩潰了。
原文出處：https://dev.to/art_light/your-microservices-arent-scalable-your-database-is-just-crying-mbd
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
