技术方案是研发项目的"施工图纸"，核心要说明"为什么改（背景）、怎么改（设计）、有什么风险（预案）、多久改完（计划）"。新手常犯的错是"只讲技术不说目标、只画架构不提落地"。
技术方案是研发项目启动的核心依据，需明确"需求分析、技术架构、实现路径、风险预案"等核心内容。传统方案撰写需手动梳理逻辑、绘制架构图，评审时需逐字逐句核对，效率低下。千问可生成结构化技术方案模板、辅助架构设计、提供评审checklist，让方案设计更规范，评审更高效。
示例：撰写订单系统高并发改造技术方案
某公司的订单系统在大促期间频繁崩溃，当前架构为单库单表，峰值QPS仅1万。业务部门要求在3个月内完成改造，支撑10万QPS。技术团队初步评估需引入Redis集群、数据库分库分表、消息队列异步化。架构师需在本周内输出一份详细设计方案，用于下周的技术委员会评审。方案必须包含清晰的架构描述、详尽的风险评估（特别是数据迁移和缓存雪崩）以及一个切实可行的3个月实施计划。
输入提示词如下：
你是一名系统架构师，请为以下需求撰写技术方案设计文档：
【业务需求】订单系统改造，支持10万QPS高并发
【现有系统瓶颈】MySQL单库单表，Redis缓存穿透严重，无读写分离
【技术约束】3个月开发周期，硬件预算有限，需兼容现有业务
【输出要求】
-
方案结构：背景与目标、详细设计（含架构图文字描述）、风险评估与应对、实施计划。
-
风险需分技术/业务/进度/成本四类，并给出具体措施。
-
附一份评审Checklist，确保覆盖架构、性能、可用性、成本等核心维度。
输出结果如下：
订单系统高并发改造技术方案设计文档
一、背景与目标
1.1 背景
当前订单系统采用单库单表 MySQL 架构，配合 Redis 缓存。随着业务快速增长，系统在促销活动期间频繁出现响应延迟甚至服务不可用，主要瓶颈包括：
- 数据库写入压力大 ：MySQL 单点写入成为性能瓶颈；
- 缓存穿透严重 ：大量请求查询不存在的订单 ID，直接穿透至数据库；
- 无读写分离 ：所有读写操作均落在主库，资源利用率低；
- 扩展性差 ：无法横向扩容以应对流量激增。
1.2 目标
在3个月内完成系统改造，达成以下目标：
- 支持 10****万 QPS 的稳定处理能力（峰值）；
- 系统可用性 ≥ 99.95%；
- 兼容现有业务接口和数据结构，确保平滑过渡；
- 控制硬件成本，在有限预算内完成架构升级。
二、详细设计
2.1 整体架构设计（文字描述）
新架构采用"分层+异步+缓存增强+数据库分片"策略，整体分为四层：
（1 ）接入层
- 使用 Nginx + LVS 做负载均衡，支持动态扩缩容；
- 前置 API****网关 （如 Kong 或自研轻量网关），实现限流、熔断、鉴权。
（2 ）应用层
- 拆分为 订单创建服务 （写密集）与 订单查询服务 （读密集）；
- 引入 读写分离 ：写请求走主库，读请求优先从从库或缓存获取；
- 应用无状态部署，支持 Kubernetes 自动扩缩容。
（3 ）缓存层
- 多级缓存策略 ：
- L1：本地缓存（Caffeine）缓存热点数据（TTL=1~5s）；
- L2：Redis 集群（3主3从），启用 布隆过滤器（Bloom Filter ） 防止缓存穿透；
- 对空结果也缓存（空值缓存，TTL=30s）；
- Redis 使用 **Pipeline +**批量操作 提升吞吐。
（4 ）数据存储层
- MySQL 分库分表 ：
- 采用 ShardingSphere-JDBC（客户端分片）方案，避免引入中间件复杂度；
- 按 user_id 哈希分 16 库 × 16 表（共256分片），预留未来扩展空间；
- 主从复制（1主2从）实现读写分离；
- Binlog 异步同步 ：通过 Canal + Kafka 将订单变更同步至下游（如风控、通知系统）。
（5 ）监控与治理
- 接入 Prometheus + Grafana 监控 QPS、延迟、错误率；
- ELK 收集日志，便于问题追踪；
- 配置全链路压测环境，验证高并发能力。
架构图文字描述 ：
用户请求 → LVS/Nginx → API 网关（限流/熔断） → 订单服务集群（K8s Pod）
↓（写）
ShardingSphere → MySQL 分库分表（主库）
↓（读）
本地缓存 → Redis 集群（含 BloomFilter） → MySQL 从库
↓（异步）
Canal → Kafka → 下游系统
2.2 关键技术选型
| 组件 | 选型 | 理由 |
|---|---|---|
| 分库分表 | ShardingSphere-JDBC | 轻量、兼容现有 MyBatis，无需 Proxy 运维成本 |
| 缓存 | Redis Cluster + Caffeine | 成熟、高性能，本地缓存降低 Redis 压力 |
| 防穿透 | Bloom Filter + 空值缓存 | 有效拦截无效 ID 查询 |
| 消息队列 | Kafka | 高吞吐，用于解耦和异步处理 |
| 部署 | Kubernetes + Helm | 快速扩缩容，资源利用率高 |
2.3 兼容性保障
- 保留原有 API 接口，内部重构不影响调用方；
- 数据迁移采用 双写 + 校验补偿 策略，确保一致性；
- 提供灰度发布能力，按用户 ID 或流量比例逐步切换。
三、风险评估与应对
3.1 技术风险
| 风险 | 应对措施 |
|---|---|
| 分库分表后跨分片查询困难 | 限制业务仅支持按 user_id 或 order_id 查询；全局查询走 ES 异步索引（二期） |
| Redis 集群故障导致缓存雪崩 | 设置随机 TTL（±10%），加互斥锁重建缓存 |
| ShardingSphere 性能瓶颈 | 压测验证，必要时升级为 ShardingSphere-Proxy（预留方案） |
3.2 业务风险
| 风险 | 应对措施 |
|---|---|
| 改造期间订单数据不一致 | 双写期间开启数据比对任务，自动修复差异 |
| 用户感知到服务异常 | 灰度发布 + 回滚预案（保留旧系统并行运行2周） |
3.3 进度风险
| 风险 | 应对措施 |
|---|---|
| 开发周期紧张（仅3个月） | 采用 MVP 策略：先解决核心瓶颈（分库分表+缓存优化），非核心功能延后 |
| 联调复杂度高 | 提前搭建完整测试环境，每日构建集成 |
3.4 成本风险
| 风险 | 应对措施 |
|---|---|
| 硬件预算有限 | 优先使用云厂商预留实例 + Spot 实例混合部署；Redis 和 MySQL 选用高性价比机型 |
| 运维成本上升 | 自动化运维脚本 + 监控告警全覆盖，减少人工干预 |
四、实施计划（3 个月）
| 阶段 | 时间 | 主要任务 |
|---|---|---|
| Phase 1 ：准备与设计 | 第1-2周 | 架构评审、压测基线建立、分片策略确认、环境搭建 |
| Phase 2 ：核心改造 | 第3-6周 | 分库分表接入、缓存增强（BloomFilter+本地缓存）、读写分离 |
| Phase 3 ：联调与压测 | 第7-9周 | 全链路压测（目标12万QPS）、数据一致性校验、故障演练 |
| Phase 4 ：上线与收尾 | 第10-12周 | 灰度发布、监控覆盖、文档沉淀、旧系统下线 |
注：每周进行迭代评审，关键节点设置 Go/No-Go 决策点。
五、架构评审 Checklist
| 维度 | 检查项 | 是否满足 |
|---|---|---|
| 架构合理性 | 是否消除单点故障？ | ✅ |
| 是否支持水平扩展？ | ✅ | |
| 是否遵循单一职责原则（读写服务拆分）？ | ✅ | |
| 性能 | 是否通过压测验证10万QPS？ | 待验证（Phase 3） |
| 缓存命中率是否 > 95%？ | 目标设定 | |
| 数据库连接池是否合理配置？ | ✅（HikariCP + 动态调整） | |
| 可用性 | 是否具备熔断/降级机制？ | ✅（Sentinel 或 Resilience4j） |
| 是否有灾备/回滚方案？ | ✅（双系统并行 + 快速回切） | |
| 监控告警是否覆盖核心指标？ | ✅（Prometheus + AlertManager） | |
| 成本 | 是否在预算范围内？ | ✅（采用混合云实例 + 资源复用） |
| 是否避免过度设计？ | ✅（MVP 原则，二期再引入 ES） | |
| 兼容性 | 是否 100% 兼容现有 API？ | ✅ |
| 数据迁移是否可逆？ | ✅（双写 + 校验） |
文档版本 ：v1.0
撰写人 ：系统架构师
日期 ：2025年12月26日
该方案结构完整（背景---设计---风险---计划---评审），用通俗语言解释架构，风险分类清晰，实施计划可落地，符合 3 个月周期和预算约束，能直接用于技术评审。此外，还需补充落地细节以便让新手直接上手，避免"方案好看但没法落地"。
