架构设计怎么做：一套可复用、可落地的方法论

架构设计的本质不是"画图"，而是在约束条件下，对系统的关键质量属性（性能、可用性、安全、可演进性、成本）做出一系列可验证的决策，并把这些决策沉淀为团队可执行的方案与规范。

下面给出一套工程化流程，你可以直接用于：0→1 新系统、老系统重构、性能治理、平台化建设。

1. 定义目标：先把"成功"说清楚

架构设计的第一步是把"业务目标"翻译成"系统目标"。

1.1 三类目标

业务目标：增长、效率、合规、交付周期、成本上限
用户体验目标：响应时间、可用性、可理解的错误、可恢复能力
工程目标：可维护、可扩展、可观测、可测试、可替换

1.2 质量属性（必须量化）

建议用这类口径写清楚（例）：

可用性：99.95%（月故障预算约 21.6 分钟）
性能：p99 < 200ms；峰值 10×；冷启动 < 30s
数据：RPO=0/5min？RTO=15min/1h？
安全：鉴权模型、数据隔离、审计留存周期
成本：单位请求成本、存储成本、带宽成本

没有量化目标的"高性能/高可用"，会把设计拉向玄学。

2. 明确约束：架构从来不是"随便选"

把约束写成清单，架构才能对齐现实：

技术栈约束（语言、框架、数据库、云环境、网络）
团队约束（人数、经验、交付节奏、SRE 能力）
合规约束（数据驻留、审计、隐私、等保/ISO 等）
既有系统约束（老接口、数据模型、依赖系统、迁移窗口）
预算约束（机器、带宽、商业软件许可）

约束越早暴露，方案越稳。

3. 业务域建模：先把"业务"分清，再谈"技术"

推荐用 **DDD（领域驱动）**的轻量实践：

识别核心域 / 支撑域 / 通用域
画出业务能力地图（Capability Map）
确定关键业务对象与生命周期（订单、库存、结算、权限等）
划分边界（Bounded Context），明确边界内的一致性责任

架构拆分的第一驱动力应是业务边界，不是技术组件。

4. 架构风格选择：单体 / 微服务 / 模块化单体 / 事件驱动

不要"信仰式选型"，按目标选择：

4.1 快速判断规则

交付优先、团队小、需求不稳定 → 模块化单体更优
多团队并行、域边界清晰、需要独立扩展 → 微服务更优
强解耦、异步扩展、复杂集成与审计 → 事件驱动更优
低延迟强一致、核心链路极敏感 → 收敛一致性边界，避免跨服务事务

4.2 重要提醒

"微服务"不是性能解药，反而引入：网络延迟、分布式一致性、可观测成本、故障放大面。
真正决定上限的是：数据模型、缓存策略、并发控制、隔离与治理能力。

5. 系统分解：模块、服务、依赖关系怎么定

5.1 分解的原则（强烈建议写进设计）

高内聚、低耦合：边界内自洽，边界外通过契约协作
一致性边界清晰：一个边界内可强一致；跨边界默认最终一致
依赖单向：避免环依赖；依赖方向要与业务分层一致
变化隔离：高频变化点与稳定点分开

5.2 输出物（落地必需）

模块/服务清单（职责、Owner、SLA）
依赖图（调用方向、同步/异步）
接口契约（API、事件、数据契约版本策略）

6. 数据架构：这是系统的"骨架"，决定上限

数据设计通常比服务设计更决定长期成败。

6.1 先定三件事

数据主权：哪块数据归哪个边界拥有（写权限唯一）
一致性策略：哪些必须强一致？哪些可最终一致？
读模型策略：是否做 CQRS / 物化视图 / 搜索索引？

6.2 高并发常用组合

缓存：Cache-Aside + 逻辑过期 + 异步刷新（防击穿/雪崩）
写入：Outbox + 消息队列（保证"落库与发消息一致"）
扩展：分区/分片、冷热分层、归档
审计：事件日志/变更日志（可回放、可追踪）

7. 关键横切能力：安全、观测、治理是"架构的一部分"

如果这些能力后补，系统会越来越难控。

7.1 安全（建议最低基线）

身份认证、授权（RBAC/ABAC）、数据权限与审计
租户隔离（如果是 SaaS：数据、缓存 key、消息、配置隔离）
传输与存储加密、密钥管理、敏感字段脱敏
防重放、防刷、风控与限流

7.2 可观测（建议标准化）

指标：RED（Rate/Error/Duration）+ USE（Utilization/Saturation/Errors）
链路追踪：采样策略（不要全量）
日志：结构化、可关联 traceId、分级与采样

7.3 治理（分布式系统生死线）

超时、重试（重试预算）、熔断、隔离（Bulkhead）
限流、降级、灰度发布
依赖健康探测与故障演练（混沌工程最小化实践）

8. 部署与运行：把"可运维性"设计进去

架构必须能在真实环境中持续运行：

环境分层：dev/test/stage/prod
发布策略：蓝绿/金丝雀/分批发布/回滚路径
配置治理：动态配置、灰度配置、配置审计
资源模型：容量规划、自动扩缩容、故障域（AZ/Region）

架构图里没有"发布与回滚"，就等于没有架构闭环。

9. 决策可追溯：用 ADR 管住复杂度

架构设计不是一次性文档，而是一串长期决策。

建议用 **ADR（Architecture Decision Record）**记录：

背景与问题
备选方案与取舍
最终决策
影响面（性能、成本、团队、迁移）
验证方式与指标

ADR 的价值：新人能懂、分歧能收敛、后续能复盘。

10. 架构交付物清单：让团队"照着做"

很多架构失败不是方案差，而是交付物不够可执行。建议至少输出：

C4 视图（Context/Container/Component/Code 选用）
核心链路时序图（下单、支付、库存、权限等）
数据流/事件流（同步/异步边界、幂等点）
SLA/SLO 与容量模型（峰值、裕量、扩容策略）
异常与降级策略（超时、重试、熔断、限流）
安全模型（认证、授权、审计、隔离）
迁移与演进计划（里程碑、回滚、灰度策略）
关键规范（日志/追踪、错误码、接口版本、编码规范）

常见陷阱（强烈建议对照自查）

只做"功能拆分"，忽略一致性与数据主权 → 最终分布式事务地狱
过度追求微服务数量 → 运维与故障域失控
重试没有预算、超时不统一 → 雪崩与级联故障
全量日志/全量追踪 → 性能被观测拖垮
缓存没有击穿/雪崩治理 → 峰值直接打穿数据库
不写 ADR → 方案反复、团队内耗

一句能落地的总纲

以质量属性为北极星，以业务边界为切割线，以数据主权为秩序，以可观测与治理为护城河。