全球负载均衡
说到 AWS、Google、Azure 的全球负载均衡，那我们需要了解一下 Anycast IP。我们知道，在互联网中的公网 IP 是唯一的，正常来说，一个网络中不应该有两个相同的 IP，那么 Anycast protocol 就是这么一项可以让一个 IP 分散在多个地方，这需要云厂商和各地的网络运营商做好路由等协议，将用户路由到最近的节点。
那么全球负载均衡就是利用到了这一点，让用户以最近的路径跳到云厂商的骨干网，通过稳定的骨干网把流量传递到全球各地的后端服务器。并且通过切分 TCP 连接，也就是把用户的连接在全球负载均衡器处终止，负载均衡器和后端服务器产生一个较长往返时间 (RTT) 的 TCP 连接，进而优化用户往返时间。
那么说了这么多，这三家云厂商都有哪些服务利用了这一项技术，通过我的了解和对比，三家云厂商都有利用此技术的参数，分别是：
- AWS：Global Accelerator
- Google：Cloud Load Balancing
- Azure：Front Door
功能对比
就这三家的产品来说，AWS 的 Global Accelerator 是最弱的，它是工作在第四层的，不支持七层的很多功能，Google Cloud Load Balancing 和 Azure Front Door 基本功能类似，是工作在第七层的，很多应用负载均衡器的功能都支持，比如支持卸载 SSL 会话，等主机名路由，URL 路径路由等，让我推荐的话，那就从 Google 还有 Azure 中选择一个喽，希望 AWS 尽快完善 Global Accelerator 的相关功能。
- AWS：★★
- Google：★★★★★
- Azure：★★★★★
网络对比
在功能上面，AWS 已经不占优势，那在全球网络延迟上面，各自又差距多少呢？我们通过第三方的站点进行一下测试，因为都是一次测试结果，会存在一些偶然性，仅作为参考依据。
我在 Google 创建了一个 Cloud Load Balancing，其 Anycast IP 为：35.244.143.92。
那么我们通过第三方站点 https://tools.ipip.net/newping.php，测试结果如下：
从结果中可以看到，在海外的延迟很低，基本都是 10ms 左右。
AWS
同样的，我也在 AWS 创建了一个 Global Accelerator，其 Anycast IP 为：75.2.121.40。
下面是延迟测试结果：
海外延迟大约在 10几毫秒左右，对大陆的网络目前看来有不少改善。
Azure
Azure Front Door 提供的是一个 DNS 名称，名称是wzlinux.azurefd.net。
下面是测试结果：
海外的波动大一些，北非比较高，其他地区还可以。
- AWS：★★★★
- Google：★★★★★
- Azure：★★★
我也对三个 IP 进行了路由追踪，针对于中国大陆的电信用户，出海线路都是走的 CN2，说明三家运营商和中国本地运营商的 peering 还可以。
具体怎么选择，主要看你的业务，如果是四层的业务，那么我觉得 AWS 和 Google 都可以，如果你要上 SSL，那么我不推荐 Global Accelerator，因为它不支持 SSL 会话卸载，需要源端服务器会话卸载，增加 TCP 来回时间，效果不好。
如果你是七层 WEB 应用，那推荐选择 Google 和 Azure 的全球负载均衡器。
CDN 对比
我了解了一下三家云厂商的 CDN，其中看到 AWS 还是使用的传统的 CDN 技术，基于智能 DNS 解析，而 Google 和 Azure 目前都使用了和全球负载均衡一样的技术 Anycast，所以在 CDN 层面，我们只需要测试一下 AWS 的全球网络延迟即可，其他两家基本和全球负载均衡延迟一致，并且 Google 的 CDN 还依托于 Cloud Load Balancing 之上。
- AWS：CloudFront
- Google：Cloud CDN
- Azure：Azure CDN
我们找到一个 CloudFront 的 DNS 域名，进行一下测试：
和全球负载均衡比起来，延迟增加了不少，整体来说 AWS 的 CDN 网络不是太理想。
欢迎大家扫码关注，获取更多信息
