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