架构设计最常见的错误，是在需求还没有说清楚之前就开始选择数据库、消息队列或 Kubernetes。正确顺序应当是先理解业务，再确定质量目标和约束，最后选择能够满足目标的技术方案。
一、先确认业务目标
架构师首先要知道系统为谁服务、解决什么问题、怎样衡量成功。建议至少回答：
核心用户是谁，最重要的业务流程是什么；
业务收入、效率或风险目标是什么；
哪些功能必须首期交付，哪些可以延后；
业务高峰何时出现，增长预期如何；
哪些故障会产生重大损失。
例如“建设订单系统”还不够，需要进一步明确订单峰值、支付链路、库存一致性、取消规则、监管要求和可接受停机时间。
二、绘制系统上下文
先画最简单的上下文图，标明用户、目标系统和外部依赖：
消费者 ──> 订单系统 ──> 支付平台
商家 ──> │ ──> 库存系统
客服 ──> └──────> 消息通知平台上下文图的价值是确定边界。哪些能力由本系统负责，哪些由外部平台负责，接口失败时谁承担恢复责任，都应在这一阶段明确。
三、量化非功能需求
模糊要求无法直接指导设计，应转化为可验证指标：
同时记录数据保留、隐私、审计、地域和合规要求。
四、估算容量
容量规划不需要一开始就非常精确，但必须有模型。可以从日活用户、每用户操作次数、峰值系数和平均数据量推导：
峰值 QPS ≈ 日请求量 ÷ 86400 × 峰值系数
存储增长 ≈ 日新增记录数 × 单条记录大小 × 保留天数 × 副本系数还要分别评估网络带宽、并发连接、缓存容量、数据库连接和消息堆积。所有估算都应预留合理余量，并通过压测校准。
五、划分组件与数据边界
组件划分应围绕业务能力、数据所有权和变化频率，而不是简单按技术分层。早期系统可以保持模块化单体，只有在团队规模、发布独立性或扩缩容差异确实需要时再拆分微服务。
每个核心数据对象必须有明确所有者。跨服务直接访问数据库会破坏边界，导致发布和故障相互影响。
六、设计正常与异常流程
不能只画成功路径，还应逐项分析：
外部接口超时怎么办；
消息重复或乱序怎么办；
缓存不可用怎么办；
数据库主库切换期间如何处理；
部分节点版本不一致时是否兼容；
下游容量不足时如何限流和降级。
针对关键流程建立超时、重试、幂等、熔断、隔离、降级和补偿机制。重试必须设置次数、间隔和抖动，避免故障时形成流量放大。
七、比较候选方案
方案比较至少覆盖功能适配、可靠性、性能、安全、成本、团队能力和迁移难度。不要只比较产品参数，还要评估日常运维、升级、备份、监控和故障恢复。
推荐用 ADR 记录最终选择。设计文档还应明确哪些假设尚未验证，并通过原型、压测、故障演练或安全评估消除不确定性。
八、形成分阶段演进路线
架构应匹配当前业务阶段。首期可以采用简单可靠的方案，提前保留扩展点；当流量、团队或合规要求达到触发条件时，再引入读写分离、消息队列、多地域或服务拆分。
上线前检查
核心需求和非功能指标是否可测试；
单点、故障域和外部依赖是否明确；
容量模型是否经过压测验证；
数据备份与恢复是否实际演练；
监控、日志、追踪和告警是否覆盖关键路径；
发布、回滚和应急预案是否可执行；
成本是否在预算范围内。
总结
架构设计的主线是“业务目标 → 约束与指标 → 组件和数据边界 → 异常处理 → 验证与演进”。先解决正确的问题，再选择技术，系统才可能真正可用、可维护和可持续。