為了減少 web 服務器的宕機時間，同時也提高服務器的響應性能，我們往往部署多個站點並通過負載均衡來對外提供服務。Azure 提供的 Traffic Manager 服務屬於負載均衡的一種，特點是工作在 DNS 層，因此具有配置簡單的優勢。本文將通過一個 demo 演示如何通過 Traffic Manager 實現根據用戶的地理位置來分流用戶的請求。
Traffic Manager 簡介
本質上講 Traffic Manager 是 Azure 提供的 DNS 解析服務。它提供的核心能力有：
- 提升響應能力(把請求路由到低延遲的節點)
- 減少宕機時間(把請求路由到健康的節點)
Traffic Manager 會通過我們配置的規則把請求解析到響應延遲最低的節點上去，並同時監控節點的健康狀況，如果發現某個節點出現健康問題就會把請求解析到其它健康的節點上。我們還可以通過更加靈活的配置來決定不同的節點可以響應不同數量的請求。或者是隨時添加新的節點提升服務的響應能力。通過 Traffic Manager 這些功能都夠輕松實現並且配置起來卻很簡單。
有了這樣的能力我們不僅可以輕松的提示服務的響應性能還可以逐個的斷開節點進行維護或升級，從而實現無宕機的 web 服務。
Traffic Manager 工作原理
Traffic Manager 工作在 DNS 級別，這一點非常重要！
在整個工作過程中，Traffic Manager 只負責告訴用戶的 web 客戶端：你訪問的服務器在哪里。所以它沒有代理的功能，也不參與用戶與服務器的通信過程：
從上圖中我們可以清晰的看到，用戶的 web 客戶端只是在進行 DNS 解析的時候通過 DNS 的 CNAME 找到 Traffic Manager，並由 Traffic Manager 根據你的配置完成最終的解析並返回 web 服務的 IP 地址。在這之后，用戶的 web 客戶端都是直接訪問 web 服務器的，直到你設置的 TTL 超時， web 客戶端才會重新進行一次 DNS 解析。所以 Traffic Manager 不是代理或網關，它也看不到 web 客戶端與服務器之間的數據傳遞。
Traffic Manager 支持的路由策略
當我們部署了多個 web 服務器時，如何設置策略讓不同的用戶訪問到不同的 web 服務器上呢？當前 Traffic Manger 內置了四種路由策略：
- Priority (主節點處理所有請求，次節點作為隨時可用的備份存在)
- Weighted (按照指定的權重分配流量)
- Performance (按照最小延遲分配流量)
- Geographic (按照地理位置分配流量)
Priority(基於優先級的路由策略) 可按照優先級設置多個從節點(web 服務器)，當其中的某個或多個節點失效時，活着的節點中具有最高優先級者對外提供服務。這個策略主要用來提高服務的可用性。
Weighted(基於權重的路由策略) 可以為不同的節點(web 服務器)設置不同的權重。比如服務器1配置高、性能好，就可以設置比較高的權重，這樣分配給它的請求就會多些(具體的多少是按照服務器的權重計算出來的)。當然如果其中有服務器離線了，Traffic Manager 就會把負載分配到其它的節點。因此我們也可以使用這種路由策略讓服務器逐個的離線並進行升級從而實現漸進式的發布。
Performance(基於性能的路由策略) 提升服務器的響應時間可謂是重中之重，這種策略會根據最小的網絡延遲來路由用戶的請求。
Geographic(基於地理位置的路由策略) 對於全球化的服務，最好是在不同的地理位置上部署服務器以就近響應用戶的請求。Traffic Manager 也支持這樣的策略。本文中接下來的 demo 就將演示如何創建一個基於地理位置進行路由的 Traffic Manager 設置。
配置基於地理位置進行路由的 Traffic Manager
假設我們有兩台主機，一台在香港，另一台在新加坡。我們希望新加坡的用戶訪問的是放在新加坡的主機，香港的用戶和全世界其它地方的用戶訪問的都是放在香港的主機。
創建 Traffic Manager 配置文件
使用 Traffic Manager 服務需要從創建 Traffic Manager 配置文件開始。在 Azure 的門戶網站上新建一個 "Traffic Manager profile"(不太熟悉 Azure 的朋友可以先去申請創建一個免費的 Azure 賬戶)：
除了填寫合適的名稱還要選擇正確的路由策略，這里我們選擇的 "Geographic" 表示基於地理位置的路由策略。
添加 endpoint
所謂的 endpont 這里就是需要進行域名解析的主機或者是服務。本文的 demo 使用的是兩台放在 Azure 上的虛擬主機。我們先添加放在新加坡的主機(請保證你已經創建了該主機，並且區域選的是 Southeast Asia，同時設置了主機的 DNS 名稱)：
上圖中 webvm2-ip 其實是虛擬主機的 IP。另外在選擇 Regional grouping 為 "Asia"，然后選擇 Contry/Region 為 "Sinqapore"。此時 Regional grouping 中的 "Asia" 被清空了，看來是個 bug。但是這種情況並不影響保存。這個問題存在挺長時間了，難道是個 feature ？？
按照相同的方式我們再添加一個位於香港的節點，由於香港的主機會被除了新加坡之外的其它所有地區的用戶訪問，所以在 Geo-mapping 中設置為 "All(World)" 就可以了(Azure 的 Traffic Manager 服務會保證用戶的請求會被解析到正確的節點)：
監控節點健康狀況
當我們完成節點的添加后，Traffic Manager 會監控節點的健康狀況：
"Degraded" 說明當前監控到的節點有問題，所以我們需要調整一下相關的配置。
打開 Traffic Manager 中的 "Configuration" 界面，把 "Endpoint monitor settings" 中的 Protocol 改為 TCP，端口改成 22，並清空 Path 中的內容：
原因是默認的配置中通過 http 協議和 80 端口監控服務器的健康狀況，但是筆者並沒有在兩個節點上運行 web 服務。改成 TCP 協議和 22 號端口(demo 中的兩台虛擬主機運行的是 linux，並且都監聽了 22 號端口)就可以了。修改配置后，節點的狀態馬上就變成 "Online" 了：
"Online" 說明節點處於健康的，可以穩定提供服務的狀態。
對節點監控是非常重要的，Traffic Manager 就是依靠健康監控來實現自動故障轉移的。
配置 DNS 的 CNAME
完成 Traffic Manager 配置的最后一步是在 DNS 解析中配置域名的 CNAME。筆者在 GoDaddy 購買了域名 filterinto.com，現在我們就給它添加一個 CNAME 並指向前面創建的 Traffic Manager 服務：demox.traffimanager.net：
保存上面的配置就可以了。
測試
接下來該測試我們的配置是否達到了目的。重新說明一下我們預定的目標：
- 新加坡的用戶訪問的是放在新加坡的主機
- 香港的用戶和全世界其它地方的用戶訪問的都是放在香港的主機
先登錄到一台放置在新加坡的虛擬機(使用雲服務的好處是你可以在全世界的任何區域隨意的創建虛擬主機！)，然后執行 dig 命令：
$ dig demo.filterinto.com +noall +answer
這就是我們希望新加坡的用戶訪問到的主機，它的 IP 地址為：52.230.11.28。
接下來直接在本地(哥們兒是天朝子民)執行相同的 dig 命令：
$ dig demo.filterinto.com +noall +answer
其實你只要在新加坡之外的其它地方執行這個命令，解析到的主機 IP 地址都是：52.229.175.83。到這里我們可以證明 Traffic Manager 已經能夠正常工作了。
注意，IP 地址與國家和區域的關系是由專門的機構管理的，我們基本不需要懷疑其正確性。
從 dig 命令的輸出中我們也可以看到 DNS 的解析過程為：
demo.filterinto.com demox.trafficmanager.net // 我們創建的 Traffic Manager 服務 eagle.eastasia.cloudapp.azure.com // Azure 提供的主機域名 52.229.175.83
其中第二三兩行的解析都是由 Azure 完成的。
總結
負載均衡可以在不同的層級以不同的技術實現，本文介紹的 Traffic Manager 就是在 DNS 層的一種實現。本文選擇盡可能簡單的 demo 只是為了說明 Traffic Manager 是什么、能夠做什么。如果要把它應用到生產中則需要考察並測試更多的細節，具體請參考 Azure 的官方文檔。