Azure 提供負載均衡(一)Azure Traffic Manager 爲咱們的Web項目提供負載均衡

一,引言

  上一篇講到咱們將本身的Net Core Web 項目部署到 Azure 的 Web App 的一項 pass 服務,假如隨着項目的日益增加的訪問量,以前部署到單節點的應用可能沒法保證其穩定性,可能會致使系統宕機等等問題,這個時候,咱們就要考慮到項目的架構問題,怎麼保證項目的穩定性,好比:html

  1,縱向擴展,增長 Web App的訂價層git

Azure Portal 中找到咱們以前建立好的叫 「CnBateBlogWeb」 的 Web App,選擇 「App Service plan」 => "Change App Service plan",點擊 「Standard(S1)」的超連接。github

 

咱們能夠看到,當前咱們建立的Web App 的訂價層是 S1,爲100個計算單元,1.75G的內存,若是往後項目隨着業務訪問量的上漲沒法知足後,咱們能夠進行選擇升級,選擇一個合適的訂價層。同時,咱們也能夠點擊 」 See additional options 「 查看更多選項,好比 "Standard(P3V2)「  web

  2,橫向擴展:咱們能夠增長 Azure Web App 實例數,Azure 已經爲咱們提供了 縮放/擴展的功能, 咱們能夠選擇 」手動「/ 」自動「去縮放咱們的資源數據庫

可是今天,我採用第三種方式,假設咱們的架構是這個樣子的。瀏覽器

ok,第一種方案,我就再也不進行演示了,由於以前在使用部署槽的時候,我也是把應用程序計劃由一個 」Free「 改變成 」S1「,今天着重講一下第二種方式,開始內容以前,咱們先了解一下Azure 提供的另一個服務 」Traffic Manager「。服務器

-----------------------------題外話-----------------------------網絡

這時,有可能會有人出來擡槓了,說硬件方面能夠經過F5,軟件方面,咱們也能夠經過 Nginx 來實現,爲何還有額外使用什麼 」Azure Traffic Manager profile「。用這個還得收費。是沒錯,F5和 Nginx 均可以實現,但這不是重點,重點是去熟悉,瞭解Azure的這些服務。架構

--------------------我是分割線--------------------app

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,今天的分享到此結束。撒花,撒花!!!🎉🎉🎉🎉🎉

三,總結

今天將的內容也有些多,演示了兩種Traffic Manager 的路由策略,也同時複習了一下如何建立 Web App,以及使用 VS 發佈項目到 Azure Web App。

下一篇,咱們繼續介紹 Traffic Manager 剩下的4種路由策略,期待中........

做者:Allen 

項目代碼:https://github.com/yunqian44/CnBateBlogWeb.git

版權:轉載請在文章明顯位置註明做者及出處。如發現錯誤,歡迎批評指正。

相關文章
相關標籤/搜索