2026年2月8日Evgeny · 高级系统工程师
HighLoad 架构：从单体到微服务
所有伟大的项目都是从单体开始的。但有一天你醒来发现：部署需要一个小时，任何修补都会破坏半个网站，数据库在乞求怜悯。欢迎来到 HighLoad 的世界。
“胖单体”综合症
单体在开始时很方便。但随着负载的增加，它变成了瓶颈。
- 扩展困难： 为了加速一个模块，你需要复制整个巨大的服务器。
- 单点故障： “通讯”模块中的错误可能会导致“支付”崩溃。
第 1 步：Highload 系统开发
过渡到微服务不仅仅是更改代码，而是改变思维方式。Highload 系统开发需要明确的职责分离。
Monolith: User -> [App (Auth + Billing + Catalog)] -> DB
Microservices:
User -> [API Gateway]
-> [Auth Service] -> DB1
-> [Billing Service] -> DB2
-> [Catalog Service] -> DB3
高负载系统架构：主要原则
- 异步性： 服务不应该互相等待。使用队列 (RabbitMQ, Kafka)。用户点击“购买” -> 我们回复“OK”并将任务放入队列。
- 数据隔离： 每个服务都有自己的数据库。不能直接访问别人的数据库，只能通过 API。
- 容错性： 即使一个服务宕机，系统也必须工作 (优雅降级)。
风险和陷阱
微服务很复杂。你需要强大的 DevOps、Kubernetes (k8s) 和分布式追踪 (Jaeger)。不要为了炒作而实施它们。
结论： 拆分单体是外科手术。只有当病人真的长大了，穿不下旧衣服时才做。
主题常见问题
流量形态与数据往往与生产不一致。需要场景、与线上一致的指标，以及可回滚的逐步加压。
常见瓶颈在数据库与执行计划、连接池、同步外部调用与队列——可作为快速排查清单。
不一定：失效、冷启动与热点键可能适得其反。缓存要按读模型与 SLO 设计。
垂直扩展与查询优化触顶，且数据增长在分片键上可预期时。