Azure 基礎：使用 Traffic Manager 分流用戶請求

爲了減小 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 的官方文檔。