从单机到分布式：网站架构演进与高可用实践

1. 从单机到分布式：网站架构演进的必然性

十年前我刚入行时参与维护的电商网站，所有功能都跑在一台4核8G的服务器上。随着日均订单量从100单增长到10万单，我们经历了完整的架构演进历程。这种演进不是技术人员的炫技，而是业务发展倒逼的技术升级。

当单机遇到性能瓶颈时，首当其冲的是数据库。我清楚地记得某个促销日凌晨，MySQL的CPU利用率突然飙升到98%，整个下单接口响应时间从200ms恶化到15秒。这时垂直拆分（Vertical Scaling）就成了救命稻草——把用户、商品、订单三个最繁忙的表分别迁移到独立的数据库实例，配合应用层代码改造，硬是把系统从崩溃边缘拉了回来。

但垂直拆分只是权宜之计。当商品库的单表数据突破500万行时，简单的SQL查询都要扫描几十万行数据。这时候就需要水平拆分（Horizontal Sharding），我们按照商品类目ID的哈希值将数据分布到8个物理节点，查询性能立即提升了6倍。不过分库分表也带来了分布式事务的难题，最终我们通过"最终一致性+补偿机制"的方案解决了订单状态同步问题。

关键转折点：当单机QPS超过2000或单表数据量超过500万行时，就该认真考虑分布式架构了

2. 服务化拆分的艺术与实践

2.1 单体架构的痛点实录

2016年我们重构的社交平台项目，代码库膨胀到120万行Java代码。每次发版需要全量回归测试，上线窗口长达4小时。更可怕的是某个缓存组件的BUG导致全站不可用——这就是典型的"牵一发而动全身"。

服务化拆分的第一步是确定边界。我们根据业务域划分了用户中心、内容服务、关系链等核心服务。这里有个重要经验：先按业务能力划分，再考虑技术特性。比如将短信、邮件等通知功能统一归入通知服务，而不是每个业务模块自己实现。

2.2 分布式系统的关键设计

服务化之后，我们踩过几个典型的坑：

1. 循环依赖：用户服务调用订单服务，订单服务又回调用户服务。解决方案是引入DTO对象和消息队列
2. 分布式事务：采用TCC模式处理跨服务转账，补偿机制要记录完整操作日志
3. 链路追踪：每个请求的traceId要穿透所有服务，我们基于Zipkin实现了调用链可视化

服务通信选用Dubbo框架而非Spring Cloud，主要考虑当时团队对RPC更熟悉。接口定义遵循"三不原则"：不超过