我有一个相当典型的常见应用程序部署到 Azure，具有以下组件:
- 两种云服务 - Web 和 Worker
- Azure 服务总线
- Azure SQL 数据库
- Azure 存储
在 Azure 管理控制台中，您可以选择 automatically scale out每个云服务(意味着添加更多服务器)，这发生在同一个数据中心内。
跨多个数据中心扩展完整云服务架构(如我们的)的最简单方法是什么？
或者，如果可以很容易地将我们的云服务复制到另一个数据中心(正确处理负载平衡等)，那么通过 Microsoft，SQL 和存储延迟/传输率是否会相当快数据“ Backbone ”？
我问的原因是我们的服务器目前位于欧洲，但我们即将在亚洲大力推广，并希望减轻网站(也托管我们的移动 API)的任何性能问题。
我意识到这是一个不平凡的问题，因为您需要考虑同步 SQL 数据库和 Azure 存储容器，但我希望 Microsoft 已经考虑到它了:)
我当前使用 Visual Studio Azure 项目中的“发布”命令进行部署。它有一个 ServiceDefinition(包含我的两个云服务)和每个环境(实时/测试)的 ServiceConfiguration 文件。
我真正想要的是像 this 这样简单的东西(但可能来自 Visual Studio):
>git push azure-NorthCentral master
>git push azure-SoutheastAsia master
>git push azure-WestEurope master
此示例使用Git deployment for Azure Web Sites ，它们比我们的云服务架构更加隔离，例如无需考虑数据同步。
最佳答案
我将这个问题标记为“太宽泛”，因为说实话，在地理缩放方面没有正确的答案。但是，我想就 Azure 原生提供的与您的应用程序相关的内容(无论您是否选择合并它们)提供一个客观的答案。
流量管理器专为根据特定规则(最近、循环、主要/故障转移)将流量路由到特定区域而设计。这将根据您的规范将流量引导至您部署到的特定区域。
Azure 存储提供了异地复制辅助存储的能力(您无法选择辅助存储的区域；每个区域已与另一个区域配对)。然后，您可以选择从次要区域而不是主要区域读取。您必须面对数据最终一致这一事实。
SQL 数据库服务提供主动异地复制，您将在其他区域拥有只读数据库(同样，这是异步复制，尽管您的辅助数据库在事务上保持一致)。
请记住:区域之间的带宽/吞吐量没有 SLA/性能指标。您需要进行一些基准测试。
关于c# - 跨多个数据中心在地理上扩展 Azure 云服务，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31046947/