我有一个相当典型的公共应用程序部署到Azure，包含以下组件：
在Azure管理控制台中，您可以选择automatically scale out每个云服务（意味着添加更多服务器），这些服务发生在同一个数据中心内。
在多个数据中心之间扩展完整云服务架构（如我们的）的最简单方法是什么？
或者，如果很容易将只是我们的云服务复制到另一个数据中心（正确处理负载平衡等），那么SQL和存储滞后/传输速率是否可以通过微软快速合理地快速完成数据“骨干”？
我问的原因是我们的服务器目前在欧洲，但我们即将在亚洲大力推广，并希望减轻网站的任何性能问题（该网站还托管我们的移动API）。
我很欣赏这是一个非常重要的问题，因为您需要考虑同步SQL数据库和Azure存储容器，但我希望微软已经考虑过它了：）
我目前使用Visual Studio Azure项目中的“发布”命令进行部署。这有一个ServiceDefinition（包含我的两个云服务）和每个环境的ServiceConfiguration文件（Live / Test）。
我真正想要的是像this一样简单（但可能来自Visual Studio）：
>git push azure-NorthCentral master
>git push azure-SoutheastAsia master
>git push azure-WestEurope master
此示例使用Git deployment for Azure Web Sites，它们比我们的Cloud Service架构更加孤立，例如无需考虑数据同步。
答案 0 :(得分：4)
我将此问题标记为过于宽泛，因为老实说，在地理定标方面没有正确的答案。但是，我想提供一个客观的答案，关于Azure本身提供的与您的应用程序相关的内容（无论您是否选择合并它们）。
流量管理器专门用于根据特定规则（最近，循环，主/故障转移）将流量路由到特定区域。根据您的规范，这会将流量定向到您部署到的特定区域。
Azure存储提供了具有地理复制辅助存储的功能（您无法为辅助存储选择区域;每个区域已与另一个区域配对）。然后，您可以选择从次要区域而不是主要区域进行读取。您必须处理数据最终一致的事实。
SQL数据库服务提供了活动的地理复制，您将在其他区域中拥有只读数据库（同样，这是异步复制，尽管您的辅助数据在事务上保持一致）。
请记住：区域之间的带宽/吞吐量没有SLA /性能指标。你需要做一些基准测试。