练习 - 将设计扩展到多个区域
Contoso Shoes 需要一种方法来承受区域中断。 你要将当前缩放单元部署到主动-主动、共享状态多区域拓扑。 体系结构必须设计为将流量重定向到另一个区域，以防区域发生故障。
当前状态和问题
单一区域已足够用于应用程序。 但是，影响网络的最近一次区域中断导致了系统被最终用户视为离线。 在区域中进行水平缩放，甚至在该区域中部署新缩放单元不会使应用程序从失败状态中恢复。
DNS 由 api.contososhoes.com 的现有注册机构持有。 DNS 记录解析为后端应用程序服务终结点 (apicontososhoes.azurewebsites.net)，生存时间 (TTL) 期间为两天。 将解决方案部署到多个区域时，需要迁移 DNS。
规范
- 扩展体系结构以在主动-主动多区域拓扑中工作。
- 修改部署缩放单元模型，使你可以根据需要动态添加和移除区域，而不是两个区域间的硬编码资源列表。
- 如果出现区域故障，则流量需要路由到非故障区域，而不会对已处于非故障区域中的客户端产生任何显著影响。
- 客户端不应固定到某个区域。
- 客户端应该无需更改 URL 即可联系 API。 DNS 应迁移到全局路由器。
推荐的方法
若要开始设计，建议执行以下步骤：
1 – 多区域拓扑
体系结构必须分布到两个或更多 Azure 区域，以防范区域中断。 选择区域时考虑以下因素：
- 区域必须能够承受该区域中的数据中心中断。
- 体系结构中使用的 Azure 服务和功能必须在区域中受支持。
- 区域以及区域中部署的资源必须靠近最终用户和依赖系统，以最大程度地减少网络延迟。
请考虑一个故障情形。 假设区域 1 获得 75% 的流量，新添加的区域 2 获得剩余流量。 它们都会适当进行缩放以处理该负载。 区域 1 中发生区域中断，所有流量现在都路由到区域 2。 是否可以顺利进行转换？ 区域 2 是否可以支持增加的流量负载？
检查进度：全局分布
2 - 全局路由
若要使客户端以透明方式路由到任一正常工作的区域，请添加全局负载均衡器。 负载均衡器应使用在前面练习中添加的运行状况检查来确定缩放单元是否正常。 你是否可以想出一些方法来处理频繁请求以及可以在不到达后端的情况下完成的类似请求？
- 选择与现有体系结构集成并能够快速故障转移的本机 Azure 服务。
- 确保网络入口路径具有控制措施，以拒绝未经授权的流量。
- 通过从边缘缓存为最终用户提供服务来最大程度地减少网络延迟。
- 迁移现有 DNS 而不影响现有客户端。
- 采用自动方式指示区域故障，以确保流量不会路由到故障区域。 此外，在区域再次可用时收到通知，以便负载均衡器可以恢复路由到该区域。
检查进度：全局流量路由
3 – 部署缩放单元更改
理想状态是主动-主动配置，该配置不需要任何手动故障转移，可从任何区域处理客户端请求。 请考虑这对你的体系结构意味着什么。 例如，是否有任何状态存储在区域缩放单元中？
当前体系结构中的某些服务具有异地复制功能。 请考虑将服务拆分为不同的缩放单元：一个包含全局资源的缩放单元，与全局缩放单元共享资源的其他区域缩放单元。 决定因素之一应该是这些资源的生命周期。 相对于体系结构中的其他资源，资源的预期生存期是多长？ 资源的生存期是否应比整个系统或区域的生存期长或具有同一生存期？或是否应为临时资源？
探索体系结构中使用的 Azure 服务的可靠性功能。 可以从这些功能开始并进一步探索，以最大程度地提高可靠性。
| Azure 服务 | 功能 |
|---|---|
| Azure Cosmos DB | 多区域写入 |
| Azure 容器注册表 | 异地复制 |
| Azure 应用服务计划 | 可用性区域支持 |
检查你的工作
下面是适用于类似体系结构的应用程序和数据设计选择。 是否在设计中涵盖了所有方面？
- 为多区域拓扑选择了其他哪个 Azure 区域，以及为什么？
- 是否在每个 Azure 区域中启用了两个或更多 Azure 可用性区域，以防范数据中心中断？
- 是否包括 Web 应用程序防火墙来控制入口流量？ 制定了哪些路由规则，以及为什么？
- 负载均衡器如何支持现有 DNS 记录？
- 如何使用前面练习中的运行状况检查 API？
- 是否保护应用程序免受 DDoS 攻击，尤其是防止恶意客户端绕过负载均衡器并到达区域实例？
- 如何处理 DNS 迁移？
- 是否对现有组件进行了任何 SKU 更改以支持多区域拓扑？
- 保留了哪些 Azure 服务作为单一实例？ 如何证明选择每个服务的合理性？ 是否进行了任何配置更改？
- 是否记录资源？ 是否认为这会影响你检查整个系统的日志的能力？