地理节点模式

地理节点模式涉及到将一系列后端服务部署到一组地理节点，其中的每个节点可为任何区域中的任何客户端请求提供服务。 此模式允许以主动-主动方式为请求提供服务，通过在全球分布请求处理来改善延迟和提高可用性。

上下文和问题

许多大型服务在地理可用性和规模方面存在特定的挑战。 经典设计将数据引入计算的方式通常是将数据存储在充当该数据的计算层的远程 SQL 服务器中，并依赖纵向扩展来实现扩增。

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

• 地球另一端的用户连接到宿主终结点时遇到的网络延迟问题
• 对可能导致单个区域中的服务不堪重负的需求突发进行流量管理
• 将应用基础结构副本部署到多个区域以实现全天不间断服务的成本高昂且非常复杂

现代云基础结构经过演进，可以支持前端服务的地理负载均衡，同时允许后端服务的异地复制。 在可用性和性能方面，让数据更靠近用户是良好做法。 当数据在异地分布在遥远的用户群中时，异地分布的数据存储也应该与处理数据的计算资源共置在一起。 地理节点模式将计算引入数据。

解决方案

将该服务部署到遍布全球的多个卫星部署中，每个部署称为地理节点。 地理节点模式利用 Azure 的关键功能通过最短路径将流量路由到附近的地理节点，从而改善了延迟和性能。 每个地理节点位于全局负载均衡器后面，使用 Azure Cosmos DB 之类的异地复制读写服务来托管数据平面，确保跨地理节点的数据一致性。 数据复制服务确保不同地理节点中的数据存储相同，因此可以从所有地理节点为所有请求提供服务。

部署缩放单元与地理节点之间的主要差别在于地理节点永远不会孤立存在。 一个生产平台中始终应该有多个地理节点。

地理节点具有以下特征：

• 由一系列不同类型的资源（通常在模板中定义）组成。
• 在地理节点覆盖范围之外没有依赖项，地理节点是自给性的。 不存在一个地理节点必须依赖于另一个地理节点才能正常运行的情况，如果一个地理节点消亡，其他地理节点仍可正常运行。
• 通过边缘网络和复制后端松散耦合。 例如，可以使用 Azure 流量管理器或 Azure Front Door 作为地理节点的前端，而 Azure Cosmos DB 可以充当复制后端。 地理节点与群集不同，因为它们共享一个复制后端，因此平台会负责处理仲裁问题。

地理节点模式出现在使用商用硬件处理共置于同一台计算机上的数据，并使用 MapReduce 整合不同计算机的结果的大数据体系结构中。 另一种用途是近边缘计算，它使计算更靠近网络的智能边缘，以缩短响应时间。

服务可以在数十个或数百个地理节点上使用此模式。 此外，每添加一个地理节点，整个解决方案的复原能力也会随之提高，因为如果区域性服务中断导致一个或多个地理节点脱机，其他任何地理节点都可以接管工作。

还可以使用全局可用性的地理节点模式来增强本地可用性技术，例如可用性区域或配对区域。 这会增大复杂性，但如果体系结构有存储引擎（例如只能复制到配对区域的 Blob 存储）为后盾，则此措施非常有用。 可将地理节点部署到局部区域内部、局部区域或 Azure 区域覆盖范围中，同时注意有关位置的监管或延迟约束。

问题和注意事项

使用以下方法和技术来实现此模式：

• 现代 DevOps 做法和工具，用于在大量区域或实例中生成和快速部署相同的地理节点。
• 自动缩放，用于在地理节点中横向扩展计算和数据库吞吐量实例。 每个地理节点在公用后端约束范围内单独横向扩展。
• Azure Front Door 之类的前端服务，用于执行动态内容加速、拆分 TCP 和任意播路由。
• Azure Cosmos DB 之类的复制数据存储，用于控制数据一致性。
• 无服务器技术（请尽可能使用），用于降低始终联机的部署成本，尤其是在全球范围内频繁重新均衡负载时。 使用这种策略能够以极少量的额外投资部署大量的地理节点。 无服务器和基于消耗量的计费技术减少了重复异地分布式部署的浪费和成本。
• 实现设计模式不需要 API 管理，但可以将它添加到区域中 Azure 函数应用前面的每个地理节点，以提供更可靠的 API 层，从而能够实现速率限制等附加功能。

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

• 选择是要在每个区域的本地处理数据，还是在单个地理节点中分布聚合并在全球范围内复制结果。 Azure Cosmos DB 更改源处理器使用其租约容器的概念和相应 Azure Functions 绑定中的 leasecollectionprefix 来提供这种精细控制。 每种方法都有明显的优缺点。
• 地理节点可以使用 Azure Cosmos DB 更改源和 SignalR 等实时通信平台协同工作。 地理节点可以通过网格模式中的其他地理节点来与远程用户通信，而无需知道或关心远程用户所在的位置。
• 这种设计模式隐式解耦每个组件，从而构建了超高程度的分布式解耦体系结构。 考虑如何跟踪同一请求的不同组件，因为这些组件可能在不同的实例上以异步方式执行。 适当的监视策略至关重要。 Azure Front Door 和 Azure Cosmos DB 可以轻松地与 Log Analytics 集成，Azure Functions 应与 Application Insights 一起部署，以便在体系结构中的每个组件上提供可靠的监视系统。
• 分布式部署包含更多的机密和入口点，需要采取财产保安措施。 密钥保管库为机密管理提供了一个安全层，API 体系结构中的每一层都应得到适当保护，使 API 的唯一入口点是 Azure Front Door 之类的前端服务。 Azure Cosmos DB 应使用 Microsoft Entra ID 或 IP 限制等做法来限制发往 Azure 函数应用的流量，以及传送到 Azure Front Door 的函数应用。
• 部署的地理节点数量以及应用于每个地理节点中 API 技术的特定应用服务计划会极大地影响性能。 部署额外的地理节点或过渡到高级层会增加额外内存和计算的成本，但这种成本增加不是按事务发生的。 考虑在部署后对 API 体系结构进行负载测试，并将增加地理节点数量与提高定价层的效果进行对比，以使用最经济高效的模型来满足需求。
• 确定数据的可用性要求。 Azure Cosmos DB 提供用于启用多区域写入、可用性区域等的可选标志。 这些标志可以提高 Azure Cosmos DB 实例的可用性并创建复原能力更强的数据层，不过会产生额外的成本。
• Azure 提供多种负载均衡器，这些负载均衡器提供不同的功能来分配流量。 借助决策树为 API 前端选择适当的选项。

何时使用此模式

使用此模式：

• 实现一个用户分布范围广泛的大规模平台。
• 对于任何需要极高可用性和复原能力的服务使用此模式，因为基于地理节点模式的服务可以在多个服务区域同时丢失的情况下留存下来。

此模式可能不适用于

• 存在约束、所有地理节点的数据存储不能保持均等的体系结构。 例如，可能存在数据驻留要求、需要为特定会话保持临时状态的应用程序，或者对单个区域的请求权重很大。 在这种情况下，请考虑将部署缩放单元与能够感知用户数据所在位置的全局路由平面（例如部署缩放单元模式中所述的流量路由组件）结合使用。
• 不需要异地分布的场合。 请考虑改用可用性区域和配对区域来组建群集。
• 需要改造旧式平台的场合。 此模式仅适用于云原生开发，可能很难改造。
• 简单的体系结构和要求，不需要异地冗余和异地分布，或者这些措施没有优势。

工作负荷设计

架构师应评估如何在其工作负载的设计中使用“地理节点模式”，以解决 Azure Well-Architected Framework 支柱中涵盖的目标和原则。 例如：

与任何设计决策一样，请考虑对可能采用此模式引入的其他支柱的目标进行权衡。

示例

• Windows Active Directory 实现了此模式的前期形式。 多重主要复制意味着理论上可以从所有可服务节点处理所有更新和请求，但灵活单一主控操作 (FSMO) 角色意味着所有地理节点并不均等。
• GitHub 上的地理节点模式加速器展示了这种设计模式的实践，旨在帮助开发人员使用实际 API 来实现此模式。