你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
建立常见的订阅自动售货生产线
订阅售货可帮助组织实现 Azure 登陆区域的订阅民主化设计原则 ，这对于 Azure 环境的一致缩放、安全性和治理至关重要。 订阅自动售货还有助于组织符合 平台工程原则。 有关详细信息，请参阅 采用产品思维模式 ， 并通过通过防护措施自助为开发人员提供支持。
许多组织都在努力为应用程序团队提供有效交付工作负载和服务所需的灵活性。 一个关键障碍是缺乏标准化的订阅自动售货方法，这可能导致混淆、延迟和效率低下。
本文探讨平台团队如何建立符合各种应用程序团队多样化需求的常见订阅自动售货生产线。 本文讨论提供各种生产线的好处，并提供基于实际客户部署的常见方案示例。 你还了解为什么订阅自动售货没有“一个大小适合所有”的设计，以及为什么你必须向应用程序团队提供各种生产线。
下图显示了 Azure 环境中的管理组和订阅的组织。
以下指南介绍了为何可能需要各种生产线，并介绍使用 Azure 登陆区域和订阅自动售货的客户的生产线示例。
利用各种生产线
应用程序团队需要交付其工作负载和服务所需的订阅采用许多类型和样式。 在应用程序团队之外，组织可能还有其他要求，需要使用 Azure 订阅，例如各种合规性和数据处理规则或体系结构模式。
在决定组织设计和实施订阅自动售货的方法时，请考虑提出以下问题：
平台团队应在订阅自动售货流程中出售哪些其他资源？
对于每个应用程序团队，默认情况下是否部署多个订阅，例如每个环境一个订阅？
对于每个应用程序，你默认是否将辐射虚拟网络对等互连或连接到连接中心？
应如何在每个订阅中构建基于角色的访问控制 （RBAC） ？
应如何管理和控制在订阅中使用的体系结构或原型的资源和样式？
你无法解决每个应用程序和平台团队的独特要求，只需使用任何单一订阅类型或订阅样式即可。平台团队必须让应用程序团队灵活地从多个类型和样式的订阅中进行选择，团队可以通过自助服务系统将其出售给它们。 这些类型的订阅称为 生产线。
仅提供“一个大小适合所有”方法的组织，订阅自动售货通常会限制其内部客户的灵活性。 例如，缺乏灵活性可能会限制应用程序团队的体系结构设计选择，并可能导致由于它们被出售而遭到入侵。
因此，平台团队需要提供各种生产线来满足组织的需求。 这种灵活性可确保消费者可以选择最符合其要求的生产线。
管理应用程序环境
组织必须在订阅自动售货流程和实现过程中管理应用程序团队的应用程序环境。 但是，还应提供灵活性，以便应用程序团队可以管理其应用程序环境，例如开发/测试/生产环境，以及他们在交付应用程序时想要的方式。 有关详细信息，请参阅 环境、订阅和管理组。
某些 Azure 服务提供本机功能，以帮助隔离单个 Azure 订阅中单个资源实例中的环境，例如Azure App 服务及其部署槽位功能。 此示例强制应用程序团队使用单独的订阅，因此团队不能利用 Azure 提供的完整服务集。 单独的订阅还可以增加应用程序交付成本，包括运营和维护开销。
设计用于订阅自动售货的常见生产线
现在，你已了解平台团队必须向 Azure 平台的使用者提供多个 Azure 订阅类型和样式或生产线，本部分介绍了可跨行业和国家或地区使用的多个常见生产线。
平台团队应将这些常见的订阅自动售货生产线用作基线。 你的团队可以现成地为消费者提供多个选项，这符合客户平台工程原则的 优先顺序 。 此方法使内部客户能够自由使用 Azure 登陆区域 设计原则 和 设计区域建议 来交付其工作负载和服务，并提供 Azure 平台治理。
注意
将这些示例用作起点。 可以自定义和扩展这些生产线以满足组织的需求。
订阅自动售货的常见生产线包括：
连接公司：需要传统第 3 层 IP 路由连接的工作负载通过连接订阅连接到其他应用程序和本地环境。
联机：通过新式连接服务和体系结构（例如，Azure 专用链接或通过每个应用程序中公开的 API 或终结点进行交互）与其他应用程序的工作负载进行连接。
技术平台：构建可构建其他应用程序的平台的工作负载。 例如，AKS 平台团队管理Azure Kubernetes 服务（AKS）群集群可以代表其他应用程序团队在其 AKS 群集中托管其他应用程序。
共享应用程序组合：一组常用紧密耦合应用程序的同一应用程序团队之间的共享工作负载。 你不想自行托管应用程序，也不想托管任何特定工作负荷。
沙盒：应用程序团队可以构建概念证明（PoC）或最小可行产品（MVP）并施加更少的控制，以便团队可以促进开发、发明和自由，从可用的 Azure 服务目录中构建最佳应用程序。
公司连接的生产线
公司连接的生产线（也称为内部或专用生产线），用于应用程序登陆区域订阅自动售货通过传统的第 3 层 IP 方法提供连接。 可以使用此生产线在以下资源之间提供连接：
在同一应用程序登陆区域中。
在不同的公司连接的应用程序登陆区域中，通过 Azure 防火墙或网络虚拟设备（NVA）。
通过 Azure ExpressRoute 或 VPN 连接在本地或不同云中。
使用订阅自动售货的组织通常合并此生产线，因为它与大多数本地环境目前的工作方式密切相关。 但是，仅当需要时，才应使用公司连接的生产线。 我们建议你愿意使用更现代的云原生方法，例如在线生产线，你可以。
提示
有关公司工作负荷与联机工作负载之间的差异的信息，请参阅连接、公司与联机管理组的用途是什么？
下图显示了已连接的公司订阅自动售货生产线的示例。 可以将此设置用于中心辐射型网络模型，以帮助有效地管理网络流量和策略。
何时使用公司连接的生产线
在以下情况下使用公司连接的生产线：
你希望根据 合理化的五个 Rs 执行 Rehost 和重构迁移和应用程序生成。
你希望在 Azure 中开始你的旅程，并熟悉类似的本地体系结构。
想要将应用程序“直接迁移”到 Azure。
你希望通过将应用程序隔离到其自己的登陆区域订阅，以及从零信任转向微分段原则，从而增强工作负载之间的安全性，而无需重新架构应用程序完全是云原生的。
记下公司连接的生产线的以下其他注意事项：
平台团队可以将虚拟网络出售到应用程序登陆区域订阅中，并将虚拟网络对等互连到区域中心虚拟网络或 Azure 虚拟 WAN中心。 然后，你的团队可以使用 IP 地址管理（IPAM）工具来控制 IP 地址分配。
平台团队通常不会将子网或任何其他资源出售到虚拟网络中。 相反，平台团队会将这些活动分配给应用程序团队，以便他们可以设计应用程序网络的方式。
平台团队使用分配给订阅上方的管理组的 Azure 策略来强制实施所需的行为，例如附加到每个子网的标准化网络安全组（NSG）。 应用程序团队继承此 Azure 策略，无法对其进行编辑。 此方法遵循订阅民主化的 Azure 登陆区域设计原则。
在线生产线
对于应用程序登陆区域，联机生产线（也称为外部或公共生产线）订阅自动售货不会通过其他应用程序登陆区域或本地的资源之间的传统第 3 层 IP 方法或通过 ExpressRoute 或 VPN 连接提供连接。 同一联机应用程序登陆区域订阅中的资源可以使用虚拟网络通过第 3 层 IP 方法相互通信。 但虚拟网络通常不会对等互连回区域连接中心或其他应用程序登陆区域。
相反，可以通过以下资源之间的公共接口提供连接：
在不同的应用程序登陆区域中。
本地。
在不同云中的工作负荷中。
可以使用用于构造应用程序的各种平台即服务（PaaS）解决方案公开的网络控制、身份验证功能和授权功能来保护连接。
可以使用联机应用程序登陆区域订阅内部和之间的专用链接服务和 Azure 专用终结点来启用和公开应用程序之间基于第 3 层的专用连接。 还可以在应用程序登陆区域中使用的 PaaS 服务之间使用此方法，以防止使用这些 PaaS 服务的公共接口进行安全或监管控制。
还可以将 专用链接 服务与专用终结点配合使用，公开和发布在联机应用程序登陆区域中托管的应用程序，并将其发布到连接的应用程序登陆区域、本地位置或其他云。 可以将专用终结点放置在公司连接的应用程序登陆区域或直接放置在连接中心，然后通过传统的第 3 层连接方法（例如虚拟网络对等互连、ExpressRoute 连接或 VPN 连接）授予对这些专用终结点的访问权限。
将在线应用程序登陆区生产线视为孤立岛屿。 默认情况下，唯一可以访问订阅中资源的资源是部署在同一联机应用程序登陆区域订阅中的资源。 如前所述，可以使用本文中的技术来扩展与其他应用程序登陆区域、本地位置或其他云的连接。
提示
有关公司与联机工作负荷之间的差异的详细信息，请参阅 连接、公司与联机管理组的用途是什么？。
下图显示了联机订阅自动售货生产线的示例。
何时使用在线生产线
在想要以下情况下使用联机生产线：
基于 合理化的五个 Rs 重构、重新架构、重新生成和执行迁移和应用程序生成。
为应用程序团队提供完全民主化的应用程序登陆区域，即使在网络配置方面也是如此。
利用云原生服务和体系结构。
大大增强了与零信任原则的一致性。
使用公司连接的生产线，但专用 IP 地址空间不可用或有限。
- 在此方案中，应查看 Azure 中防止 IPv4 耗尽的指导。
技术平台生产线
使用技术平台（如 Azure VMware 解决方案 或 Azure 虚拟桌面）的团队应实现技术平台生产线。 技术平台生产线本质上是订阅自动售货生产线，更适合高度的技术要求。 可以使用技术平台生产线来托管和管理大型复杂工作负载，这些工作负载通常在整个组织中为多个其他应用程序团队托管多个应用程序。 如果应用程序团队仅管理应用程序部件而不是基础技术平台部分，请使用此生产线。
提示
若要更好地了解此生产线，请考虑以下示例。 技术平台团队（如 AKS 团队）旨在将 AKS 作为托管服务提供给需要在 AKS 平台上运行其应用程序的其他应用程序团队。 AKS 技术平台团队提供 AKS 的管理、维护、安全性和配置。 因此，应用程序团队只维护其应用程序，并将其部署到平台上。
你可能会在技术平台生产线中包含以下产品：
App 服务环境，通常通过单独的App 服务计划。
AKS，通常通过一个或多个群集中的命名空间。
Azure VMware 解决方案群集或主机上的 Azure 虚拟机。
Azure 虚拟桌面 向整个组织提供虚拟桌面或应用程序。
可以根据团队希望为组织中的其他应用程序团队提供服务的技术平台的要求，将这些产品 包含在公司连接 或 在线 生产线中。
共享应用程序组合
应用程序登陆区域的共享应用程序组合生产线订阅自动售货适用于不需要多个单独的应用程序登陆区域订阅的工作负载，这些应用程序可能仅从少量 Azure 资源构造。
应用程序团队和部门可以使用此生产线来托管多个小型应用程序或共享组件，例如存储帐户或 SQL 服务器。 团队在单个订阅或少量订阅中的多个自己的应用程序之间共享这些组件。
重要
一个常见的团队拥有在此产品系列下出售的订阅。 此团队管理在此订阅中为此生产线部署的相关应用程序组合。 不要将此生产线用于具有不同应用程序组合所有者的不相关的应用程序工作负荷的常规部署。
如果组织更改单个订阅并使用资源组委托访问权限，请仔细规划，以确保持续的灵活性、访问控制、治理和可维护性。
如果在多个团队之间的单个订阅中考虑资源组委派，请在做出最终决定之前考虑以下注意事项：
| 区域 | 注意事项 |
|---|---|
| 相关应用程序组合的常见所有权 | - 拥有共同所有者（如部门的业务部门）管理应用程序以简化变更管理，使其保留在同一实体的审批范围内。 - 确保工作负荷在订阅中遵循一致的策略分配，包括日志记录、监视和安全性。 |
| 法规符合性 | - 使用 IAM 和 Azure 策略为符合法规要求的工作负载创建订阅，包括国家标准与技术研究所（NIST）、Internet 安全中心（CIS）、支付卡行业安全标准委员会（PCI SSC）、行业要求和区域要求。 有关详细信息，请参阅 “定制 Azure 登陆区域”。 - 为使用隐私和数据处理要求进行治理的工作负载创建订阅。 单个订阅可减少访问权限。 |
| Azure Policy | 将 Azure 策略的范围限定为管理组、订阅、资源组和资源。 在资源组中部署资源时，在高级别分配 Azure 策略，以便进行高效治理。 在资源组范围级别管理 Azure Policy 时，请考虑以下约束： - 在向订阅添加新资源组时，增加创建 Azure Policy 分配的管理开销 - 管理策略分配更改时增加工作负荷 - 当不立即将策略分配给资源组时，提高安全性和治理差距 - 减少在高范围（例如管理组和订阅）上汇总符合性状态的功能 |
| 订阅限制 | - 检查限制以确保应用程序不会达到阻止增长的硬性限制。 每个订阅都有 Azure 服务的软硬限制。 - 为预计满足订阅限制的大型增长模式的应用程序创建单独的订阅。 - 不要与来自不同业务部门或部门的应用程序团队共享订阅，以防止 干扰邻居 问题。 |
| Azure 服务和功能对齐 | 可以在单个资源组中部署提供基本 Azure 服务基元的服务，例如虚拟机、虚拟网络和简单的 PaaS 服务。 但是，新式复合产品/服务的复杂性要求将这些更复杂的服务部署到单个资源组的边界之外。 对于这些部署方案，请使用本文前面介绍的其他民主化订阅方法。 |
| 只有平台团队才能创建资源组 | 在跨业务部门或部门的各个应用程序团队共享订阅时，可以限制任何团队在共享订阅中创建新资源组的能力。 此限制限制了资源组的蔓延。 只有平台团队才能创建新资源组并管理这些资源组。 此方法增加了 RBAC 分配的复杂性，并增加了对平台团队的依赖，以管理应用程序部署，这可能会阻碍应用程序团队的敏捷性和授权性。 |
可以将你出售的订阅放置在 Corp 或 Online 管理组下的共享应用程序组合产品系列中。 此方法与 Azure 登陆区域默认建议的层次结构保持一致。 或者，如果组织的管理组层次结构遵循定制 Azure 登陆区域体系结构中的 指南来满足要求，则可以将订阅放置在新的管理组下。
下图显示了共享应用程序组合订阅自动售货生产线的示例。
在以下的情况下使用共享应用程序组合产品系列：
应用程序团队需要提供其应用程序共享的多个小型资源或组件，但这些组件不直接适合任何专用应用程序登陆区域。
你拥有在同一部门的应用程序之间共享的资源或组件，但这些组件不直接适合任何专用的应用程序登陆区域。
技术平台团队希望托管大型共享服务，例如 AKS、Azure 虚拟桌面和Azure VMware 解决方案，以便其他应用程序团队可以在服务上使用或托管其应用程序。
沙盒
使用沙盒生产线进行应用程序登陆区域订阅自动售货，以帮助在 Azure 中构建 PoC 或 MVP 提供安全、轻微治理和可见的测试区域。
有关详细信息，请参阅 登陆区域沙盒环境 和管理 Azure 登陆区域中的应用程序开发环境。
沙盒通常受时间限制或预算限制，这意味着它们具有时间限制或预算限制。 在这些情况下，必须扩展或删除沙盒并解除其授权。
如果你的组织没有为应用程序团队或其他人员提供沙盒生产线来测试和试验 Azure 中的服务，团队可能会利用 影子 IT 设置。 如果是这样，你的组织可能难以提供报告和可见性，并将治理应用于业务用户在平台团队的控制与监督之外创建的订阅。
平台团队必须为组织的用户和团队提供易于访问、最好是自助服务，并自动批准对沙盒订阅的访问权限。 为用户和团队提供对平台团队可以查看和管理的环境的访问权限，以防止 平台团队无法访问或控制的影子 IT 环境，从而造成风险。
沙盒通常遵循联机生产线订阅的网络配置方法，因为你不会将它们对等互连到沙盒订阅边界之外的其他虚拟网络。 沙盒通常还具有额外的控制，以防止与本地位置或其他位置建立混合连接。 使用这些控件，使未知源无法将数据从沙盒外泄到未批准的位置。 可以使用 Azure 策略来强制实施这些控制。
与共享应用程序组合和技术平台生产线一样，还可以在同一部门的团队之间共享沙盒生产线，同时考虑相同的注意事项。 不要创建单个沙盒订阅，并通过资源组在团队之间共享它。 而是创建其他沙盒订阅。
如果需要向组织中想要试验、创建 PoC 或创建 MVP 的组织中任何人提供安全、安全和受治理的 Azure 订阅，请使用沙盒生产线。 必须轻而轻地管理这些用户，并授予他们对所有服务的访问权限，以防止 影子 IT 做法。
摘要和外卖
本文概述了指导性指导，可帮助你导航复杂的订阅自动售货流程并朝着实现的方向发展。
确定未来的应用程序团队的要求，以选择最适合它们的订阅自动售货生产线。 确定生成或迁移的初始工作负荷集的要求，以帮助确定要通过自助服务接口启用和公开的订阅自动售货生产线的优先级。
每个生产线都有实施成本和维护成本。 评估长期成本与长期权益和使用情况。
客户通常最初启用以下订阅自动售货生产线：
其他资源
若要进一步支持平台工程方法，请在设计和实施组织的订阅自动售货生产线和产品/服务时查看以下资源：
- 视频：应在 Azure 中使用多少个订阅？
- 平台登陆区域与应用程序登陆区域
- Azure 登陆区域中包含的策略参考实现
- 根据要求定制 Azure 登陆区域体系结构
- 连接、公司和联机管理组的用途是什么？
- 管理 Azure 登陆区域中的应用程序开发环境
- 平台工程原则
下一步
为了获得最佳结果，应尽可能自动执行订阅自动售货过程。 使用有关实现订阅自动售货自动化的配套指南。