凌晨兩點，我決定殺死那個單體應用

凌晨兩點，第三杯咖啡已經(jīng)涼透。終端窗口卡在那里，看起來像在干活，實際上一動不動。

我們的架構給每個客戶單獨分配數(shù)據(jù)庫空間（schema）。理論上，數(shù)據(jù)隔離完美無缺。現(xiàn)實是管理噩夢。第401個客戶的數(shù)據(jù)庫在一次簡單更新時死鎖，整個系統(tǒng)停擺。那一刻沒有頓悟，只有一個清醒的認知：這套系統(tǒng)遲早會拖垮我們。

于是我們決定逃離單體應用。這是全過程，以及踩過的坑。

原版應用用Python和Django搭建。我喜歡Django，但撞到了天花板。Python有個內(nèi)置限制——全局解釋器鎖（GIL）——決定了它能同時干多少件事。簡單應用無感知，但我們有幾百人同時聊天、同步文件、調用API，就像用吸管跑馬拉松。

我們試過砸錢：更大的服務器，更強的配置。短期有效，沒解決根本問題。

最致命的是耦合。應用某個角落的慢查詢，能讓登錄頁面卡成PPT。單體架構里，廚房一點火星，最終濃煙灌滿整棟房子。當你知道一個小bug就能干掉全部，睡眠質量會顯著惡化。

我們轉向Java 21。核心原因是一個新特性：虛擬線程（Virtual Threads）。

在此之前，Java處理并發(fā)靠線程池——預分配固定數(shù)量的工作線程，祈禱流量別超標。線程等著數(shù)據(jù)庫響應或API返回時，就干耗內(nèi)存、什么都不干。高負載下，連接超時比CPU耗盡來得更早。

虛擬線程改變了游戲規(guī)則。JVM能啟動數(shù)百萬條輕量級虛擬線程，I/O等待時自動掛起和恢復。關鍵是寫普通阻塞代碼就行——不用給每個函數(shù)標記async/await，像病毒一樣蔓延。相當于從四車道直接擴到一千車道，還不用改駕駛習慣。

我們從凌晨一點盯著服務器上限，變成……完全不用想這事。這才是真正的勝利。

遷移分三步走。

第一步，身份清理。我們不再讓每個模塊操心"用戶是誰"。這件事挪到網(wǎng)關（Gateway）統(tǒng)一處理。網(wǎng)關一次性校驗用戶密鑰，給請求打個標簽（比如"這是A客戶"），然后放行。請求到達業(yè)務代碼時，"這是誰"已經(jīng)解決。整體響應明顯變快。

第二步，一張大表，更好的組織方式。我們干掉了"每個客戶一個schema"的設計。