架构设计要素：从“金门大桥”到“小泥沟”的实战心法
面向一线开发和准架构师，讲清架构设计要素：目标/方法/输出、分而治之/迭代设计、输入（功能/质量/限制/资产）、输出（规划/设计/测试/部署/采购）与面试策略。
1. 架构设计要素：基本功就像画画
架构设计要素就像画画的基本功：不管你是素描、水粉还是水墨，都得会布局、用笔、观察。架构设计也一样，不管用什么方法论，都得贯穿这些核心要素。
这一章主要讲输入输出、目标方法，为后续实战打基础。关键词是匠心：沉下心来，一步一步勾画，做出能落地、能传承的架构。
2. 架构设计的规划：目标、方法、输出
2.1 目标：Do the Right Thing Right
做正确的事（Do the Right Thing）
金门大桥设计师回小渔村，乡亲说有条“湍急大河”要修桥。设计师大手一挥：复制金门大桥设计，双拱斜拉索桥！
五个月后回到村里，发现“湍急大河”只是半米宽的小泥沟，搭个木质单拱桥就够了。乡亲们只有行人和自行车，没有卡车。
**问题在哪？**没做正确的事。不知道真实需求，没看交互场景，就盲目复制。
把事情做对（Do the Thing Right）
艺术家设计蜂窝状房屋，有人觉得丑，有人拍婚纱照。艺术家靠灵感设计，但：
- 过两年自己都忘了为什么这样设计
- 人员变动快，设计无法传承
- 无法迭代、无法交接
推荐匠人思路：
- 有想法，但不是纯工业制品
- 普世、易接受、易迭代、易沟通
- 易交接、易评估、易测试验收
Do the Right Thing Right = 满足客户需求 + 把事情做对 = 普世、易传承、易交接的架构
2.2 方法：架构立方体（Architecture Thinking）
推荐 Architecture Thinking（架构师思维） 方法论，核心是架构立方体，包含：
- 应用维度、技术维度
- 功能维度、运行维度
- 逻辑维度、物理维度
三根箭头转换路径：
- 功能 → 运行
- 应用 → 技术
- 逻辑 → 物理
照着流程，把架构图画清晰、细化、丰富，自动完成从应用逻辑到物理落地的完整流程。
2.3 输出：可落地的架构和系统
作曲家不光要有手稿，还要在维也纳金色大厅演奏，让观众欣赏、反馈、传播。
架构师也一样：
- 有架构设计图、文档
- 代码化、系统化
- 让业务负载、用户体验
- 让口碑传播
输出 = 可落地的架构 + 对应的系统
3. 两个核心设计模式
3.1 分而治之（Divide and Conquer）
Hi-Fi 音响系统案例：
音乐发烧友要做 Hi-Fi 系统，买音箱、调音设备、遥控器，但功放系统要么不满足要求，要么太贵。
分而治之过程：
- 拆分成模块：音箱、调音、遥控、功放
- 功放模块无法用商业产品 → 自己开发
- 功放里：旋钮、壳子现成；电路板需定制 → 开发 PCB
- 电路板里：电阻、电容现成；编解码芯片、放大器芯片需定制 → 流片
关键点：
- 分解到刚好能实现为止：有产品用产品，有开源用开源，不行才定制
- 适可而止：到流片就够了，不用研究晶体管理
- 自然拼接：芯片用电路板组装，电路板用壳子封装，用 API 网关/消息队列串联模块
架构设计中的应用：
- 尽量用商业化/开源方案
- 实在不行才少量定制编程
- 用 API 网关/消息队列串联低耦合模块
- 分到合适点就停止，不过度切分
3.2 迭代式设计（蛇咬尾巴循环）
企业架构循环：
- 红箭头：企业和业务能力
- 黄箭头：IT 能力
- 蓝箭头：需求 gap、不可达能力、转型能力
出现 gap → 转型 → 调整企业能力 → 改变 IT → 循环
系统架构循环： 了解需求 → 架构设计 → 开发实现 → 架构验收 → 反向箭头重新了解需求 → 迭代
关键点：
- 一个循环不是结束，是下一个循环的开始
- 蛇嘴咬蛇尾，循环往复
- 不停更新功能需求、改善非功能性需求
- 性能更强、吞吐量更大、安全性更好
匠心精神：通过不停迭代，实现完美的 IT 架构。
4. 架构设计的输入：四大块
4.1 功能性需求：WH 分析法
WH = Who/Which + What + How
宠物管理系统例子：
-
Who/Which：谁在用系统？
- 人：宠物保姆（店员/店长）
- 动物：各种宠物
- 系统：外围用户认证系统、第三方监控系统、第三方支付系统
-
What：系统要做什么？
- 给猫喂食
- 给猫洗澡
- 让猫滚毛线球
- 召唤虚拟小狗（汪汪汪吓唬猫）
-
How：如何交互？
- 人放置猫粮 → 猫吃空猫粮（喂食）
- 猫四仰八叉躺盆子里（洗澡）
注意：How 关注用户如何体验系统（交互），不是内部如何实现（实现细节可忽略）。
4.2 质量需求：怎么分析法
怎么安全、怎么快、怎么稳定、怎么方便、怎么牛...
两大场景：
-
运行质量：系统正常运行时，用户体验到的质量
- QPS、TPS、响应延迟
- 用户实实在在感受到的
-
准备质量：用户体验前，系统管理员准备的质量
- 代码发布速度
- 扩缩容速度（秒级扩展到上万个节点）
快猫 vs 慢牛：
- 慢牛：系统很牛，但准备过程很长
- 快猫：系统不强，但像猫一样敏捷
- 理想：又快又强大（准备质量好 + 运行质量牛）
质量要结合功能需求：
- 召唤虚拟小狗：5 秒响应（运行质量）
- 给猫洗澡：准备 5 分钟（加热倒水铺满澡盆），洗完猫很舒服（运行质量）
每个质量挂在一个功能需求或系统需求上。
4.3 限制：三角形分析法
青铜级玩家（项目管理角度）：
- 范围：金门大桥 vs 小泥沟
- 时间：多久完成
- 资源：设计越细越浪费，用现成产品/开源方案节省资源时间
王者架构师：
-
业务限制：
- CEO 希望市场份额达到 X%
- 用户口碑达到 Y
- 系统必须 10 毫秒响应，支撑 N 万 TPS/QPS
-
技术限制：
- 容器化技术能实现什么功能？有什么问题？
- 中间件技术能达到什么要求？有什么限制？
- 业务与技术限制互相沟通，找到合理切入点
-
法律法规限制：
- 欧洲：GDPR（个人敏感信息管理），数据放欧洲指定城市，支持快速删除
- 美国：PCI DSS（支付安全）
- 中国：安全银行民间证件要求
- 地域性要求、摆放要求、架构设计要求
- 可能导致必须外包、必须对接外部系统（如资金托管需牌照）
关键点：
- 限制制约架构发展，但也让架构真正落地
- 空泛架构 = 口头架构
- 受业务/法律/技术制约的架构 = 真真正正落地的架构
4.4 现有手段：资产和技术
- 上一个项目的积累
- 前一个产品的代码、库、架构设计文档、思路
- 已熟悉的技术
配合需求，实现完整的架构设计思路。
5. 架构设计的输出：五大工件
5.1 架构规划
甘特图：
- 左边：具体任务（需求分析、设计、编码、测试）
- 顶上：时间维度
- 方块：前后依赖、交叠、并发
燃尽图：
- 任务达成 story point
- 灰色线：目标
- 红色点：实际完成（通常追不上灰色线）
没有规划的架构师不是好架构师（虽然可能追不上规划）。
5.2 研发设计
- 需求工程图
- 功能工程图
- 运行工程图
- 十张图 + 五六张文档 = 十几个工件
5.3 测试方案（Test Driven Design）
架构师不光指导开发，还要指导测试。
TDD 循环：
- Red（失败）→ Green（成功）→ Refactor（重构）
- 蛇头咬蛇尾循环
架构师职责：
- 跳出循环之外，在循环开始前考虑：
- 整体测试框架
- 最核心的测试用例
- 让研发/测试工程师通过循环落地、验证架构、完成代码
TDD 框架和关键 use case/test case 的选型、制定由架构师完成。
5.4 部署方案
物理架构：
- 服务器、网络、机房、云平台
应用架构师 vs 系统架构师：
- 应用架构师：对接系统架构师，审核部署方案
- 系统架构师：完成非功能性物理架构
- 配合观察：功能性是否在非功能性物理架构上实现
- 共同实现：业务要求、质量要求（可用性、稳定性、扩展性、高可用、性能）
非功能性扩展面：
- 可用性 → 容灾多活单元化
- 性能 → CDN 缓存
准备过程的质量能力：
- 快速发布：应用发布、数据发布、网络发布
- CI/CD：全自动实现开发测试环境 → 准生产发布
5.5 采购目标设定（招标需求）
RFP（Request for Proposal）：
- 招标流程最关键的文件
- 大部分内容描述招标需求
- 由架构师来写
POC（Proof of Concept）原型验证：
- 验证环境、验证案例
- 成功/失败标准、打分考核项
- 由架构师来写
资深架构师 vs 新架构师：
- 新架构师：参与招标、参与原型设计文档选择，不参与最后盖章
- 资深架构师：有拍板权、图章权
影响力与身价：
- 百万级项目决策人 → 对接总监级（研发总监、产品总监）→ 百万年薪
- 千万级项目决策人 → 对接 CTO → 首席架构师/主架构师 → 千万级身价
6. 面试实战：三道题
6.1 架构设计的整体思路和步骤
核心：架起需求到落地的桥梁
要点：
- 从需求出发，到最后落地
- 分而治之：分解需求、分解模块
- 迭代化思想：逐步落地、细化、可实现化
- 架构立方体方法论：不同视角、不同视图
拿高分：
- 结合实际：讲清楚项目需求、如何理解、如何拆解
- 功能性/非功能性、应用/技术/功能/运行模块、逻辑/物理视图
- 利用立方体思路进行转换
6.2 架构设计中通常要考虑哪些因素
核心：架构设计的输入
要点：
- 功能需求（WH 分析法）
- 质量（怎么分析法：运行质量、准备质量）
- 限制（业务/技术/法律法规三角形）
- 现有资产和技术
拿高分：
- 结合实际项目方法
- 功能需求：Who/Which/What/How 讲清楚
- 质量：多个“怎么”，运行时/准备时多个层次
- 限制：项目角度、企业架构角度等多维度
6.3 架构设计中该如何分配工作时间
考察点：
- 架构设计过程：更关注哪些环节
- 输出：关注哪些输出、比例如何
- 风格：组成派（大部分时间做设计）vs 决策派（大部分时间开会讨论）
- 时间管理：如何管理项目
拿高分：
- 结合架构设计的五大输出：规划、设计、测试、部署、采购
- 分析时间分配比例，体现广度（面很广）和深度（某个点很深）
- 组成派：九成时间在设计 → 细问设计方法、时间价值
- 决策派：一半时间在采购/外包决策 → 细问决策依据、牺牲、限制
三道题总结：
- 一题考输出（整体思路步骤）
- 一题考输入（考虑因素）
- 一题考过程（时间分配）
7. 总结：匠心精神
架构设计要素贯穿整个架构设计过程：
- 目标：Do the Right Thing Right
- 方法：架构立方体
- 输出：可落地的架构和系统
- 模式：分而治之、迭代式设计
- 输入：功能需求、质量、限制、资产
- 输出：规划、设计、测试、部署、采购
关键词：匠心。沉下心来，一步一步勾画，做出能落地、能传承、能交接的架构。
8. 延伸思考
- 找一个相对复杂的项目，作为后续章节的实战案例
- 讲一讲当时如何设计、如何进行架构实践
- 听完这一章后，有什么感触，希望通过什么方式进一步优化
- 后续章节会逐步深入：实际画图、实际写工件，对着原有项目重新画架构图、重新写工件
把架构师的基本功练扎实，把匠心精神练出来。
