Azure 登陆区域的设计原则
Azure 登陆区域的概念体系结构普遍适用于任何登陆区域过程或实现。 体系结构的基础是一组核心设计原则，这些原则可作为整个关键技术领域中后续设计决策的指南。
这些原则可帮助你争取完成目标体系结构的最佳设计。 如果选择部署 Azure 登陆区域加速器或任何版本的企业规模登陆区域代码库，请通过应用此处所述的设计原则构建体系结构。
将这些原则用作实现的一部分将充当实现云技术优势的有用指南。 这种面向云的视角（通常称为云原生）表示面向组织的工作方式和技术选项（传统技术方法通常不提供）。
设计偏差的影响
可能有偏离原则的正当理由，例如在 Tailwind Traders 的情况下。 组织要求可能会影响特定结果或设计 Azure 环境时采用的方式。 在这些情况下，了解偏差对设计和未来运营的影响非常重要。 请仔细考虑每个原则概述的权衡。
一般情况下，请准备好平衡要求和功能。 你的概念体系结构之旅将逐渐随着要求的变化以及你从实现中所学而变化。 例如，使用预览服务并依赖服务路线图可在采用期间清除技术阻碍。
订阅大众化
将订阅用作管理单元，并进行缩放以加快应用程序迁移和新应用程序开发进程。 根据业务需求和优先级调整订阅，以支持业务领域和项目组合所有者。 向业务部门提供订阅，以支持新工作负载的设计、开发和测试以及现有工作负载的迁移。
若要使组织能够大规模有效运营，请支持具有适当的管理组层次结构的订阅。 提供这一支持后，可以有效管理和组织订阅。
偏差的影响
实现此原则的一种方法是分散式运营，方式是将运营转移到业务部门和工作负载团队。 此方法使工作负载所有者可在平台基础建立的规范措施内对工作负载拥有更多控制和自主性。
Azure 登陆区域的概念体系结构设计假设所有运营管理订阅都有特定的管理组和订阅层次结构。 此假设可能与运营模型不一致。
有了这种偏差，随着组织的增长和发展，运营模型可能会发生变化。 此更改可能导致资源再次迁移到单独的订阅中，随后进行复杂的技术迁移。 在采用某种方法之前，请查看对齐指南。
策略驱动的治理
使用 Azure Policy 提供规范措施，并帮助确保始终符合组织的平台以及平台上部署的应用程序的要求。 Azure Policy 还为应用程序所有者提供了独立性以及通往云的安全路径。
偏差的影响
如果不使用 Azure Policy 在环境中创建规范措施，在维护合规性方面的运营和管理开销将增加。 Azure Policy 可帮助你限制并自动实现环境中所需的符合性状态。
在考虑设计时，请查看如何在登陆区域实现内使用 Azure Policy。
单个控件和管理平面
避免依赖于抽象层，例如客户开发的门户或工具。 强烈建议为中心运营和工作负载运营提供一致的体验。
Azure 提供统一且一致的控制平面（受基于角色的访问和策略驱动的控制的约束）。 这适用于所有 Azure 资源和预配通道。 你可以使用 Azure 建立一组标准化的策略和控制措施，以管理整个企业资产。
偏差的影响
选择采用多供应商的方法来操作控制和管理平面可能会增加集成和功能支持的复杂性。 通过替换单个组件来实现“最佳”设计或多供应商操作工具可能会有限制，并且可能会因固有的依赖关系而产生意外的错误。
对于将现有工具投资引入运营、安全或治理的客户，建议查看 Azure 服务和任何依赖项。
以应用程序为中心的服务模型
侧重于以应用程序为中心的迁移和开发，而不是纯基础结构直接迁移，例如移动虚拟机。 设计选项不应该区分新旧应用程序、基础结构即服务 (IaaS) 应用程序或平台即服务 (PaaS) 应用程序。
无论服务模型如何，都努力为 Azure 平台上部署的所有应用程序提供安全环境。
偏差的影响
以与管理组层次结构的实现选项不同的方式细分工作负载，可以创建复杂的策略和访问控制结构来治理环境。 示例包括偏离组织层次结构或按 Azure 服务分组。 这种权衡带来的风险是：出现意外的策略重复和异常，这会增加运营和管理开销。
客户考虑的另一种常见方法是将登陆区域用于开发/测试/生产工作负载。 有关详细信息，请参阅 FAQ 问题：如何在企业级体系结构中处理“开发/测试/生产”工作负载登陆区域？。
与 Azure 本机设计和路线图对齐
尽可能使用 Azure 本机平台服务和功能。 使此方法与 Azure 平台路线图保持一致，以确保新功能在环境中可用。 Azure 平台路线图应有助于让大家了解迁移策略和 Azure 登陆区域概念发展轨迹。
偏差的影响
通过向 Azure 环境内引入第三方解决方案，可创建这些解决方案的依赖项，以提供功能支持和与 Azure 服务的集成。
有时，将现有的第三方解决方案投资引入环境是不可避免的。 请仔细考虑这一原则及其权衡，以符合你的要求。
建议
准备好取舍功能，因为不太可能一开始就需要所有功能。 使用预览服务并依赖服务路线图以清除技术阻碍。
请记住，使用此方法时，理想运营模型的某些方面不一定通用。