现在有了跨区域的新Azure 区域虚拟网络功能，使用关联组是否有性能优势？在链接博客文章的常见问题解答部分中，阅读
在区域虚拟网络中运行的服务是否会导致性能下降？
虚拟网络只是一个逻辑边界，它并不规定 VNet 中的部署实际去往何处。如果出于某种原因，您需要服务位于同一个 Affinity 组中，您仍然可以在区域虚拟网络中执行此操作。在部署期间，您必须指定托管服务应绑定到的关联组。唯一的限制是，关联组应与区域虚拟网络属于同一区域。
如果您未将托管服务绑定到 Affinity 组，而是将服务直接部署到区域虚拟网络，则您的部署将放置在虚拟网络绑定到的区域内的缩放单元中。
我觉得建议不再使用亲和力组（基于这篇文章和其他一些帖子，也许这是我对 Azure 和/或英语的理解），但服务和数据是否会在数据中共同定位中心呢？
<编辑：当然，在写完这篇文章后，我发现了一篇关于虚拟网络的区域 VNets 和 Affinity Groups的 MSDN 文章，其中指出
以前，在创建虚拟网络 (VNet) 时，您需要将 VNet 与关联组关联，而关联组又与区域关联。这个要求已经改变。现在，VNet 直接与管理门户中的区域（位置）相关联。这使您在创建 VNet 时有更大的自由度。您仍然可以在适当的时候将您的云服务与关联组相关联，但您不需要这样做。
区域代表虚拟网络覆盖的位置。您部署到虚拟网络的任何内容都将实际位于该区域中。如果您想进一步指定您希望您的资源在同一区域内彼此物理上非常接近，您可以为这些特定资源指定一个关联组。这意味着这些资源不仅位于同一物理位置，而且在数据中心中彼此非常接近。
所以，我想在使用亲和力组时会有性能优势。
<edit：我能找到的关于亲和力组的小性能优势和用例的最权威来源可以在Convective 博客文章 Affinity Groups in Azure中找到。
亲和组有两个目的：
- 云服务和存储帐户的托管
- 关联组 VNET 的主机
其中第二个现已弃用。第一个仍然是可能的，但没有被强调，因为它是在 2012 年 Azure 网络升级之前的延迟优化。实际上在 Azure 门户中部署 VM 的标准方式不支持同时创建云服务在亲和组和区域 VNET 中。这让试图满足使用区域 VNET 进行部署的现代最佳实践以及在关联组中创建云服务的历史最佳实践的人们感到困惑。
在这一点上，似乎没有理由将云服务部署到关联组中。但是，与其他部署选择一样，人们最好针对他们的特定工作负载进行测试。