Published on

AWS应用架构最佳实践

Authors
  • avatar
    Name
    Mao
    Twitter

当你在云上构建你的系统的时候，AWS良好架构框架能够帮助你在决策时候更好的权衡得失。通过AWS良好架构框架，你可以学习到在云上构建可靠运维、安全、高效、成本最优系统的最佳实践。同时AWS良好架构框架可以作为衡量已有系统架构的指导原则并对照改进，我们相信一个良好架构的系统可以增加商业成功的概率。

AWS解决方案架构师在多个领域有着多年的解决方案架构经验，他们设计与审视了成百上千个AWS客户架构，通过这些经验，总结出了云上系统架构的最佳实践。

AWS良好架构框架以文档形式提供一些关于架构的基础原则，对照这些原则你可以判断某个架构与最佳之间的GAP；框架也提供了良好架构的评估系统、以及达到良好架构的改进建议。同时AWS也在持续进化，良好架构也会随着不断的完善。

AWS良好架构框架的目标读者是技术相关角色：CTO，架构师，开发人员，运维人员。框架描述了AWS最佳实践以及云上设计、运维策略，并提供了更多的架构模型，在AWS良好架构主页可以获取更多信息。

良好架构定义

AWS架构师每天都在帮助客户使用云上最佳实践设计架构，与客户一起做出架构权衡，当系统部署到云上时，我们得到系统是否良好运行的反馈，并得到权衡的结果。基于我们的积累我们总创建AWS良好架构框架，框架提供了云上架构评估的最佳实践，提供了一系列的基础问答用于设计的架构与良好架构对齐。

AWS良好架构基于五大支柱：卓越运维、安全、可靠、性能、成本。

  • 卓越运维：系统在云上运行与监控能力，支撑客户系统向最终用户投递业务价值，并支撑业务流程或过程的持续改进
  • 安全：保护信息、系统、资产安全的能力
  • 可靠：系统依赖的基础设施或基础服务故障后的恢复能力
  • 性能与效率：高效地使用云资源满足系统需求，同时随着系统需求变化能够保持资源高效使用
  • 成本优化：最低成本满足商业需求

在AWS良好架构框架中，使用如下术语。

  • Component 组件：代码、配置、资源打包成一个逻辑单元以满足一定的用户需求；组件与组件之间是相对解耦的。
  • Workload 工作负载：一组组件对外提供商业价值的服务。
  • Milestones 里程碑：架构演进过程中关键变更点：设计、测试、上线。
  • Architecture 架构：描述一组组件如何组成工作负载。
  • Technology Portfolio 技术组合：需要业务上配合的工作负载集合。

在设计工作负载架构时候，需要根据不同的场景在五大支柱之间权衡，业务决策驱动工程上的优先级。如在开发环境成本的优先级比可靠性高；在关键业务工作负载上，可以增加成本以提升可靠性；在商业系统场景下，良好性能会提升用户体验并增加收入的可能。安全与运维通常不作为权衡的选项，这两个点是在任何场景下都不能牺牲的。

关于架构

在On-Promise环境下用户通常都有集中的架构团队与业务开发团队配合，以落实架构最佳实践。技术架构团队通常由基础设施架构师、软件架构师、数据架构师、网络架构师、安全架构师这些角色组成。架构团队通常使用TOGAF与Zachman Framework作为其架构能力的一部分。

在AWS，我们更偏向于直接在开发团队构建架构能力，而不是构建一个集中的架构团队。将架构能力下放到开发团队存在风险，如怎样保证开发团队能够遵循内部的标准。我们使用两个方法消除这个风险。第一，我们通过让开发团队不断练习（实践流程/标准，接受规范）从而获得此能力，同时提供驻场架构专家让标准能够被遵循。第二，我们提供机制，标准与规则能够在流程中被自动检查。这套方法被列在Amazon leadership principles，并且建立了为客户work back的文化。

Working backward 是创新流程中的基础组成部分，我们基于用户需求开始工作，并让用户定义评价标准并评价我们最终的交付成果。

关于架构我们希望每个团队都由设计架构并遵循最佳实践的能力，为了帮助新团队获得此能力、老团队不断提升此能力，我们建立了虚拟的由首席工程师委员会，委员会里的首席工程师会帮助团队审视架构并帮助他们理解AWS最佳实践。首席工程实负责将最佳实践可视并可获取，如他们在午餐时候讲述关于最佳实践的实际案例，这些演讲会被记录下来给新的团队或成员学习。

AWS最佳实践来自上千个AWS上的系统的总结，我们倾向于使用数据来定义最佳实践，同时我们也使用主题专家、如首席工程师来定义最佳实践，因为首席工程师在实践中会发现一些新的最佳实践，这些新的最佳实践会进入到内部评审流程中。

通用设计原则

AWS良好架构框架列出了一系列的通用设计原则，以便设计出一个良好的云上系统。

  • 停止猜测系统容量：当你部署系统时候，在云上可以先使用最小的资源，然后弹性伸缩。没必要再为空闲资源买单。
  • 以生产环境容量测试系统：在云上，你可以以生产环境的容量测试系统，测试完成后销毁所有资源。
  • 自动化让架构验证测试更容易：自动化可以更快的在云上构建你的系统而不必花费大量人力，使用自动化可以快速实施变更、回滚。
  • 演进式架构：传统模式下架构变化是相对静态的，一次性的。随着业务的不断演进与变化，架构也需要不断的变化与演进，在云上，通过自动化与按实际容量测试方式可以降低架构变化带来的影响。
  • 数据驱动架构：在云上你可以采集架构变化对工作负载的影响数据，基于这些数据可以更好的分析与改进架构。
  • 通过演练不断进步：在云上可以很容易模拟生产环境的事件，通过这些演练可以得到架构改进点，通过事件演练可以沉淀出处理实际事件的经验。

良好架构五大支柱

构建软件与构建大厦类似，如果地基不够稳固就会存在结构性问题。构建软件时，如果忽略了卓越运维、安全、可靠、性能与效率、成本优化这些要素，系统在交付后将会存在诸多挑战。在系统架构中运用好这五大支柱可以帮助你设计出稳定高效的系统，你可以空出多余精力放在其他你，如功能实现。

卓越运维

卓越运维包含系统在云上运行与监控能力，支撑客户系统向最终用户投递业务价值，并支撑业务流程或过程的持续改进能力。 卓越运维支柱包含设计原则、最佳实践、常见问题。可以在卓越运维白皮书中阅读更详细内容。

设计原则

云上系统卓越运维有6大设计原则。

  • 运维代码化：在云上，你可以将整个运行环境代码化，包括工作负载以及基础设施，并保持更新。你可以使用代码方式定义运维过程，事件响应。通过运维代码化，尽可能减少认为出错可能，并能够固话事件响应流程。
  • 注解化的文档：在On-Promise环境上，文档由人手动创建，只给人使用，变更之后的文档同步很麻烦。在云上，在每次构建之后可以自动化的创建注释文档。注解化的文档可以给人与机器使用。在你的运维代码中加入注解。
  • 让变更变得频繁、小、可回滚：工作负载内的组件需要定期更新，使用频繁的、小的、可回滚的更新。
  • 经常提炼运维程序：当运维代码化之后，代码程序过程需要经常提炼并找出优化机会，如设置定期的演练日验证运维代码程序是否有效的工作。
  • 预料故障：实施"pre-mortem"演练用于发现潜在的故障点以便提前移除或消除他们。测试故障场景并验证故障响应过程。
  • 从运维故障中学习：通过已发生的故障中不断学习积累，可以在整个组织中学习并积累。

定义

卓越运维最佳实践分为3个领域：

  1. 准备
  2. 运维
  3. 演进

安全

可靠

性能与效率

成本

良好架构常见问题QA

Reference

AWS良好架构 AWS Well Architected Framework AWS well architected tool AWS Well-Architected

Discuss on Twitter • View on GitHub