对 AWS Google Azure 三家全球负载均衡的延迟情况做个评测

Posted 2020-12-19

全球负载均衡

说到 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

我在 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 网络不是太理想。

欢迎大家扫码关注，获取更多信息