通过重构节点提高 CPU 利用率
Improve CPU Utilization by Restructuring Nodes
我们有一个位于北欧地区的数据库，在 Azure（西欧和北欧）上有 2 个 AppServices 节点。我们使用流量管理器来路由流量。
我们的 SQL 数据库和存储位于北欧。
当我们启动该网站时，欧洲的位置离我们的客户最近。
但是，我们看到了转变，现在我们的大部分客户都来自美国。
尽管每个处理器上都有很多实例，但我们的处理器 CPU 利用率很高。
问题是：
由于我们的大多数客户都来自美国并且很难重新定位数据库，因此最好保持应用程序结构不变（北欧和西欧）还是在美国创建一个新节点，但这节点是否仍需要与北欧的数据库通信？
谢谢
您是否考虑过根据用户的位置对数据进行分片？在性能方面会更好，您可以在每个区域的非高峰时间提供维护。请允许我向您推荐 this 篇文章。
不建议在美国地区安装应用程序而在欧洲安装数据库。
这些是您将 运行 加入的一些内容：
1) 高延迟，因为数据查询必须往返欧洲才能获得。
2) 更高的资源利用率，因为通常每个访问数据库的请求都需要更长的时间，这会在请求等待数据时增加内存使用量，这也会使负载对应用程序的影响更加严重。
3) 跨区域数据出口，每次查询时，您都需要为从欧洲移动到我们的所有数据付费。
更好的解决方案是执行以下操作：
1) 在美国地区建立一个新的数据库并连接active geo-replication
此时您将拥有一个 hot/cold 配置，其中任何实例都可用于从数据库读取数据，但只有主实例可用于写入操作。
2) 在美国地区
创建新版本的 App/App 服务计划
3) 调整您的代码以了解您的地理分布式拓扑。
您的应用程序应该能够将所有读取发送到 "closest" 区域并将所有写入发送到主数据库。
4) 将代码部署到所有区域
5) 将新区域添加到 TM 配置文件
虽然这并不理想，因为写入操作可能仍然需要跳过池塘，但大多数应用程序的读写模式比读取操作严重偏斜（大约 85% 读取/15% 写入），因此此解决方案可行如果其中一个区域出现故障，还可以为您提供 HA 的额外好处。
您可能想要 look at this talk 我介绍了如何使用应用服务、SQL Azure 和上述技术设置地理分布式应用程序。
我们有一个位于北欧地区的数据库，在 Azure（西欧和北欧）上有 2 个 AppServices 节点。我们使用流量管理器来路由流量。
我们的 SQL 数据库和存储位于北欧。
当我们启动该网站时，欧洲的位置离我们的客户最近。
但是，我们看到了转变，现在我们的大部分客户都来自美国。
尽管每个处理器上都有很多实例，但我们的处理器 CPU 利用率很高。
问题是：
由于我们的大多数客户都来自美国并且很难重新定位数据库，因此最好保持应用程序结构不变（北欧和西欧）还是在美国创建一个新节点，但这节点是否仍需要与北欧的数据库通信？
谢谢
您是否考虑过根据用户的位置对数据进行分片？在性能方面会更好，您可以在每个区域的非高峰时间提供维护。请允许我向您推荐 this 篇文章。
不建议在美国地区安装应用程序而在欧洲安装数据库。
这些是您将 运行 加入的一些内容：
1) 高延迟，因为数据查询必须往返欧洲才能获得。
2) 更高的资源利用率，因为通常每个访问数据库的请求都需要更长的时间，这会在请求等待数据时增加内存使用量，这也会使负载对应用程序的影响更加严重。
3) 跨区域数据出口，每次查询时，您都需要为从欧洲移动到我们的所有数据付费。
更好的解决方案是执行以下操作：
1) 在美国地区建立一个新的数据库并连接active geo-replication
此时您将拥有一个 hot/cold 配置，其中任何实例都可用于从数据库读取数据，但只有主实例可用于写入操作。
2) 在美国地区
创建新版本的 App/App 服务计划3) 调整您的代码以了解您的地理分布式拓扑。
您的应用程序应该能够将所有读取发送到 "closest" 区域并将所有写入发送到主数据库。
4) 将代码部署到所有区域
5) 将新区域添加到 TM 配置文件
虽然这并不理想，因为写入操作可能仍然需要跳过池塘，但大多数应用程序的读写模式比读取操作严重偏斜（大约 85% 读取/15% 写入），因此此解决方案可行如果其中一个区域出现故障，还可以为您提供 HA 的额外好处。
您可能想要 look at this talk 我介绍了如何使用应用服务、SQL Azure 和上述技术设置地理分布式应用程序。