我们有一个位于北欧地区的数据库,在Azure (西欧和北欧)上有2个AppServices节点。我们使用流量管理器来路由流量。
我们的SQL数据库和存储位于北欧。
当我们开始创建这个网站时,欧洲的位置离我们的客户最近。
然而,我们看到了一个转变,我们的大部分客户现在都来自美国。
我们的处理器上有很高的CPU利用率,尽管每个处理器上都有很多实例。
问题是:
由于我们的大多数客户来自美国,很难重新定位数据库,是保持应用程序结构的原样(北欧和西欧)还是在美国创建一个新节点,但此节点仍需要与北欧的数据库通信?
谢谢
发布于 2017-08-03 07:26:53
不推荐在美国地区使用应用程序,在欧洲使用数据库。
以下是你将会遇到的一些事情:
1)高延迟,因为数据查询必须往返到欧洲才能获得此结果。
2)更高的资源利用率因为通常每个访问数据库的请求都会花费更长的时间,这会在请求等待数据时增加内存使用量,这也会使加载对应用程序的影响更加严重。
3)跨地域数据出口,您需要为所有从欧洲移动到我们的数据付费-每次有查询。
更好的解决方案是执行以下操作:
1)在美国区域建立一个新的DB,并挂接active geo-replication
此时,您将拥有一个热/冷配置,其中任何实例都可用于从DB读取数据,但只有主实例可用于写入操作。
2)在美国地区创建新版本的应用程序/应用程序服务计划
3)调整您的代码以了解您的地理分布式拓扑。
您的应用程序应该能够将所有读取内容发送到“最近”区域,并将所有写入内容发送到主数据库。
4)将代码部署到所有地域
5)将新区域添加到TM配置文件中
虽然这并不理想,因为写操作可能仍然需要跳出池塘,但大多数应用程序的读写模式都严重偏向于读操作(大约85%的读取/ 15%的写入),因此此解决方案的额外好处是在其中一个区域发生故障时提供HA。
您可能想要在我介绍如何使用app Service、SQL Azure和上面概述的技术设置地理分布式应用程序的地方使用look at this talk。
发布于 2017-08-02 09:00:28
您是否考虑过根据用户的位置对数据进行分片?在性能上会更好,您可以在每个地域的非高峰时段提供维护。请允许我向您推荐this文章。
https://stackoverflow.com/questions/45448393
复制相似问题