Well-Architected Framework 提供了一些建议，可帮助架构师、开发者、管理员和其他云从业人员设计和运营安全、高效、弹性佳、高性能且经济实惠的云拓扑。
Google 的跨职能专家团队会验证 Well-Architected Framework 中的建议。该团队精选 Well-Architected Framework，以反映 Google Cloud的扩展技能、行业最佳实践、社区知识以及您提供的反馈。如需了解 Well-Architected Framework 的重大更改摘要，请参阅新功能。
架构完善框架适用于专为云打造的应用以及从本地迁移到 Google Cloud、混合云部署和多云环境的工作负载。
Well-Architected Framework 的支柱和视角
Well-Architected Framework 中的建议分为核心和视角，如下图所示。
Well-Architected Framework 中的核心针对特定的非功能性重点领域（安全性、可靠性、性能、费用或运营）提供原则和建议。
Well-Architected Framework 中的视角是针对特定技术或行业的跨核心建议视图。透视中的建议与支柱中的一般原则和建议保持一致。
例如，金融服务行业 (FSI) 视角建议采用符合数据留存监管要求的灾难恢复策略。此 FSI 专用建议符合可靠性支柱关于实际目标原则，因为数据驻留要求会影响故障切换区域的选择，进而影响恢复目标。
核心
- 卓越运营
- 高效地部署、运营、监控和管理您的云工作负载。
- 安全性、隐私权和合规性
- 最大限度地确保云数据和工作负载的安全性，在设计时确保隐私权，并遵守法规要求和行业标准。
- 可靠性
- 在云中设计和运行弹性佳且可用性高的工作负载。
- 费用优化
- 使您对 Google Cloud的投资发挥尽可能大的业务价值。
- 性能优化
- 设计和调整云资源以获得最优性能。
观点
- AI 和机器学习
- 针对 AI 和机器学习工作负载的跨支柱技术特定建议视图。
- 金融服务行业 (FSI)
- 针对 FSI 工作负载的行业特定建议的跨支柱视图。
核心原则
在探索 Well-Architected Framework 各核心中的建议之前，请先查看以下核心原则：
从设计上应对变化
没有哪个系统是静态的。用户的需求、构建系统的团队的目标以及系统本身都在不断变化。考虑到变化的需求，您可以构建一个开发和生产流程，以便团队定期交付细微更改并快速获得有关这些更改的反馈。持续展示部署更改的能力有助于与利益相关方（包括负责系统的团队和系统用户）建立信任。使用 DORA 的软件交付指标可以帮助您的团队监控系统更改的速度、轻松程度和安全性。
记录您的架构
当您开始将工作负载迁移到云或构建应用时，缺少有关系统的文档可能会成为一大障碍。文档对于正确直观呈现当前部署的架构尤为重要。
高质量的文档不是通过生成特定数量的文档来实现的，而是取决于内容的清晰度、实用性以及在系统更改时如何维护文档。
适当进行文档说明的云架构可以设定通用语言和标准，使跨职能团队能够有效沟通和协作。此外，该文档还提供确定和指导未来设计决策所需的信息。文档应该根据您的应用场景编写，以便为设计决策提供具体情境。
设计决策会随着时间的推移而不断改进和变化。更改历史记录可提供您的团队调整计划、避免重复以及有效衡量性能随时间变化所需的情境。如果您是新入职的云架构师，尚不熟悉当前设计、策略或历史记录，则更新日志尤为有用。
DORA 的分析发现，文档质量与组织绩效（组织实现绩效和盈利目标的能力）之间存在明确的关联。
简化设计并使用全代管式服务
简洁性对设计至关重要。如果您的架构过于复杂，难以理解，则随着时间的推移，将很难实现和管理设计。在可行的情况下，使用全代管式服务来最大限度地减少与管理和维护基准系统相关的风险、时间和工作量。
如果您已经在生产环境中运行工作负载，则使用代管式服务进行测试，以了解这些服务如何帮助降低运营复杂性。如果您要开发新的工作负载，请先从简单开始，开发最简可行产品 (MVP)，并抵御过度工程的冲动。您可以确定异常的用例，反复迭代并随着时间的推移逐步改进系统。
分离您的架构
DORA 的研究表明，架构是实现持续交付的重要预测因素。分离是一种用于将应用和服务组件分成可以独立运行的较小组件的技术。例如，您可以将单体式应用栈拆分为单独的服务组件。在松散耦合的架构中，应用可以独立运行其功能，而无需考虑各种依赖项。
分离式架构可让您更加灵活地执行以下操作：
- 应用独立的升级。
- 实施特定的安全控制措施。
- 为每个子系统设定可靠性目标。
- 监控健康状况。
- 精细地控制性能和费用参数。
您可以在设计阶段的早期开始分离流程，或者在扩容时将其纳入系统升级。
使用无状态架构
无状态架构可以提高应用的可靠性和可伸缩性。
有状态应用依赖各种依赖项来执行任务，例如本地缓存数据。有状态应用通常需要额外的机制来捕获进度并正常重启。无状态应用可以使用共享存储空间或缓存服务来执行任务，而无需大量本地依赖项。无状态架构使您的应用能够以最少的启动依赖项快速扩容。应用可以承受住硬重启，缩短停机时间，并为最终用户提供更好的性能。