Azure Well-Architected Framework 支柱
云改变了组织解决业务挑战的方式，以及应用程序和系统的设计方式。 解决方案架构师的角色不仅局限于通过应用程序的功能需求来提供业务价值。 还必须确保以可缩放、可复原、高效和安全的方式设计解决方案。
解决方案体系结构涉及到技术系统的规划、设计、实施和持续改进。 系统的体系结构必须在业务要求与执行这些要求所需的技术能力之间进行平衡，并使两者保持一致。 成品体系结构需要在整个系统及其组件的风险、成本和功能之间取得平衡。
Azure Well-Architected Framework
Azure 架构良好的框架是一组指导如何在 Azure 上生成优质解决方案的原则。 不存在任何以一应百的体系结构设计方法，但无论是对于体系结构、技术还是云提供商而言，确实存在一些适用的通用概念。
虽然这些概念并非包罗万象，但专注于这些概念可有助于为应用程序构建可靠、安全且灵活的基础。
Azure Well-Architected Framework 由五大支柱构成：
- 成本优化
- 卓越运营
- 性能效率
- 可靠性
- 安全性
成本优化
你希望设计的云环境能够让你经济高效地进行操作和开发。 应识别云支出中的低效和浪费，确保投入的资金能够产生最大的收益。
卓越运营
通过利用诸如 DevOps 之类的新式开发做法，可以加快开发和部署周期。 你需要部署一个适当的监视体系结构，以便在故障和问题发生之前（最起码要在客户察觉到之前）检测到它们。 自动化是该支柱的一个重要方面，可消除差异和错误，同时提高运营敏捷性。
性能效率
要让体系结构正常运行且具有可伸缩性，应根据需求为它预配相应的资源容量。 一直以来，云体系结构是通过基于应用程序中的活动动态缩放应用程序来实现这种平衡。 服务需求会发生变化，因此，体系结构应能够根据需求做出调整，这非常重要。 如果在设计体系结构时兼顾了性能与可伸缩性，则可为客户提供极佳的体验，同时可以产生成本效益。
可靠性
每个架构师最害怕的问题就是体系结构出现故障，但却没有任何办法可以恢复。 成功的云环境在设计时已经预见到了所有级别的故障。 预见故障的一部分是设计一个在发生故障后，可在利益干系人和客户要求的时间内恢复的系统。
安全性
数据是组织技术覆盖范围中最有价值的部分。 在此支柱中，你将专注于通过身份验证保护对体系结构的访问，并在出现网络漏洞时保护应用程序和数据。 还应通过加密等工具来保护数据的完整性。
你必须考虑从设计和实现到部署和操作的整个应用程序生命周期的安全性。 云提供针对各种威胁（例如网络入侵和 DDoS 攻击）的保护。 但你仍需要在应用程序、流程和组织文化中构建安全性。
一般设计原则
除了这些支柱外，还应考虑在整个体系结构中采用一些一致的设计原则。
允许体系结构不断发展：没有哪个体系结构是静止不变的。 通过利用可用的新服务、工具和技术，允许体系结构不断发展。
使用数据制定决策：收集数据，进行分析，然后使用它制定体系结构方面的决策。 从成本数据到性能，再到用户负载，合理使用这些数据可以引导你在自己的环境中做出正确的选择。
培训和支持：云技术发展迅速。 对开发、运营和业务团队进行培训，帮助他们做出正确的决策并构建解决方案来解决业务问题。 在组织内记录并共享配置、决策和最佳做法。
自动化：手动活动自动化不仅可以降低运营成本，最大限度减少手动步骤导致的错误，还能提供环境之间的一致性。
共担责任
迁移到云引入了共担责任模型。 在此模型中，云提供商将管理应用程序的某些方面，让你承担剩余的责任。
在本地环境中，你负责一切。 当你迁移到基础结构即服务 (IaaS)，然后迁移到平台即服务 (PaaS) 和软件即服务 (SaaS) 时，云提供商将承担更多责任。
这个共担责任模型会在体系结构决策中发挥作用，因为这些决策可能会影响应用程序的成本、安全性、技术能力和运营能力。 通过将这些责任转移到提供商，您可以专注于为业务带来价值，远离那些不是核心业务职能的活动。
设计选项
在理想的体系结构中，你有机会构建出最安全、高性能、高度可用且高效的环境。 但是，任何设计形式都存在利弊。
若要构建一个最大程度地利用上述支柱的环境，则肯定要付出成本。 这种成本可能体现在资金、交付时间或运营敏捷性上。 每个组织都有不同的优先事务，这会影响在每个支柱中所做的设计选择。 设计体系结构时，需确定哪些权衡可以接受，哪些权衡不可以接受。
构建 Azure 体系结构时，需要考虑到许多因素。 我们希望体系结构安全、可缩放、高度可用且可恢复。 若要做到这一点，必须根据成本、组织的优先事务和风险做出决策。