我们在北欧地区有一个数据库，在Azure（西欧和北欧）上有2个AppServices节点。我们使用流量管理器来路由流量。
我们的SQL数据库和存储位于北欧。
当我们启动网站时，欧洲地区最接近我们的客户。
然而，我们看到了一个转变，我们的大多数客户现在来自美国。
我们的处理器的CPU利用率很高，尽管每个处理器都有很多实例。
问题是：
由于我们的大多数客户来自美国并且很难重新定位数据库，因此最好保持应用程序结构（N. Europe＆amp; W. Europe）或在美国创建新节点但是此节点还需要与北欧的数据库进行通信吗？
谢谢
答案 0 :(得分：2)
您是否考虑过根据用户所在位置对数据进行分片？在性能方面会更好，您可以在每个地区的非高峰时段提供维护。请允许我向您推荐this条。
答案 1 :(得分：2)
不建议您在美国地区使用应用程序，在欧洲使用数据库。
这些是您将遇到的一些事情：
1）高延迟，因为对数据的查询将不得不往返欧洲才能实现这一目标。
2）资源利用率越高，因为一般来说，访问数据库的每个请求都需要更长的时间，这会增加内存使用量，而请求在等待数据时也会对应用程序造成更严重的负载影响。
3）跨区域数据出口，每次有查询时，您需要支付从欧洲到我们的所有数据。
更好的解决方案是执行以下操作：
1）在我们的区域设置一个新数据库并挂钩active geo-replication
此时您将进行热/冷配置，其中任何实例都可用于从数据库读取数据，但只有主实例可用于写入操作。
2）在美国地区创建新版本的App / App Service计划
3）调整代码以了解地理分布式拓扑。
您应用程序应该能够将所有读取发送到“最近”区域并将所有写入发送到主数据库。
4）将代码部署到所有区域
5）将新区域添加到TM配置文件
虽然这并不理想，因为写入操作可能仍然需要跳槽，大多数应用程序都有读写模式，而不是大量读取操作（大约85％读取/ 15％写入）所以这个解决方案可以解决如果其中一个地区出现故障，给你HA的好处还是增加了。
您可能需要look at this talk，我将了解如何使用App Service，SQL Azure和上述技术设置地理位置分布式应用。