Scaling a Monolith to 1M LOC
Performance (性能优化)
- 分页计数是性能杀手: 精确的"总页数"在大规模下很难，需要扫描大量行
- 长 Cron 任务能瘫痪系统: 报表用的低效查询能让整体性能降 50%
- RAM 压力被低估: 内存不足会 swap 到磁盘，系统变慢但不崩溃
- 后台任务很有效: 邮件、推送、WebSocket、webhook 处理都应异步
- 树形数据结构: 分类等层级数据可用内存缓存替代数据库自连接
- 设置超时: 防止单点故障耗尽所有线程导致崩溃
- 定期重启 Worker: 防止内存泄漏，每 10000 请求重启
- 前端性能常见问题: 表单重复渲染、DOM 元素过多、useEffect 滥用
- ORDER BY id 而非 created: id 字段自带索引
- 删除无用数据: 十年堆积的数据严重影响查询性能
Human (团队与人效)
- 全员应成为全栈: FE/BE/ops 分工导致协调成本高
- 不要责备个人: 生产问题通常是至少 3 个 cascade failure
- 建立员工期望文档: 明确什么是"好工作"，员工无法读心
- Tech Debt 周五: 周一至四做功能，周五做维护和技术债务
- Linters 改善结果: 防止 review 被格式问题分散注意力
- 防止 Long PRs: 大特性应拆解，每天或每周合并
- 远程公司要多聊天: 主动提问、展示代码、鼓励互相通话
- 用户投票功能需求: 让用户决定他们想要什么
- 一次只做一个重大改变: 变革太多团队无法适应
- 关键系统至少两人精通: 知识不能只存在一个人脑子里
Monitoring (监控)
- 监控即代码: 确保告警系统本身被测试
- 监控 Worker 队列积压: 慢查询会让队列阻塞数小时
- Sentry 清零: 达到此目标后团队才会认真对待每个异常
- 监控邮件/推送送达率: 大量用户会遇到送达问题
- Dead Man Switch: 监控"某事没发生"比监控"某事发生"更重要
- N+1 是最大性能风险: ORM 使用中最常见的性能问题
- 请求队列是关键指标: 平均应小于 2ms
- 给 DB 连接打标签: 方便在 pg_stat_activity 中追踪
- 生产日志需要好 UX: 可搜索、可图形化、可 CLI
- Top 20 端点设置性能回归告警：性能问题是渐进式的
💡 核心洞见: 单体扩展不仅是技术问题，更是人效和管理问题。113 条经验来自 20 人团队、Django/React 代码库、100 万行代码的实战总结。
标签: scaling, performance, django, react, management, monitoring
探索来源: lobsters (scaling, performance, python, debugging, practices)