走向全球
- 3 分钟
在上一单元中，我们描述了如何缩放计算，提升其在过程中的可用性。 我们还建议添加 Azure Redis 缓存以提高性能，并通过分片横向扩展 Azure SQL 数据库。
随着业务的增长，下一步可能是走向全球。 但是，在尝试实现完全全局体系结构之前，需要考虑一些事项。
应考虑的问题
第一个问题是： 你真的需要走向全球吗？
了解客户在执行此类任务之前所受的痛苦很重要，因此请问自己其他几个问题：
- 能否通过内容分发网络使内容更接近用户？
- 你真的需要跨两个（或更多）地理位置缩放这个特定系统吗？ 例如，美国用户是否需要在英国拥有完全相同的帐户？ 独立系统会更合适吗？ 这种模式在电子商务中很常见。
- 如果确实需要全局分布式系统，那么数据库需要什么一致性？ 由于光速的限制，全球范围内实现强一致性非常困难，因此在 Cosmos DB 等服务中是不允许的。
数据一致性
让我们更仔细地看看数据一致性问题。
数据库系统中的一致性 是指任何给定数据库事务必须仅以允许的方式更改受影响的数据的要求。 分布式计算中使用了两个一致性模型。
强一致性 提供线性化保证。 保证读取操作返回项的最新提交版本。
然后是 最终一致性，即数据库或系统最终会在一段时间内变得一致的想法。 没有读取顺序保证。 如果缺少任何进一步的写入，则副本最终会收敛。
用于走向全球的工具
如果发现确实需要全局缩放应用程序，则有些 Azure 服务可以帮助你实现此目的。 让我们看看 Azure 流量管理器和 Azure Front Door：
- Azure 流量管理器是基于 DNS 的全局负载均衡服务。 它通过使用 DNS 和健康状况探测，根据您定义的路由策略，将用户引导至最佳健康状态的后端。 此定义可以基于性能、位置、循环等。 确定正常的后端后，客户端始终直接连接到后端。
- Azure Front Door 服务是应用程序分发网络（ADN）即服务，为应用程序提供各种第 7 层负载均衡功能。 它提供动态站点加速 (DSA)，还提供具有准实时故障转移能力的全球负载均衡。 它是一项高度可用且可缩放的服务，完全由 Azure 管理。
Azure Front Door 基本上是基于 HTTP 的全局负载均衡器。 客户端与 Front Door 本身建立连接，因此 Front Door 正在代理用户的请求。 如果请求的项不在缓存中，则会标识正确的路由规则。 然后，它会检查相关后端的运行状况探测，假设所有后端都正常，会根据路由方法将用户请求转发到最佳后端。
由于 Azure Front Door 代理连接，因此您可以执行一些高级功能，例如运行 Web 应用程序防火墙和缓存，这对于扩展规模非常有帮助。 这两个函数都不能通过流量管理器实现。
此图显示了如何将这两者一起使用。
此设置使用流量管理器对存储帐户中的静态资产进行简单的基于 DNS 的负载均衡。 它还使用 Front Door 在 Web 应用程序跨应用服务和 VM 进行基于路径的路由。