你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

地理节点模式

Cosmos DB

Geode 模式涉及将后端服务的集合部署到一组 地理node 中,每个节点都可以为任何区域中的任何客户端提供任何请求。 此模式允许以 主动-主动 样式提供请求,通过在全球分发请求处理来提高延迟和提高可用性。

Geode map

上下文和问题

许多大型服务在异地可用性和规模方面存在具体挑战。 经典设计通常通过将数据存储到远程SQL服务器中,将数据作为该数据的计算层,从而将数据引入计算,具体取决于纵向扩展以增长。

经典方法可能会带来许多挑战:

  • 来自全球另一端的用户连接到托管终结点的网络延迟问题
  • 需求突发的流量管理,使单个区域中的服务不堪重负
  • 将应用基础结构的副本部署到多个区域进行 24x7 服务的成本禁止性复杂性

现代云基础结构已演变为实现前端服务的地理负载均衡,同时允许后端服务的地理复制。 为了获得可用性和性能,使数据更接近用户是好的。 当数据跨远方用户群进行异地分布时,还应将异地分布式数据存储与处理数据的计算资源并置。 地理图模式 会将计算引入数据

解决方案

将服务部署到分布在全球的多个卫星部署中,其中每个部署称为地理区域。 地理定位模式利用 Azure 的主要功能,通过最短的路径将流量路由到附近的地理围栏,从而提高延迟和性能。 每个地理区域都位于全局负载均衡器后面,并使用异地复制的读写服务(如 Azure Cosmos DB)托管数据平面,确保跨地域数据一致性。 数据复制服务确保跨地理区域存储相同,因此 可从所有 地理区域提供 所有 请求。

部署标记和地理隔离区之间的主要区别在于,地理区域从来就不存在于隔离中。 生产平台中应始终有多个地理区域。

Geode overview

地理区域具有以下特征:

  • 由不同类型的资源集合组成,通常在模板中定义。
  • 在地理围栏占用之外没有依赖项,并且是自包含的。 没有地理围栏依赖于另一个操作,如果一个死亡,另一个则继续操作。
  • 通过边缘网络和复制背板松散耦合。 例如,可以使用Azure 流量管理器Azure Front Door 对地理区域进行前端,而 Azure Cosmos DB 可以充当复制背板。 地理区域与群集不同,因为它们共享复制背板,因此平台负责仲裁问题。

地理定位模式发生在大数据体系结构中,这些体系结构使用商用硬件处理在同一台计算机上并置的数据,MapReduce以跨计算机合并结果。 另一种用法是近边缘计算,这使得计算更接近网络的智能边缘,以减少响应时间。

服务可以使用此模式超过数十个或数百个地理区域。 此外,整个解决方案的复原能力随着每个添加的地理围栏而增加,因为如果区域中断使一个或多个地理区域脱机,则任何地理区域都可以接管。

还可以使用全局可用性的地理设计模式来增强本地可用性技术,例如可用性区域或配对区域。 这会增加复杂性,但如果体系结构由存储引擎(如只能复制到配对区域的 Blob 存储)支撑,则这会增加复杂性。 你可以将地理区域部署到区域内、区域或区域足迹中,并考虑对位置的监管或延迟约束。

问题和注意事项

使用以下技术和技术来实现此模式:

  • 新式DevOps做法和工具,用于跨大量区域或实例生成和快速部署相同的地理区域。
  • 自动缩放以横向扩展地理区域中的计算和数据库吞吐量实例。 每个地理区域在常见的背板约束内单独横向扩展。
  • Azure Front Door 等前端服务,用于执行动态内容加速、拆分 TCP 和 Anycast 路由。
  • 复制数据存储(如 Azure Cosmos DB)以控制数据一致性。
  • 尽可能降低无服务器部署成本,尤其是在全球经常重新平衡负载时。 此策略允许部署许多地理区域,只需最少的额外投资。 无服务器和基于消耗的计费技术可减少重复异地分布式部署的浪费和成本。
  • API 管理不需要实现设计模式,但可以添加到区域 Azure 函数应用前面的每个地理区域,以提供更可靠的 API 层,从而实现其他功能,例如速率限制。

在决定如何实现此模式时,请考虑以下几点:

  • 选择是在本地处理每个区域中的数据,还是将聚合分布到单个地理区域,并在全球复制结果。 Azure Cosmos DB 更改源处理器使用其租约容器概念提供此精细控制,以及相应Azure Functions绑定中的 leasecollectionprefix。 每个方法都有不同的优点和缺点。
  • 地理区域可以使用 Azure Cosmos DB 更改源和 SignalR 等实时通信平台协同工作。 地理区域可以通过网格模式中的其他地理区域与远程用户通信,而无需知道或关心远程用户所在的位置。
  • 此设计模式隐式分离所有内容,导致超高度分布式和分离的体系结构。 请考虑如何跟踪同一请求的不同组件,因为它们在不同实例上异步执行。 适当的监视策略至关重要。 Azure Front Door 和 Cosmos DB 都可以轻松地与 Log Analytics 集成,并且应将Azure Functions与应用程序Insights一起部署,在体系结构中的每个组件上提供可靠的监视系统。
  • 分布式部署具有大量需要属性安全措施的机密和入口点。 密钥保管库为机密管理提供安全层,应正确保护 API 体系结构中的每个层,以便 API 的唯一入口点是 Azure Front Door 等前端服务。 Cosmos DB 应使用Azure Active Directory或 IP 限制等做法将流量限制到 Azure Function Apps 和 Function Apps 到 Azure Front Door。
  • 性能受到部署的地理区域数量和应用于每个地理区域 API 技术的特定App 服务计划的影响。 部署额外的地理区域或向高级层移动会增加额外的内存和计算成本,但不会按事务这样做。 考虑在部署 API 体系结构后进行负载测试,并将地理区域的数量与提高定价层的数量形成对比,以便最经济高效的模型用于你的需求。
  • 确定数据的可用性要求。 Cosmos DB 具有用于启用多区域写入、可用性区域等的可选标志。 这会增加Cosmos DB 实例的可用性,并创建更具弹性的数据层,但会产生额外的成本。
  • Azure 提供了各种负载均衡器,这些负载均衡器为流量的分布提供不同的功能。 使用 决策树 帮助为 API 的前端选择正确的选项。

何时使用此模式

使用此模式:

  • 实现具有跨区域分布用户的大规模平台。
  • 对于任何需要极端可用性和复原特征的服务,因为基于地理隔离模式的服务可以同时丢失多个服务区域。

此模式可能不适合

  • 具有约束的体系结构,以便所有地理区域都不能等于数据存储。 例如,可能存在数据驻留要求、需要维护特定会话的临时状态的应用程序,或者对单个区域的请求进行沉重加权。 在这种情况下,请考虑将 部署戳 与全局路由平面结合使用,以识别用户数据所在的位置,例如 部署标记模式中所述的流量路由组件。
  • 不需要地理分布的情况。 相反,请考虑可用性区域和配对区域进行群集。
  • 需要改造旧平台的情况。 此模式仅适用于云原生开发,并且很难进行改造。
  • 简单的体系结构和要求,其中异地冗余和异地分布不需要或有利。

示例

  • Windows Active Directory 实现此模式的早期变体。 多主复制意味着可以从所有可服务节点提供所有更新和请求,但灵活单主操作 (FSMO) 角色意味着所有地理区域不相等。
  • GitHub上的地理图模式加速器在实践中展示了此设计模式,旨在帮助开发人员使用实际 API 实现它。
  • 使用 Cosmos DB 文章的全局分布式应用程序检查了一个基于地理的部署,该部署利用流量管理员进行负载均衡和Azure 应用服务来托管 API 代码。
  • GitHub上的 QnA 示例应用程序在实践中展示了这种设计模式。
  • 通过 SAP OData API 进行异地缓存:Cosmos支持的 OData API 异地缓存示例,作为 SAP 零售应用程序的全局加速数据缓存。