AWS 良好架构框架
§1摘要与结论
别名：AWS Well-Architected Framework、AWS WAF、AWS Well-Architected、AWS 六大支柱框架、Q:S3-VEN-02、Q:S3-VEN-03 | 英文：AWS Well-Architected Framework | 类型：技术 / framework
§2局部关系图
§3原理 · 为什么
云上架构决策影响面广、取舍多，单靠团队经验容易遗漏关键维度。AWS Well-Architected Framework 把非功能关注点归纳为六大支柱，为架构评审提供一套可复用的检查结构：它不规定唯一正确的架构，而是通过一组问题引导团队对照最佳实践、暴露决策中的利弊与风险。其官方定位是建设性对话而非审计（not an audit mechanism）——评审的目的是识别改进项并推动权衡，而不是给出通过或否决。框架还给出六条通用设计原则：停止猜测容量、在生产规模测试、围绕实验做自动化、考虑演化式架构、用数据驱动架构、通过 game day 改进，把持续验证与演进确立为云架构的基本立场。理解这一原则有助于把厂商框架当作对话与学习工具，而不是合规门槛。把六大支柱与通用原则一起使用，才能既覆盖质量维度，又保持对容量、实验与演化的持续关注；若只逐条核对问题而忽略背后的设计立场，评审容易退化为填表。
§4机制 · 如何运作
框架按支柱→设计原则→最佳实践→评审问题的层次组织。六个支柱分别对应运营卓越、安全、可靠性、性能效率、成本优化与可持续性；每个支柱下有若干设计原则（如运营卓越的围绕业务成果组织团队、实施可观测性、安全地自动化、频繁做小而可逆的变更），之下再展开为可核查的最佳实践与评审问题。评审时团队以工作负载为单位逐项回答，标记为高/中/低风险，并记录改进计划（improvement plan）。支柱之间并非彼此独立：例如可靠性的冗余会抬高成本，安全的加密会影响性能，因此框架要求同时审视多个支柱，发现并显式处理权衡点。可持续性支柱于 2021-12 加入，体现云架构对能耗与环境影响的关注。这种层次化结构让抽象的质量目标落到可讨论、可跟踪的具体问题上。
§5工程 · 怎么落地
落地时通常借助 AWS Well-Architected Tool 建立工作负载档案，按六大支柱完成评审问题清单，产出风险项与改进建议；也在架构评审会议、设计文档模板与团队章程中复用这些检查问题。工程上建议：把评审与迭代节奏结合，针对高风险工作负载定期重评，而不是一次性的合规动作；把识别出的风险转成有负责人、有期限的改进项，并与 ADR 联动记录取舍理由；对同一工作负载在不同阶段用框架做增量对照。框架提供的设计原则可提炼为团队的设计清单，但不应逐条照抄为硬性规范。鉴于其方法论绑定 AWS 服务与云运营模型，跨云或多云场景应先做中立化改写，再结合其他体系使用。由于框架随版本更新（本例为 2024-11），团队还应记录评审所依据的版本，并在框架升级后复核既有改进项的适用性，避免对旧版清单形成路径依赖。
§6权衡卡
框架的最大边界在于厂商立场：它是 AWS 官方方法论，最佳实践与设计原则天然指向 AWS 的托管服务与运营模型，使用托管服务等倾向会引导架构向单一云厂商收敛，存在服务绑定与迁移成本风险。
- 它也不追求中立或完备：问题清单聚焦 AWS 生态，未必覆盖多云、私有化或强合规场景的关注点；把评审问题当作硬性标准，会抑制合理的架构创新。
- 此外，厂商框架面向的是对照最佳实践而非证明架构正确，评审结论不能替代基于场景的架构评估与量化验证。
- 因此应把它当作工程落地的补充视角，而非裁决标准；引用时须标注厂商立场与版本。
- 跨云团队尤其要警惕把 AWS 术语与默认值直接搬入其他环境：先抽出与厂商无关的架构关注点，再回到具体平台评估服务选项，可减少锁定。
- 同时，评审问题应服务于对话，而非成为考核指标，否则团队会倾向于选择容易回答而非真正重要的项。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7冲突 / 对比表
| 对照维度 | AWS 良好架构框架 | GCP 良好架构框架 |
|---|---|---|
| 定位 / 依据层 | AWS 良好架构框架 · AWS Well-Architected Framework | GCP 良好架构框架 · Google Cloud Well-Architected Framework |
| 核心定义（原文） | AWS 发布的云架构最佳实践对照框架，以运营卓越、安全、可靠性、性能效率、成本优化、可持续性六大支柱组织设计原则与评审问题，用于一致地度量工作负载与最佳实践的偏差。 | Google Cloud 发布的云架构建议框架，以运营卓越、安全隐私与合规、可靠性、成本优化、性能优化、可持续性六大支柱及 AI/ML、金融等跨支柱视角，指导设计安全、高效、韧性、高性能且可持续的云拓扑。 |
| 首条机制断言（原文） | 云上架构决策影响面广、取舍多，单靠团队经验容易遗漏关键维度。 | 云架构的核心难题不是缺少选项，而是如何在众多服务与配置间做出可解释、可维护的选择。 |
| 对照关系 | AWS 与 GCP WAF 支柱同构但绑定不同厂商（对照） | 同一条 对照 边的另一端 |
| 典型反例（原文） | 框架的最大边界在于厂商立场：它是 AWS 官方方法论，最佳实践与设计原则天然指向 AWS 的托管服务与运营模型，使用托管服务等倾向会引导架构向单一云厂商收敛，存在服务绑定与迁移成本风险。 | 该框架与 AWS 框架高度同构，但同构并不等于可互换：其核心原则明确写入优先使用全托管服务，体现 Google Cloud 的服务导向，会引导架构向 GCP 服务组合收敛，存在厂商绑定风险。 |
| 处置要点（原文） | 落地时通常借助 AWS Well-Architected Tool 建立工作负载档案，按六大支柱完成评审问题清单，产出风险项与改进建议；也在架构评审会议、设计文档模板与团队章程中复用这些检查问题。 | 落地时可按支柱建立评审清单，并结合 Google Cloud Architecture Center 的参考架构、决策树与 Well-Architected 评审流程使用。 |
§8案例带
去中心化聊天架构逆向
对一个仅有 58 份设计文档、尚未实现的开源去中心化聊天项目做架构逆向：从设计文本提炼 18 个模块及其依赖关系，重建模块依赖 DAG 与三条核心数据流 DAG，并输出全景理解与深度需求分析。
harness 源码架构解析
对 deepseek-harness 官方源码做分层解析：镜像官方架构文档，按九个层与九十余模块建立文档集群，产出跨层联动矩阵与七条关键路径，并钉住「模型可见即已记录」、能力缝三角等设计不变量。
dsh 插件依赖增量定位
以官方插件 DAG 为蓝本，对一个官方清单之外的全新社区插件做功能定位与依赖位置增量分析，产出可下钻交互依赖图与多形态文档的源码级架构逆向案例。
MCP 四件套选型对比
对四个同类 MCP 服务器做源码级能力与成本对比，并以常驻 token 预算为轴给出分级接入策略的技术选型实战案例。
Claude Code 架构逆向
以社区逆向源码、系统提示词与官方文档三源交叉验证，还原一个商业 Agent 的查询引擎、子Agent、工具与权限体系的逆向分析案例。
Open Code Review 图谱
对阿里开源 AI 代码审查 CLI 做源码级解析并构建「知识 + 实践资产 + AI 索引」三合一知识图谱的工程案例。
§9信源与核验
核验结论：它是 AWS 官方最佳实践框架，官方定位为架构评审的建设性对话而非审计；其原则与建议绑定 AWS 服务与运营模型，引用时须标注厂商立场 [VEN-002]
核验结论：评审用于对照最佳实践识别风险与改进项，不构成通过/否决判定，也不能替代基于质量属性场景的架构评估 [VEN-002]
§10原始关系清单
展开：本节点的全部原始关系边（4 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 组合 | → TEC-G-02 | GCP 良好架构框架 E-889 | 多云场景可组合对照两厂商 WAF 建议 |
| 对照 | → TEC-G-02 | GCP 良好架构框架 E-887 | AWS 与 GCP WAF 支柱同构但绑定不同厂商 |
| 实现 | → MTH-G-02 | 质量属性场景与ATAM E-881 | AWS 支柱评审落地质量属性场景分析 |
| 实现 | → MTH-G-06 | 效用树与敏感点权衡点分析 E-886 | AWS 支柱冲突识别支撑效用树权衡点 |