凌晨两点，我决定杀死那个单体应用

凌晨两点，第三杯咖啡已经凉透。终端窗口卡在那里，看起来像在干活，实际上一动不动。

我们的架构给每个客户单独分配数据库空间（schema）。理论上，数据隔离完美无缺。现实是管理噩梦。第401个客户的数据库在一次简单更新时死锁，整个系统停摆。那一刻没有顿悟，只有一个清醒的认知：这套系统迟早会拖垮我们。

于是我们决定逃离单体应用。这是全过程，以及踩过的坑。

原版应用用Python和Django搭建。我喜欢Django，但撞到了天花板。Python有个内置限制——全局解释器锁（GIL）——决定了它能同时干多少件事。简单应用无感知，但我们有几百人同时聊天、同步文件、调用API，就像用吸管跑马拉松。

我们试过砸钱：更大的服务器，更强的配置。短期有效，没解决根本问题。

最致命的是耦合。应用某个角落的慢查询，能让登录页面卡成PPT。单体架构里，厨房一点火星，最终浓烟灌满整栋房子。当你知道一个小bug就能干掉全部，睡眠质量会显著恶化。

我们转向Java 21。核心原因是一个新特性：虚拟线程（Virtual Threads）。

在此之前，Java处理并发靠线程池——预分配固定数量的工作线程，祈祷流量别超标。线程等着数据库响应或API返回时，就干耗内存、什么都不干。高负载下，连接超时比CPU耗尽来得更早。

虚拟线程改变了游戏规则。JVM能启动数百万条轻量级虚拟线程，I/O等待时自动挂起和恢复。关键是写普通阻塞代码就行——不用给每个函数标记async/await，像病毒一样蔓延。相当于从四车道直接扩到一千车道，还不用改驾驶习惯。

我们从凌晨一点盯着服务器上限，变成……完全不用想这事。这才是真正的胜利。

迁移分三步走。

第一步，身份清理。我们不再让每个模块操心"用户是谁"。这件事挪到网关（Gateway）统一处理。网关一次性校验用户密钥，给请求打个标签（比如"这是A客户"），然后放行。请求到达业务代码时，"这是谁"已经解决。整体响应明显变快。

第二步，一张大表，更好的组织方式。我们干掉了"每个客户一个schema"的设计。