1. 项目背景与挑战
去年接手公司核心返利业务系统时，我们正面临一场完美风暴。这个日活300万+的电商导购平台，在618大促期间频繁出现服务不可用告警，最严重时核心接口响应时间突破8秒，订单流失率高达15%。技术债堆积的单体架构就像定时炸弹，随时可能把业务增长炸得粉碎。
当时系统的主要痛点集中在三个维度：
- 性能瓶颈：所有服务共用MySQL主库，高峰时段CPU持续100%
- 扩展困难：代码耦合度高，新功能上线平均需要2周回归测试
- 运维风险：任何模块的BUG都可能引发全站雪崩
2. 架构演进路线图
2.1 解耦阶段（0-3个月）
我们首先用"绞杀者模式"逐步拆分单体应用：
- 将用户资产服务独立为微服务
- 采用Spring Cloud + Docker组合
- 关键配置：Hystrix超时设为800ms
- 数据迁移方案：先双写，再通过canal同步历史数据
踩坑实录：初期未设置合理的线程池大小，导致下游服务抖动引发级联故障。最终通过Hystrix线程池隔离解决。
2.2 服务治理（3-6个月）
引入全套云原生技术栈：
- 服务网格：Istio 1.9实现全链路灰度
- 可观测性：Prometheus+Grafana监控体系
- 关键指标：JVM Full GC次数、Redis慢查询
- 配置中心：Nacos动态配置推送
# Istio虚拟服务配置示例 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reward-service spec: hosts: - reward.prod.svc.cluster.local http: - route: - destination: host: reward.prod.svc.cluster.local subset: v1 weight: 90 - destination: host: reward.prod.svc.cluster.local subset: v2 weight: 102.3 流量治理（6-9个月）
实现百万QPS下的稳定保障：
多级缓存架构
- L1：本地Caffeine（最大5000条目）
- L2：Redis集群（32分片）
- 缓存击穿防护：BloomFilter+互斥锁
智能限流策略
- 基于Sentinel的阶梯式限流
- 用户维度令牌桶算法
3. 关键优化案例
3.1 订单分库分表方案
采用ShardingSphere实现水平分片：
- 分片键：user_id后4位mod16
- 索引优化：建立(user_id,create_time)联合索引
- 迁移方案：通过DataX全量+canal增量同步
| 分片策略 | 优点 | 缺点 |
|---|---|---|
| 用户维度 | 查询效率高 | 热点用户问题 |
| 时间维度 | 易于归档 | 跨年查询复杂 |
3.2 实时返利计算引擎
基于Flink构建的流式计算管道：
// 关键处理逻辑 DataStream<OrderEvent> stream = env .addSource(new KafkaSource()) .keyBy("userId") .window(TumblingProcessingTimeWindows.of(Time.minutes(5))) .process(new RewardCalculator());性能优化点：
- 开启Native Kubernetes部署
- 设置合理的operator chain
- 状态后端选用RocksDB
4. 稳定性保障体系
4.1 全链路压测方案
- 影子库策略
- 数据库：通过中间件路由
- Redis：key前缀隔离
- 流量录制回放
- 使用GoReplay捕获生产流量
- 按200%倍速回放
4.2 混沌工程实践
每周例行故障演练：
- 网络延迟：500ms抖动持续30秒
- 节点故障：随机kill 10%的pod
- 依赖降级：模拟第三方API超时
5. 演进成果
经过12个月的持续迭代，系统关键指标显著提升：
- 平均响应时间：1800ms → 220ms
- 部署频率：每月1次 → 每日20+次
- 故障恢复时间：小时级 → 分钟级
最让我自豪的是去年双11大促期间，系统平稳支撑了峰值45000 TPS的流量冲击，零重大故障。这背后是超过200次的架构评审会议和37个版本的迭代优化。
