《Windows Azure Platform 系列文章目錄》
在筆者這幾年Azure售前工作中，經常會遇到客戶提同樣的問題：Azure 虛擬機的帶寬是多少？Azure提供獨享帶寬嗎？這個項目我們需要200兆的獨享帶寬。
當遇到這種情況的時候，筆者就會問客戶：請問您需要獨享帶寬的目的是什么呢？
客戶經常會回答：這個應用需要視頻(大文件)的上傳下載功能，或者是並發用戶數巨大，需要獨享帶寬來相應更多的Internet請求。
這種情況我表示非常理解，因為我們平時在購買電信寬帶的時候，都是購買30M，100MB一年，帶寬要求越高，價格越貴。
但是在公有雲平台，我們需要轉變我們的思維方式，利用雲計算彈性的優勢，獲得更好的收益。
針對這種獨享帶寬的問題，筆者詳細寫一篇文章，來介紹一下。主要內容分為以下幾節：
1.獨享帶寬的弊端
2.分析互聯網帶寬內容
3.相關案例分享
1.獨享帶寬的弊端
在中國，互聯網接入帶寬的費用是非常昂貴的。我問了其他同事，中國的互聯網帶寬費用大約是美國的20倍。獨享帶寬的價格顯而易見是非常昂貴的。
雲計算非常適合的場景包括：開關模式、爆發增長模式等。購買獨享帶寬不能體現雲計算彈性的優勢。如果購買了獨享的帶寬的情況下，客戶用不用雲計算，帶寬成本是必須支付的。假設用戶購買了200M獨享帶寬，結果項目上線后發現用戶量很少，互聯網帶寬閑置了，但是這200M帶寬費用還是必須支付的。
我們假設購買國內某雲計算廠商的獨享帶寬200M，從其官網上可以看到，1個月的費用約為17717元。如下圖：
Azure帶寬雖然是共享帶寬，在筆者的項目經驗中發現，一般情況下單台Azure A4 VM(8Core/14GB)的帶寬約為70MB。
對應該廠商的帶寬水平，3台Azure A4 VM (每台A4的配置為8Core/14GB)做負載均衡，可以提供近似200MB的獨享帶寬水平。但是3台Azure A4 VM，每個月的價格僅僅為12142元。如下圖：
相比該雲計算廠商的獨享帶寬200M的價格，微軟Azure的價格還是非常具有競爭優勢的。
另外微軟Azure的帶寬是隨着負載均衡服務器的數量增加而逐漸增加的。
當實際項目上線后發現互聯帶寬不夠怎么辦，把更多的Azure VM加入到負載均衡器上。當我們發現互聯網帶寬閑置了，則將部分Azure VM關閉即可。
比如筆者一個證券行業的客戶，他們在業務高峰期的時候(股票開市，早上9：30-下午3點)，利用約100台Azure虛擬機橫向擴展的能力，來處理大量的客戶端並發。在業務低谷的時候(股票休市)，利用少量的Azure虛擬機橫向擴展，用來節省成本。(Windows Azure具備Auto Scaling的能力，可以按照計划任務開啟或者關閉多台Azure虛擬機，整個過程都是自動化完成的。)這種橫向擴展的方式比該公司以往購買固定帶寬的成本要大大的減少。
這種Azure虛擬機動態增加/減少的優勢，可以幫助客戶極大的減少成本。
2.分析互聯網帶寬內容
客戶又說，我們的應用需要支撐10萬用戶在線進行視頻播放功能，我們需要獨享帶寬保證用戶體驗。
我們分析一下該場景。當我們瀏覽一個網站的時候，其內容可以分為以下幾個部分：
(1)靜態的HTML頁面
(2)靜態的文件，如視頻、照片、文檔等
(3)動態的編譯頁面，如ASPX，JSP等
當用戶訪問的視頻都是走主機(Azure VM)帶寬的話，毫無疑問主機帶寬越大越好。
但是請大家別忘記了，Azure Block Blob每個文件提供60MB/S的互聯網帶寬，一個Storage Account提供10GB/S的互聯網帶寬。
Azure Block Blob就類似於雲網盤。
我們只需要改變一下軟件架構：
- 動態編譯的頁面還是走主機帶寬
- 靜態的文件，比如視頻，保存到Azure Block Blob，例如地址為: http://leizhangstorage.blob.core.chinacloudapi.cn/videos/1.mp4
- 靜態的照片文件，保存到Azure Block Blob，例如：http://leizhangstorage.blob.core.chinacloudapi.cn/images/1.jpg
通過將靜態內容請求發送到Azure Storage，將動態內容的請求發送到Azure 雲主機，就可以大大減少雲主機獨享帶寬的的壓力。
接下來我們說一個案例。是我一個客戶將在線培訓系統遷移到Azure平台上。
(1)項目背景：企業A在線培訓系統，主要為企業內的員工進行在線視頻培訓。
(2)現有架構：客戶自建數據中心購買了60M獨享帶寬，所有的動態請求和靜態視頻文件都走該互聯網帶寬。
(3)痛點：當需要培訓的用戶量爆發性增長的時候，60M帶寬不能響應大並發請求。
客戶對視頻文件還有安全性的要求，不能通過CDN服務來加快視頻訪問。所以只能將視頻文件保存到Azure Storage，通過Azure Storage設置SAS Token來控制用戶訪問權限。
在將該在線培訓系統遷移到Azure雲平台之前，我們還在全國8個不同的城市(北京、上海、廣州、深圳、成都、杭州、青島、福州)進行了Azure Storage下載壓力測試，測試結果表明Azure Storage下載速度均達到了本地網絡可允許的最大下載速度。
該項目遷移到Azure雲平台的整理架構圖如下：
該項目為混合雲方式，既保留了本地數據中心的現有投入，又將視頻流保存到Azure Storage以響應大並發請求。
整體訪問流程如下：
(1)某員工通過手機應用，SSO單點登錄到IDC 負載均衡器上(Load Balancer)
(2)自建IDC數據中心的Web服務器將該請求生成一個Token，並且將Token發送到部署在Azure上的Web服務器。
(3)Azure Web服務器將該Token返回到IDC數據中心的Web上進行驗證，證明該請求是有效的。
(4)Token驗證通過后，Azure Web根據在線培訓系統的業務邏輯，通過用戶訪問的ID，分別訪問北京和上海的Storage Account。
如果用戶ID來自北方，則將位於中國北部(北京)的Azure Storage生成SAS(Shared Access Signature) 視頻URL返回給客戶端。
如果用戶ID來自南方，則將位於中國東部(上海)的Azure Storage生成SAS 視頻URL返回給客戶端。
最后員工手機應用的視頻鏈接地址，其實就是Azure 上海或北京的Storage生成的SAS URL。
客戶收益：
(1)Azure Web服務器只驗證了IDC數據中心發送的Token是否有效。所以視頻流量不經過Azure Web服務器。如下圖:
可以看到，在過去7天時間內，Azure Web服務器的輸出網絡流量和輸入網絡流量均不超過75MB
(2)Azure Storage用來保存視頻文件，並返回SAS URL。視頻流量都經過Azure Storage。如下圖：
可以看到，在過去7天，Azure Storage出口流量總計為276.5GB。
Ticky:
在之前的內容中，筆者介紹了Azure Block Blob每個文件提供60MB/S的互聯網帶寬，一個Storage Account提供10GB/S的互聯網帶寬。
如果用戶訪問量非常大，超過了單個文件60MB/S的互聯網帶寬怎么辦？很簡單，只要我們將一個視頻文件復制多個副本即可。
我們將一個視頻在同一個存儲賬號保存了6個副本，則一共有360MB/S的互聯網帶寬。
我又同時在北京和上海有2個存儲賬號，則總體的互聯網帶寬水平為720MB/S。非常驚人了。
筆者在Azure Web服務器上開發了一個小的程序，通過將不同的請求平均分配到不同的視頻文件上。避免出現所有用戶訪問同一個視頻文件，產生帶寬性能瓶頸。
該企業A的在線培訓系統遷移到Azure的雲平台的成本如下：
- 2台A1 Cloud Service，每月1011
- Azure Storage Account Block Blob，總容量40G，每月費用16.4元。
總體成本為每年12338元。還不夠買國內某雲計算廠商的獨享帶寬200M一個月呢。
有人會問流量費用怎么計算，別忘記了Azure企業級合同每個月免費20TB上下行的流量。從該企業現有的使用情況來說，流量就是免費贈送的。
========================================================分隔符==========================================================
好了，我分享了好的案例。我們再討論一個不怎么成功的案例。
某企業B將微信平台整體遷移到Azure雲平台，因為其微信平台擁有300萬粉絲，所以訪問量也非常大。
這里面牽涉到的負載均衡器的技術點，如下圖：
微軟建議的負載均衡模式如上圖左側，通過將多個Azure VM防止在負載均衡器的后端，響應Internet的請求。
而企業B的軟件開發商只用一台Azure VM作為前置機，如上圖右側圖VM1。所有的用戶請求都發送到VM1上，再通過VM1的內網IP，分流到VM2和VM3上。
這種架構的缺點有2個：
(1)雖然VM3分攤了出站流量，但是VM1的公網入站流量會非常大。
(2)VM1會出現單點故障，如果VM1宕機了，則整個應用平台不可用。
另外客戶低估了並發用戶的請求，在項目上線之前把VM2關機了。整個架構中只有VM1和VM3在運行。
而且客戶沒有把靜態文件保存到Azure Storage中，所有的請求都是走主機帶寬，壓力會非常大。
項目上線后，立刻出現問題。如下圖：
VM1這台前置機5分鍾內的輸入流量為9.28GB，輸出流量帶寬為3.05GB。網絡直接卡死。服務宕機。
經過這次不成功的經驗，總結如下：
(1)需要提前和客戶溝通，做好上線評估
(2)將文件占用主機帶寬的弊端想客戶說明。同時建議將靜態文件保存至Azure Storage，避免占用主機帶寬。