2026年2月8日

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)。不要为了炒作而实施它们。

结论： 拆分单体是外科手术。只有当病人真的长大了，穿不下旧衣服时才做。