本文为脱敏案例：隐去公司与业务细节，保留架构挑战、决策与结果。仅用于展示能力证据，不泄露任何内部信息。
项目背景（脱敏）
面向 C 端的高流量业务平台，峰值流量集中在营销活动时段，具备典型的「潮汐式」特征——平时中等水位，活动期瞬间数倍爬升。
- 业务规模：日活跃用户数百万级；活动峰值 QPS 达百万级。
- 我的角色：技术负责人之一，负责核心链路架构设计、稳定性与演进。
- 技术栈：Java 服务端 + 关系库 + 缓存 + 消息队列 + 微服务治理（细节从略）。
架构挑战
- 潮汐流量：容量按峰值预留则平时浪费 70% 成本；按平时预留则活动必挂。
- 热点集中：活动流量高度集中在少数商品/内容上，缓存热点与单点问题突出。
- 链路冗长：核心下单链路跨 8+ 服务，任何一环抖动都会放大成整体不可用。
关键决策（脱敏后的取舍）
- 弹性伸缩 + 压测容量基线：建立以压测数据为基础的自动扩缩容策略，活动前预热、活动后回收，成本与稳定性的平衡点靠数据说话而非拍脑袋。
- 多级缓存 + 热点治理：进程内缓存兜底热点，逻辑过期 + 异步刷新避免雪崩（踩坑与解法详见缓存雪崩复盘）。
- 异步化拆分核心链路：把非关键路径（通知、统计、风控后置）从同步链路剥离，核心链路只保留「必须同步」的环节。
- 全链路可观测性：指标、日志、追踪贯通，故障定位时间从小时级降到分钟级（工具链见线上排障工具链）。
取得的结果（可量化部分）
- 活动期稳定支撑百万级峰值 QPS，核心链路可用性维持在 99.9%+ 级别。
- 通过弹性与容量治理，活动期基础设施成本较「按峰值预留」方案显著下降（具体数值涉密，从略）。
- 建立了可复用的稳定性体系：故障演练、容量基线、告警预案，团队新同学可独立按手册执行演练。
一句话总结
这个项目的核心收获不是某个技术，而是验证了一套方法：用压测数据说话、用预案兜底、把稳定性做成工程体系而不是个人经验。
项目案例会陆续补充。架构方法论见成长体系 · 后端架构落地教程。