架构师思维与架构设计

1. 简历关联点

从高级 Java（编程语言）开发走向架构师面试，面试官关注点会从“你会不会某项技术”升级为“你如何判断问题、设计方案、推动落地、控制风险”。简历中的 WMS（仓储管理系统）、跨境物流、库存防超卖、支付资金一致性、异步任务、Runner（执行器）调度、IoT（物联网）报警风暴治理，都可以升级成架构师表达。

本模块重点解决：

• 如何从业务目标推导架构目标。
• 如何拆解复杂系统。
• 如何做架构取舍。
• 如何设计高可用、高并发、可扩展、可观测系统。
• 如何把方案讲成资深架构师视角，而不是堆技术名词。

2. 架构师面试主线

架构师回答问题建议按“目标 -> 约束 -> 质量属性 -> 方案 -> 取舍 -> 风险 -> 演进 -> 落地”展开。

业务目标
  -> 规模和约束
  -> 核心质量属性
  -> 架构方案
  -> 技术选型
  -> 风险和兜底
  -> 观测和治理
  -> 演进路线

一句话模板：

我不会一上来就选技术，先确认业务目标和约束，再确定核心质量属性，比如一致性、可用性、性能、成本和交付周期。然后把系统拆成稳定边界，选择能满足当前规模且支持演进的方案，最后设计失败路径、监控告警和灰度回滚。

3. 架构师核心思维

3.1 从业务目标出发

架构不是为了“高级”，而是为了支撑业务目标。业务目标通常可以转成架构目标：

热门面试题

1. 问题（基础题）：架构师和高级开发最大的区别是什么？

   • 考点：责任边界、系统性思维、业务结果。
   • 回答思路：高级开发更关注模块实现质量，架构师要从业务目标、系统边界、质量属性、成本和团队落地能力做整体设计。
   • 进阶追问：如果业务要求很急，架构师还要不要追求完美架构？

2. 问题（原理题）：为什么架构设计不能从技术选型开始？

   • 考点：目标驱动、约束驱动、技术适配。
   • 回答思路：技术只是实现手段，先选技术容易脱离业务规模和团队能力；应该先明确目标、约束和质量属性，再选最合适的技术。
   • 进阶追问：如何判断一个方案是过度设计？

3. 问题（项目追问题）：库存防超卖的架构目标是什么？

   • 考点：一致性、性能、兜底。
   • 回答思路：核心目标不是“用 Redis（远程字典服务）锁”，而是保证库存不超卖、请求可承载、失败可补偿、数据可审计。
   • 进阶追问：如果 Redis（远程字典服务）不可用，系统如何降级？

3.2 质量属性优先级

架构设计最难的是取舍。常见质量属性如下：

面试表达：

不同系统质量属性优先级不同。支付系统优先一致性和审计，营销活动优先可用性和削峰，报表系统优先吞吐和成本，IoT（物联网）报警系统优先降噪和实时性。架构师要先排优先级，再做方案。

热门面试题

1. 问题（基础题）：高可用和强一致冲突时怎么选？

   • 考点：业务优先级、CAP（一致性、可用性、分区容错）取舍。
   • 回答思路：看业务损失。资金、库存这类强约束场景倾向一致性；推荐、搜索、报表可以接受最终一致性。
   • 进阶追问：订单主流程哪些环节必须强一致？

2. 问题（原理题）：为什么所有质量属性不能同时做到极致？

   • 考点：资源约束、复杂度、取舍。
   • 回答思路：性能、成本、一致性、可用性之间存在天然张力，比如强一致通常增加延迟和耦合，多副本提升可用性但增加一致性复杂度。
   • 进阶追问：如何把取舍讲给业务方听？

3. 问题（项目追问题）：支付资金一致性最重要的质量属性是什么？

   • 考点：资金正确性、审计、补偿。
   • 回答思路：资金正确性优先，必须有幂等、状态机、唯一流水、对账、补偿和审计；可用性可以通过异步补偿提高，但不能牺牲资金准确性。
   • 进阶追问：如果支付通道回调延迟 30 分钟，系统怎么处理？

3.3 架构分层与边界

架构边界不是按代码目录随意拆，而是按业务职责、数据所有权、变化频率和团队协作拆。

flowchart TD
    A["业务目标"] --> B["领域边界"]
    B --> C["服务边界"]
    C --> D["数据边界"]
    D --> E["接口契约"]
    E --> F["治理与观测"]

拆分判断：

• 高内聚：同一业务规则、同一数据生命周期放一起。
• 低耦合：跨边界只通过清晰 API（应用程序接口）或事件交互。
• 数据归属明确：一个核心数据只由一个服务负责写。
• 变化频率不同：变化快的业务和稳定基础能力分开。
• 团队能维护：拆分数量不能超过团队治理能力。

热门面试题

1. 问题（基础题）：服务拆分按什么原则？

   • 考点：领域边界、数据归属、团队协作。
   • 回答思路：按业务能力和数据所有权拆，避免按技术层拆；核心是高内聚、低耦合、边界清晰。
   • 进阶追问：库存服务和订单服务为什么不能随便共用一张表？

2. 问题（原理题）：服务拆太细有什么问题？

   • 考点：分布式复杂度、调用链、运维成本。
   • 回答思路：拆太细会增加网络调用、事务复杂度、部署复杂度和排障难度，团队能力不足时反而降低交付效率。
   • 进阶追问：如何判断该合并服务而不是继续拆？

3. 问题（项目追问题）：WMS（仓储管理系统）怎么拆服务？

   • 考点：业务边界、数据归属、扩展性。
   • 回答思路：可按基础资料、入库、库存、出库、结算、报表拆；库存和出库要重点设计一致性，报表可异步化和读模型分离。
   • 进阶追问：库存服务如何对外暴露能力？

4. 架构设计方法

4.1 五步架构设计法

第一步：澄清业务目标
第二步：识别约束和规模
第三步：确定质量属性优先级
第四步：设计核心链路和数据流
第五步：设计失败路径、观测和演进

4.2 架构方案评审清单

• 业务目标是否明确。
• 核心数据模型是否清晰。
• 服务边界和数据归属是否明确。
• 是否有主链路、异常链路和补偿链路。
• 是否有容量预估和压测计划。
• 是否有 Log（日志）、Metrics（指标）、Trace（链路追踪）。
• 是否有灰度、回滚和应急开关。
• 是否有成本评估和阶段性演进路线。

4.3 架构演进路线

架构师面试很喜欢问“如果从 0 到 1、从 1 到 10、从 10 到 100，你怎么演进”。

5. 架构图表达

5.1 架构师视角的系统设计总图

flowchart TD
    U["用户/外部系统"] --> G["Gateway（网关）"]
    G --> A["业务服务层"]
    A --> D["领域服务层"]
    D --> DB["MySQL（关系型数据库）"]
    D --> R["Redis（远程字典服务）"]
    D --> MQ["MQ（消息队列）"]
    MQ --> W["异步 Worker（工作线程）"]
    A --> O["Observability（可观测性）"]
    O --> L["Log（日志）"]
    O --> M["Metrics（指标）"]
    O --> T["Trace（链路追踪）"]
    A --> C["Config Center（配置中心）"]

5.2 架构决策闭环

flowchart LR
    A["问题定义"] --> B["目标和约束"]
    B --> C["候选方案"]
    C --> D["方案对比"]
    D --> E["风险评估"]
    E --> F["落地计划"]
    F --> G["监控验证"]
    G --> H["复盘演进"]

6. 表格对比

7. 数据演绎

7.1 订单高峰架构容量推演

日订单量：100 万
峰值集中在 2 小时：50 万
峰值 QPS（每秒查询率）：500000 / 7200 ≈ 70
考虑 5 倍突增：350 QPS（每秒查询率）
每单涉及库存、支付、物流、消息写入
架构目标：主链路不阻塞，异步链路可补偿，核心库存不超卖

资深表达：

我不会只看平均 QPS（每秒查询率），还会看峰值、突增倍率、下游 RT（响应时间）和失败率。订单主链路要短，支付、物流、通知尽量异步化；库存扣减要强约束，其他链路可以最终一致。

8. 线上排查与架构治理

架构师不是只设计图，还要对线上稳定性负责。

9. 项目落地话术

9.1 库存防超卖架构师话术

我会先把库存防超卖拆成三个目标：不超卖、扛峰值、可恢复。核心扣减用数据库条件更新或强一致库存服务保证底线；Redis（远程字典服务）用于热点库存预扣和削峰，但不能作为唯一事实来源；MQ（消息队列）用于异步同步和补偿。失败场景包括重复请求、锁过期、服务重启、消息丢失和库存回滚，所以必须有幂等键、状态机、补偿任务和库存对账。

9.2 支付资金一致性架构师话术

支付系统我会把资金正确性放在第一优先级。架构上用支付流水号和通道事件 ID（标识）做幂等，订单状态和支付状态用状态机管理，Webhook（回调通知）验签、防重放、幂等入库。外部通道延迟或重复通知时，通过对账和补偿修正，所有资金变化都要可审计。

10. 高频面试题与追问

1. 问题：你如何从 0 设计一个系统？

   • 回答思路：先业务目标，再规模约束，再质量属性，再核心链路，再失败路径和演进路线。

2. 问题：如何判断一个架构是不是过度设计？

   • 回答思路：看是否超过当前业务规模、团队能力和可预见增长；过度设计通常增加复杂度但没有对应收益。

3. 问题：架构师如何推动方案落地？

   • 回答思路：拆阶段、定边界、出接口契约、明确风险、设置指标、灰度验证、复盘迭代。

11. 本模块复习清单

• 能用“目标 -> 约束 -> 质量属性 -> 方案 -> 取舍 -> 风险 -> 演进”讲架构设计。
• 能区分高级开发回答和架构师回答。
• 能把库存、支付、物流、报警治理讲成架构方案。
• 能说明架构设计中的一致性、可用性、性能、成本取舍。
• 能画出系统设计总图和架构决策闭环。

12. 精通级分册入口与学习路线

根文档保留全部既有正文，作为兼容入口；本节仅追加导航、事实边界和复核统计，不以导航替换原有学习内容。原正文收口基线的 SHA-256（安全散列算法）为 b8582d14987760639a21dfb6e857d00d36dbaef5f442e50d066b81993ab8d40c。

12.1 八篇分册与八张正式图

八张正式图均为一组 PlantUML（统一建模语言）源文件和一张 PNG（便携式网络图形）渲染图；源文件与渲染图分别按 puml 和 png 扩展名统计。

12.2 事实边界、推荐顺序与快速复习

• E0（待核对）：缺少源码、运行记录或原始业务凭证的结论，只能说明待核对项和核对动作。
• E1（源码与可复现证据）：可由源码、配置、脚本、原始事件或可复现实验直接复核的事实。
• E2（已有材料映射）：来自现有简历、项目材料或已成稿模块的可追溯映射，不外推为新的线上结论。
• E3（演练证据）：用于复算机制、容量、失败窗口或验收方法的假设输入与演练结果，不代表真实生产指标、服务等级协议或项目收益。

推荐首次学习顺序为 00 -> 01 -> 02 -> 03 -> 04 -> 05 -> 06 -> 07：先建立证据和约束，再完成取舍、评审、边界、演进与治理，最后用项目口述和综合题检验表达。快速复习时，从本根的“架构设计方法”和“项目落地话术”恢复主线；需要在面试前压缩练习时，直接阅读 00 分册 的路线与边界，再练习 07 分册 的口述和排障题。

12.3 分册统计与复核口径

统计范围仅为 50-架构师思维与架构设计/ 下的 00–07 八篇 Markdown（标记语言）分册，不含本根兼容正文。知识标记按既有 HTML（超文本标记语言）注释标记计数；六字段题要求“问题、考点、回答思路、详细答案、进阶追问、进阶回答”六个字段在同一题块各恰好一次；口述答案按相应字段计数。Mermaid（图表语法）按围栏计数，时序图按围栏内 sequenceDiagram 计数；标准表按表头紧随 Markdown（标记语言）分隔行计数；数据演绎按 E3（演练证据）字段计数；图资源按目录内 puml/png 文件计数。

复核结果：interview_kb_audit 对本模块全部 Markdown（标记语言）文件审计为 0 个问题；固定 mmdc（Mermaid 命令行工具） 11.4.2 对分册 104 张 Mermaid（图表语法）图真实渲染通过 104 / 104，连同本根 3 张图后为全模块 107 / 107，输出均非空；8 组 PlantUML（统一建模语言）源文件与 PNG（便携式网络图形）渲染图均非空。