我们有一个位于北欧地区的数据库，Azure上有两个AppServices节点（西欧&北欧）。我们使用流量管理器来路由流量。通过重构节点提高CPU利用率
我们的SQL数据库和存储位于北欧。
当我们启动网站时，欧洲的地点最接近我们的客户。
但是，我们看到了一个转变，现在我们的大部分客户都来自美国。
虽然我们在每个处理器上都有很多实例，但我们的处理器的CPU利用率很高。
的问题是：
由于我们的客户大部分来自美国，很难重新定位数据库，是它更好地保持应用程序的结构，因为它是（北欧&西欧）或创建美国的一个新节点，但该节点仍然需要与北欧的数据库进行通信？
谢谢
不建议您在美国地区和欧洲的数据库应用程序。
这是几个你会碰到的事情：
1）高延迟，因为对数据的查询将不得不往返于欧洲得到这个。
2）由于通常每个访问数据库的请求需要更长的时间，这会增加内存使用量，同时请求正在等待数据，这也会使应用程序的负载影响更严重。 3）跨区域数据出口，每次有查询时，您需要为所有从欧洲转移到我们的数据支付费用。
一个更好的解决办法是做到以下几点：
1）建立一个新的数据库在美国地区和挂钩active geo-replication
在这一点上，你将有一个冷/热配置，其中任何实例都可以用于从数据库读取数据，但只有主要实例可用于写入操作。
2）在美国地区
3）适应你的代码来了解你的地理分布拓扑创建应用程序/应用服务计划的新版本。
您的应用程序应该能够将所有读取发送到“最近”区域，并将所有读取发送到主数据库。
4）代码部署到所有地区
5）新的区域添加到TM轮廓
虽然这不是理想的，因为写操作仍然可能要跳池塘，大多数应用程序有一个读写模式比对读操作严重偏离（大概85％读取/ 15％写入），所以这种解决方案能够解决您的问题，并为您提供HA，以防其中一个区域出现故障。
您可能想要在look at this talk的地方了解如何使用App Service，SQL Azure和上述技术设置地理分布式应用程序。
你有没有考虑根据用户的位置，分片你的数据？在性能方面它会更好，您可以在每个地区的非高峰时段提供维护。请允许我向您推荐this文章。
如果添加更多实例，CPU可能会关闭，在哪个区域无关紧要。美国地区可能会帮助延迟，但您仍然需要往返数据库。你在美国考虑过翻阅吗？ – Mikhail
@Mikhail你认为在CPU利用率方面，处理器上数据库成本的往返将比延迟更好吗？我们已经达到了大量的实例。我们考虑了只读副本，但我认为这将为每个应用程序添加两个连接（读/写）并使编程复杂化。谢谢。 – Techy