15個團隊寫出15套ORM：微服務自治神話的代價

去年Q3，某頭部云廠商的SRE團隊做過一次內部審計：127個微服務，用了23種不同的數據庫連接池配置，17種事務超時策略，以及9種完全不同的故障重試邏輯。沒人故意搞分裂，這只是"數據庫獨立"原則執行了3年的自然結果。

問題不是微服務錯了，是治理缺位。

每個服務擁有獨立數據存儲，理論上很干凈。實際運行中，連接管理、ORM配置、安全加固、查詢容錯——這些通用能力被重復造了無數次輪子。一個全局安全補丁要改幾十個代碼庫，每個都有自己的"方言"。

共享代碼庫是直覺解法，但只能解決編譯時標準化。運行時呢？每個服務仍獨立管理數據庫實例、憑證、schema遷移。你需要的是運行時層，而非僅編譯時層。

這里有個被忽視的參照系：多租戶架構。

多租戶的三種隔離策略，恰好對應微服務的治理光譜

多租戶系統的核心矛盾與微服務完全一致：最大化資源共享，同時強制數據邊界。三種經典策略提供了不同的取舍坐標。

數據庫級隔離（Database-per-tenant）為每個租戶獨立部署數據庫。物理隔離最徹底，schema遷移互不影響，可按負載分散到不同服務器。代價隨租戶數線性膨脹——運維復雜度、監控盲區、備份窗口的碎片化。

Schema級隔離（Schema-per-tenant）把租戶塞進同一數據庫服務器，但數據分屬不同schema。基礎設施開銷降低，但資源競爭成為單點故障模式：一個租戶的慢查詢能占滿連接池，餓死其他租戶。

行級隔離（Discriminator column）走到共享極端——所有租戶數據混在同一表，用tenant_id字段區分。資源效率最高，schema變更最簡單，但數據泄露的 blast radius 也最大。一條漏掉的WHERE條件就能跨租戶。

微服務的"數據庫獨立"原則，本質上選擇了數據庫級隔離的極端。當服務數從10個膨脹到100個，運維面爆炸的問題與多租戶廠商面對萬級租戶時的困境同構。

共享持久化層的運行時治理：不是能不能，而是劃多少

Netflix在2018年公開的EVCache演進路徑是個具體案例。他們從每個服務自建緩存集群，逐步收斂到共享的、由專門SRE團隊運營的持久化層。關鍵轉折不是技術選型，是治理邊界的重新談判：哪些決策可以集中，哪些必須保留給服務團隊。

共享持久化層的可行形態有幾種。最輕量的是托管式數據庫服務（RDS/Aurora/Cloud SQL），把實例生命周期、備份、補丁外包給云廠商，但schema和查詢仍由服務團隊自治。中等程度是內部平臺團隊運營的"數據庫即服務"，統一連接池、監控、慢查詢告警，但schema遷移仍分散。最重的是類似Google Spanner或CockroachDB的多租戶集群，服務只看見邏輯數據庫，物理拓撲完全隱藏。

每種形態都在回答同一個問題：自治的邊界畫在哪里？

Uber的Docstore團隊2021年的技術博客披露過一個細節：他們在共享文檔存儲層中保留了"物理隔離選項"——關鍵業務可以申請獨立集群，代價是多付3倍成本。這個設計把選擇權交還業務團隊，同時用價格信號引導理性決策。

更隱蔽的權衡在查詢語言層面。統一持久化層往往意味著查詢能力的受限——不是每個團隊都能隨意CREATE INDEX，不是每個復雜JOIN都被允許。Spanner的TrueTime和全局一致性是有代價的：事務延遲、特定查詢模式的禁用、對分區鍵設計的強制要求。

從"重復造輪子"到"有約束的復用"：治理即產品

回到開頭那個127個微服務的案例。該云廠商最終的解法不是推倒重來，而是把"持久化能力"拆成三層產品化。

第一層是強制共享的：連接池管理、憑證輪換、基礎監控。這些不提供差異化價值，重復建設是純浪費。第二層是可選共享的：ORM擴展、緩存策略、分庫分表中間件。團隊可以接入，也可以自建，但接入有顯著成本優勢。第三層是嚴格自治的：schema設計、查詢優化、特定業務的事務語義。

這個分層不是技術決策，是組織決策。平臺團隊需要像產品經理一樣運營：明確SLA、定價模型、升級節奏，以及——最關鍵的——退出機制。如果業務團隊覺得某層約束過強，必須有清晰的申訴和替代路徑。

AWS RDS Proxy的設計哲學值得玩味。它不提供查詢改寫或ORM功能，只做連接池管理和故障轉移——恰恰是那個"重復造輪子"最嚴重、卻最不產生業務價值的交集地帶。更深層的查詢優化、schema變更，RDS Proxy完全不碰，留給服務團隊或更上層的中間件。

這種克制很重要。共享持久化層的失敗模式往往是過度承諾：一開始只解決連接管理，逐漸膨脹成"所有數據問題的答案"，最終成為新的瓶頸和怨恨焦點。

Stripe的API設計有個相關原則：每個端點的文檔必須明確說明"什么情況下會失敗"。共享持久化層的運營團隊需要類似的透明度——不是宣傳"我們解決了所有問題"，而是清晰列出約束清單：最大連接數、允許的最長事務、不支持的操作類型、升級窗口的強制停機時間。

自治不是目的，是手段。微服務的價值在于團隊可以獨立演進，而非必須獨立演進。當15個團隊寫出15套ORM配置時，真正的損失不是代碼重復，是認知負荷的分散——沒人能完整理解系統的數據面，故障排查變成跨團隊的猜謎游戲。

多租戶架構的三種隔離策略提供了有用的思維框架，但沒有標準答案。數據庫級隔離的極端自治，行級隔離的極端效率，都是可選項，關鍵是顯式選擇而非被動 drift 到某種狀態。

那個127個微服務的云廠商，在審計報告的最后一頁寫了句備注：下次架構評審，我們要問的不是"這個服務需要獨立數據庫嗎"，而是"這個服務愿意為獨立數據庫多付多少運維成本，以及誰來做這個預算決策"。

你的組織現在有多少種數據庫連接配置？最近一次統計是什么時候做的？