在具有自带网络的传统中心辐射型拓扑中，可以完全操作中心虚拟网络。 可以将常见服务部署到中心，使其可供工作负载分支使用。 这些共享服务通常包括 DNS 资源、自定义 NVA 和 Azure Bastion 等等。 但使用 Azure 虚拟 WAN 时，你的访问权限会受到限制并且在虚拟中心上安装的内容也存在限制。
例如，要在传统的中心辐射型网络体系结构中实现专用链接和 DNS 集成，需要创建专用 DNS 区域并将其链接到中心网络。 虚拟机远程访问计划可能包括 Azure Bastion 作为区域中心内的共享服务。 还可以在中心部署自定义计算资源，例如 Active Directory VM。 虚拟 WAN 无法实现这些方法。
本文介绍虚拟中心扩展模式，指导如何安全地向分支公开无法在虚拟中心直接部署的共享服务。
体系结构
虚拟中心扩展是连接到虚拟中心的专用分支虚拟网络，用于向工作负载分支公开单个共享服务。 可以使用虚拟中心扩展向众多工作负载分支提供共享资源的网络连接。 DNS 资源就是此用法的一个示例。 还可以使用扩展来包含需要连接到分支中的众多目标的集中资源。 集中式 Azure Bastion 部署就是此用法的一个示例。
图 1：中心扩展模式
下载此体系结构的 Visio 文件。
- 用于 Azure Bastion 的虚拟中心扩展。 此扩展允许连接到分支网络中的虚拟机。
- 用于 DNS 的虚拟中心扩展。 此扩展允许向分支网络中的工作负载公开专用 DNS 区域条目。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
可靠性
虚拟中心扩展通常被视为对业务十分关键，因为它在网络中提供核心功能。 扩展应符合业务要求，具有故障缓解策略，可随分支需求进行缩放。
标准操作过程应包括所有扩展的复原能力测试和可靠性监视。 这些过程应验证访问权限要求和吞吐量要求。 每个扩展都应具有有意义的运行状况模型。
明确此扩展的服务级别目标 (SLO)，并准确衡量其可靠性。 了解 Azure 服务级别协议 (SLA)，以及扩展中每个单独组件的支持要求。 此知识可帮助你设置目标 SLO 的上限，并了解支持的配置。
安全性
网络限制。 尽管扩展通常由多个分支使用，或者需要访问多个分支，但它们可能不需要与所有分支相互访问。 尽可能使用可用的网络安全控制，例如使用网络安全组和通过安全虚拟中心传出流量。
数据和控制平面访问控制。 请遵循部署到扩展中的所有资源的最佳做法，提供对资源控制平面和任何数据平面的最低特权访问权限。
成本优化
与任何工作负载一样，请确保为扩展资源选择适当的 SKU 大小，以帮助控制成本。 工作时间和其他因素可能会导致某些扩展出现可预测的使用模式。 了解这些模式并提供与之适应的弹性和可伸缩性。
作为共享服务，工作负载资源在企业体系结构中的工作周期通常相对较长。 请考虑通过预购产品/服务（例如 Azure 预留、预留容量定价和 Azure 节省计划）来节省成本。
卓越运营
构建虚拟中心扩展以遵守单一责任原则 (SRP)。 每个扩展都应对应于单个产品/服务，因此不要在单个分支中合并不相关的服务。 可以组织资源，使每个扩展驻留在专用资源组中，以便更轻松地管理 Azure 策略和角色。
应使用基础结构即代码预配这些扩展，并制定支持每个扩展的需求和生命周期的生成和发布过程。 由于扩展在本质上通常是业务关键型的，因此必须为每个扩展制定严格的测试方法和安全的部署做法。
制定明确的变更控制和企业沟通计划至关重要。 可能需要与利益干系人（工作负载所有者）沟通交流正在执行的灾难恢复 (DR) 演练，或任何计划内停机或意外停机。
确保为这些资源建立可靠的操作运行状况系统。 在所有扩展资源上启用适当的 Azure 诊断设置，并捕获了解工作负载运行状况所需的所有遥测和日志。 请考虑长期存储操作日志和指标，以便在共享服务扩展发生意外行为期间为客户支持的互动提供支持。
性能效率
扩展是一项集中式服务。 要将缩放单元设计为处理负载更改，需要了解：
- 组织对扩展的要求。
- 容量计划的要求。
- 分支如何随时间增长。
要设计缩放单元，请根据已建立的指标和服务缩放限制，测试和记录扩展中的每个组件如何单独缩放。 某些扩展可能需要跨多个实例进行负载均衡，以实现所需的吞吐量。
实现示例
专用链接 DNS 扩展：建立用于 DNS 的虚拟中心扩展介绍了一个在专用链接方案中支持单区域 DNS 查找的虚拟中心扩展。