對 AWS Google Azure 三家全球負載均衡的延遲狀況作個評測

全球負載均衡

說到 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 網絡不是太理想。

歡迎你們掃碼關注，獲取更多信息