实现全球化
在上一单元中，我们描述了如何缩放计算，提升其在过程中的可用性。 我们还建议添加 Azure Cache for 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 进行基于路径的路由。