Azure 提供負載均衡（一）Azure Traffic Manager 為我們的Web專案提供負載均衡
一，引言
上一篇講到我們將自己的Net Core Web 專案部署到 Azure 的 Web App 的一項 pass 服務，假如隨著專案的日益增長的訪問量，之前部署到單節點的應用可能無法保證其穩定性，可能會導致系統宕機等等問題，這個時候，我們就要考慮到專案的架構問題，怎麼保證專案的穩定性，比如：
1，縱向擴充套件，增加 Web App的定價層
Azure Portal 中找到我們之前建立好的叫 “CnBateBlogWeb” 的 Web App，選擇 “App Service plan” => "Change App Service plan"，點選 “Standard（S1）”的超連結。
我們可以看到，當前我們建立的Web App 的定價層是 S1，為100個計算單元，1.75G的記憶體，如果日後專案隨著業務訪問量的上漲無法滿足後，我們可以進行選擇升級，選擇一個合適的定價層。同時，我們也可以點選 ” See additional options “ 檢視更多選項,比如 "Standard（P3V2）“
2，橫向擴充套件：我們可以增加 Azure Web App 例項數，Azure 已經為我們提供了 縮放/擴充套件的功能， 我們可以選擇 ”手動“/ ”自動“去縮放我們的資源
但是今天，我採用第三種方式，假設我們的架構是這個樣子的。
ok，第一種方案，我就不再進行演示了，因為之前在使用部署槽的時候，我也是把應用程式計劃由一個 ”Free“ 改變成 ”S1“，今天著重講一下第二種方式，開始內容之前，我們先了解一下Azure 提供的另外一個服務 ”Traffic Manager“。
-----------------------------題外話-----------------------------
這時，有可能會有人出來抬槓了，說硬體方面可以通過F5，軟體方面，我們也可以通過 Nginx 來實現，為什麼還有額外使用什麼 ”Azure Traffic Manager profile“。用這個還得收費。是沒錯，F5和 Nginx 都可以實現，但這不是重點，重點是去熟悉，瞭解Azure的這些服務。
--------------------我是分割線--------------------
Azure Web App 部署系列：
1，Azure Web App（一）釋出你的Net Core Web 專案
2，Azure Web App（二）使用部署槽切換部署環境程式碼
3，Azure Web App（三）切換你的Net Core Web 專案的資料庫連線字串
4，Azure 提供負載均衡（一）Azure Traffic Manager 為我們的Web專案提供負載均衡
二，正文
1，什麼是 "Traffic Manager profile"（流量配置管理器）
Traffic Manager profile 是 Azure 提供的 DNS 解析服務，可以在全球 Azure 區域內以最佳方式向服務分發流量，同時提供高可用性和響應性。流量管理器提供了以下功能：
（1）提高應用程式可用性
（2）改善應用程式效能
（3）在不停機的情況下執行服務維護
。。。。。。。
Traffic Manager 將監視任何 http 或 https 埠上的每個託管服務集合。如果 Traffic Manager profile 檢測到服務處於離線狀態，則會將流量傳送到下一個最佳可用服務。通過使用此新功能，我們可以看到應用程式的可靠性、可用性和效能得到了提高。
2，建立 Traffic Manager profile
建立Traffic Manager profile 之前，我們還需要再建立一個Web App，配置資訊和前面將到的Azure Web App 演示的Demo的基本配置一樣，只是新建一個資源組為 "Web_Test_01_RG"，Web App 的Name改為 “CnBateBlogWeb01”，Region 選擇 ”Southeast Asia“，點選 “Review+create” 進行預校驗，校驗完成後，點選“Create”
Azure Portal 中 點選 ”Create a resource“，搜尋框中輸入 “Traffic Manager profile”，回車
點選 “Create”
我們可以看到 Traffic Manager 配置檔案頁面，
Name：為流量管理器配置檔案輸入唯一的名稱，
Routing method：路由策略方式
Rreource group：資源組
Resource group location：資源組的位置，這個位置我習慣根據實際專案部署的位置選擇，其實它對Traffic Manager 配置檔案沒有任何影響
我i們來細看一下 Routing method 這個引數
Traffic Manger 給我們提供了四種路由策略：
（1）Performance(基於效能的路由策略)：這種策略是根據當前不同伺服器的效能根據可能最小延時來響應使用者的請求
（2）Weighted(基於權重的路由策略)：可以對多個伺服器設定不同的權重，這樣Traffic Manger會根據不同的權重分配不同的流量，權重較高的，那麼分配到的請求也就多一些。
（3）Priority(優先順序的路由策略)：根據設定的多個伺服器節點，比方說有一些伺服器因為某些原因宕機，Traffic Manger 會自動從正常的服務響應使用者的請求
（4）Geographic(基於地理位置的路由策略)：這種最好理解，簡單說就是在不同的地理位置上部署伺服器以就近響應使用者的請求，
（5）MultiValue(基於多值的路由策略)：多值路由僅針對使用 IPv4 或 IPv6 地址指定了所有端點的配置檔案啟用，根據指定的可配置的最大返回計數返回所有執行正常的終結點。
（6）Subnet(基於子網的路由策略)： 藉助子網流量路由方法，可以將一組 IP 地址範圍對映到特定終結點，當流量管理器接收到請求後，它會檢查請求的源 IP 並返回相關的終結點 。
我們接下來都會試試，
Name ：”tm.cnbateblogweb“；Routing method 選擇：”Performance“，Resource group：選擇之前建立好的的 “Web_Test_TM_RG”，Resource group location 的位置是之前資源組預設的 “East Asia”。新增完成後，我們點選 “Create”。
稍等片刻之後，我們可以再Azure Portal的通知欄中找到 剛剛建立好的 “Traffic Manager profile” ，我們點選 “Go to resource”
3， 部署專案到新的Azure Web App
我們稍微修改一下程式碼（主要是為了區別流量到底是轉發到那個Web App的服務上的），Welcome後面新增上 cnBateBlogWeb01 的標識。
重新生成專案，選擇專案釋出
點選 ”新建“，選擇 ”應用服務“，Azure 應用服務 ”選擇現有“，點選 ”建立配置檔案“
選擇上面剛剛建立好的叫 ”CnBateBlogWeb01“ 的 Web App，點選 ”確定“
稍等片刻，等待VS的輸出控制檯顯示 釋出成功
這時候，瀏覽器會自動跳出來當前專案預設的一個二級域名，這個是時候當前頁面是會報錯了 500，這個不用擔心，是因為我們沒有去配置環境變數。
我們轉到Azure Portal的 CnBateBlogWeb01的 Web App , 點選 ”Setting“ => "Configuration"，今天新增配置
Name：ASPNETCORE_ENVIRONMENT
Value：Production
點選 ”OK“
可以看到，我們成功的配置好環境變數
回到瀏覽器中，我們再次重新整理頁面看看，頁面這次顯示沒有任何問題，我們在Welcome 後面打的標記 ”CnBateBlogWeb01“也在
4，新增 “Traffic Manager”的 enPoint
選擇 “Setting” =》"Endpoints"，點選 “Add” 新增終結點。
型別選擇預設的 “Azure endpoint”，Name輸入："cbbateblogweb_webapp_performance"，Target resouce type（目標資源型別） 選擇 ”App Service“，Target resource 選擇 "CnBateBlogWeb" 的Web App，點選 ”Add“。
我們可以看到剛剛新增好的節點資訊，Ststus 也是開啟的
重複步驟4，將剛剛建立好的叫 ”CnbateBlogWeb01“ 的 Web App 也加入到 Traffic Manager profile 的終結點中，下圖圈起來的是新增好的第二個終結點資訊
5，測試流量轉發
點選 ”overview“，複製 DNS name 到瀏覽器
我們，可以看到 流量被轉發到 CnBateBlogWeb 這個Web App 上了
為了能剛好的測試，我們之前選擇的 "Routing method" 為 "Performance"（基於效能的路由策略）,我這邊採用了谷歌瀏覽器的一個叫 "lighthouse"的一個網頁效能測試的一個工具，下圖我是直接訪問兩個web app預設的域名進行訪問測試結果的對比圖
這個是谷歌瀏覽器的除錯工具，我們也可以清楚的看到左邊的 CnBateBlogWeb 的 Web App 比右邊的 CnBateBlogWeb01 的 Web App 總耗時短
不好意思，由於我自己的才疏學淺，不知道怎麼才能把啟用一個Web App 服務的網路延遲手動干擾增大。
6，通過設定 Routing method為 ”Geographic“來轉發流量
接下來，我們建立一個新的 Traffic Manager profile ,設定的路由方式為 ”Geographic“，根據地理位置分配流量
Name：“tm01.cnbateblogweb”
Routing method：”Geographic“
點選 ”Create“
新增終結點的時候，有個特殊點需要注意一下，就是需要設定 ”Geo-mapping“，這意思是，比如，我們這裡配置的異地對映有 ”亞洲-中國“，”亞洲-韓國“，當用戶的請求是從這些地方請求過來的，Traffic Manager 會將這些請求轉發到 "CnBateBlogWeb（East Asia）" 這個目標資源。
Name：“tm01_cnbateblogweb_webapp_performance”
Target resource type：”App Service“
Target resource：”CnBateBlogWeb“
點選 ”Add“
重複上面的步驟，我們進行新增另外一個終結點資訊，異地對映選擇 ”澳洲-澳大利亞“，”亞洲-新加坡“
Name：“tm01_cnbateblogweb01_webapp_performance”
Target resource type：”App Service“
Target resource：”CnBateBlogWeb“
點選 ”Add“
我們複製當前 Traffic Manager profile 的 DNS name ,瀏覽器中輸入地址，顯示如下，確實跟我們配置的資訊一直，當前使用者的請求來自 中國的時候，會將流量轉發到 CnBateblogWeb 這個Web App。
轉到瀏覽器，我們看看結果
我們使用一種不可描述的方式，切換一下試試，當用戶的請求來自 韓國，當前 Traffic Manager 也會將流量轉發到 CnBateBlogWeb 這個 Web App.
我們再次切換不可描述的方式，我們可以看到，如果使用者的請求來自 新加坡，Traffic Manager 會將流量轉發到 ”CnBateBlogWeb01“ 這個 Web App 上。
我們再次切換不可描述的方式，我們可以看到，如果使用者的請求來自 澳大利亞，Traffic Manager 會將流量轉發到 ”CnBateBlogWeb01“ 這個 Web App 上。
ok，今天的分享到此結束。撒花，撒花！！！