Windows平臺分散式架構實踐 - 負載均衡
概述
最近.NET的世界開始鬧騰了，微軟官方終於加入到了對.NET跨平臺的支援，並且在不久的將來，我們在VS裡面寫的程式碼可能就可以通過Mono直接在Linux和Mac上執行。那麼大家（開發者和企業）為什麼那麼的迫切的希望.NET跨平臺呢？第一個理由是便宜，淘寶號稱4萬多臺伺服器全部執行在Linux，Linux平臺下還有免費的MySql,這些都是免費的，這些省下來直接就是利潤呀，做企業的成本可以降低又沒有任何損失，何樂而不為呢？第二個理由是在Linux系統下還有很多非常優秀的構架（當然同樣也是免費的），分散式快取Memcached, 大資料處理構架Hadoop等等，這些都為一些大型的分散式系統提供了很好的支撐，當然還有諸如Liniux系統本身的一些安全和網路方面的優勢，等等。 所以也難怪大佬們都紛紛不約而同的沒有選擇.NET。
但是如果.NET也支援跨平臺之後，那這樣的格局可能就要發生變化了。上面所有的優勢依然可以保留，並且加上它語法的優越性，以及快速的開發效率等，還是會為其爭得一席之地的。
但是，是不是Windows平臺下就不能實現這些大型的分散式系統呢？我相信這個問題已經被廣泛討論過，但是至少我沒有看到比較清晰的，完整的案例。帶著這些問題，我決定升級我的機器，自己從頭到尾在windows平臺下搭建一個高可擴充套件性的分散式網站出來。我經驗尚淺，很多的東西還處於摸索階段，所以如果有錯誤，還請大師多多指點。
什麼是負載均衡
負載均衡可以幫我們解決兩個方面的問題，第一個即提高可用性。這裡面的可用性主要是從WEB伺服器，的角度來講的，如果說我們只有一臺Web伺服器，而它遇到了某種未知的錯誤導致IIS無法啟動，那麼我們的網站就無法訪問了，這就是一種比較低的可用性。那麼利用負載均衡，放在我們Web伺服器的前面，由它來收集所有的請求，然後轉發給我們的Web伺服器， 這時候我們就可以新增兩臺Web伺服器，如果其中有一臺壞了，至少還有另一臺在工作，也不至於導致我們的網路無法訪問。
當然，有人可能會問，如果那臺Load balancer壞了怎麼辦？那不是還是訪問不了網站麼？我們這裡討論的是提高可用性，在做到365天*24小時不間斷的服務，需要有另外的元件來支撐，我們留在後面討論。除了可用性以外，負載均衡還可以幫助我們提高可擴充套件性，當然這個可擴充套件性同樣是指的Web伺服器層面。從網站效能的角度來講，好幾個程式設計師花上好幾天的時間做了一些優化所帶來的效果有時候可能還沒有直接加一根記憶體條來的快。記憶體加完了沒什麼影響，我們還可以換更好的CPU，CPU換完了，我們還可以用固態硬碟，甚至很多公司已經開始直接把資料放到記憶體中了（注：具體場景具體對待）。 如果這些都不可以再加了呢？那就再加機器吧，一臺伺服器可以處理1000個併發，那麼兩臺理論上是2000了，所以這就有了我們的橫向擴充套件。
負責均衡器分發請求的型別
所有的請求首先全部到達Load balancer，再由它轉發到具體的Web伺服器，轉發的方式分為以下幾種：
- 輪轉排程(Round-robin):最簡單的方式，這種方式基本上不能算是負載均衡。第一個請求給web1，下一個給web2，再下一個給web3... 不會考慮某 一個伺服器是不是負荷太重等等。
- 基於權重的分配(Weight-based): 可以配置每一臺伺服器處理請求資料的比例，特別適合那種有某臺伺服器配置不一樣的場景。比如說某臺伺服器配置特別好，那我們可以讓它多處理一些請求。
- 隨機（Random): 隨機分配。
- 粘性session（Sticky Session): Load balancer會跟蹤請求，確保同一個session id的請求都交給同一樣伺服器。
- 最空閒優先（Least current request）：將最新的請求轉發給當前處理請求數量最小的那個伺服器。
- 響應時間優先(Response time)：哪臺伺服器當前響應時間最短就給哪臺。
- 使用者或URL引數選擇(User or URL information)：部分負載均衡器還提供根據一些引數來決定哪臺伺服器來處理，比如說根據使用者資訊，地址位置，URL引數，cookie資訊等 。
我們還可以根據負載均衡器所使用的技術將它們分為以下幾類：
- 反向代理：負載均衡器作為一個代理，同時維持著兩個TCP請求，從客戶端接收請求，然後將請求轉發給相應的Web 伺服器,等Web返回Response的時候是返回給了代理伺服器，然後再由代理伺服器轉交給真正的客戶端。這樣就會導致有一些功能不可用，比如在WEB伺服器環境檢視請求的來源IP實際上成了我們代理伺服器的IP等。
- 透明反向代理：和上面的代理伺服器一樣，只不過WEB伺服器從Request中獲取到的資訊是真正客戶端的資訊，就是好像沒有使用代理一樣的。
- 直接伺服器返回：通過更改WEB伺服器的MAC 地址來實現分發請求，在這種方式下，WEB伺服器不會像上面使用代理伺服器一樣，請求處理完之後是直接返回給客戶端的，所有相對於反向代理來說這種方式的效能會更快一些。
- NAT 負載均衡：NAT(Network Address Translation網路地址轉換)，將網路包（可以理解成TCP包）中的目標IP地址變成實現要處理這個請求的WEB伺服器的地址。
- Microsoft 網路負載均衡：Windows 自帶的負載均衡元件，一會我們就用它來做測試。
不使用負載均衡的測試結果
一臺獨立的伺服器
我們可以從一個網站的最初級版本開始說起，最開始的時候我們決定搭建一個網站，但是我們也不知道效果會怎麼樣，光鍵是那時候，我們很窮，於是我們租用了一臺託管主機，它可能承擔了至少三個或以上的角色：WEB伺服器、靜態資源伺服器，以及資料庫伺服器。我們可以用ASP.NET MVC4 + SQL 2008來做一個基本的電子商務網站，基本夠用了。但是能夠承載多大的訪問量呢？下面我們來做一個簡單的測試（注意：本文以後本系列所面所有的測試都是在虛擬機器上進行的，忽略網路的因素，以及多臺虛擬機器同時執行時CPU資源的因素，所以測試結果只是一個參考）。
在我的機器上有一臺虛擬機器配置如下：
CPU: Intel Core I5- 4570, 3.19GHz,
記憶體: 4G
硬碟：20G (ShineDisk 固態硬碟)
測試頁面沒有什麼複雜的邏輯，利用ASP.NET MVC4 + Entityframework 6.0 + SQL 2008 + IIS8.5來實現， 我們的頁面也只是一個簡單的列表頁，列出系統裡面所有的商品。
Home Controller 程式碼
Index.cshtml 程式碼
在資料庫初始化的時候插入500條測試資料
連線字串就使用本地連線就可以了。
|
1
2
3
|
<connectionStrings> <add name="CarolContext" connectionString="Server=localhost;database=carol;trusted_connection=true" providerName="System.Data.SqlClient" /></connectionStrings> |
我們使用的輕量級的ab來做壓力測試，如果不熟悉ab的可以點這裡，下面是測試的結果：
ab -n1000 -c100 http://192.168.1.131
通過測試發現，我們這單個伺服器的吞吐率接近在110~130之間，而一旦併發數達到200以後，每個請求的處理時間就達到1.5s多了，400個併發使用者的時候每個請求要花上3s多的時間。如果在真實的網路環境中可能會更差。由此我們可以得出我們這個伺服器可能最大支援120人左右同時訪問。
WEB伺服器與資料庫伺服器分離
現在我們來做一個花費不是很大，又空間做的擴充套件，也不需要改任何架構，我們只是再加一臺專門的資料庫伺服器。
下面我們再來看一下測試結果：
大家可以看到，這裡我們的吞吐率(每秒處理請求數已經提升到了150左右)，併發處理能力提升了50%，並且300和400併發的時候響應時間也比上面的架構要好一些。
使用負載均衡的測試結果
安裝網路負載均衡（NLB)
上面我們一臺獨立的Web伺服器和一臺獨立的資料庫伺服器的組合已經可以處理150左右的併發了，現在我們假想一下如果網站的的知名度越來越大，如果同時有400個使用者來訪問怎麼辦？
從上面的圖中我們可以看到400個併發的時候伺服器的處理時間為2582.637ms（實現上這是拿到響應的時間，因為我們是一臺機器上的不同虛擬機器，我是在主機上做測試，所以我們就忽略網路傳輸的時間，假設這個就是我們的伺服器處理時間），這個伺服器響應時間也就是我們通過F12->網路 中看到的等待時間
。
頁面什麼時候能拿到這個響應還要加上網路傳輸的時間，也就是Receiving。1ms的傳輸時間堪稱神速啊！我家用的長城寬頻10M，總是早上網路出奇的好，一到晚上就掛掉了，還有可能就是你們現在都沒有上部落格園 :)
使用者體驗黃金法則之一: 網站載入時間 = 使用者體驗，別說3S，可能等個2S你頁面還不出來，使用者準備離開了，下面是淘寶購物車頁面的載入時間 。
國內很多大型的網站的響應時間基本上都控制在100ms以內，基本達到那種一輸入地址敲回車，眨眼之間頁面就出來了。當然這並不是光有個負載均衡加幾臺web伺服器就能解決的，我們後來再來一步一步的實踐下去。 話說回來，我們上面的測試結果基本上只有併發為10的時候響應時間是在100ms以內的， 看來我們還有很長的一段路要走啊。
正所謂“最好的架構是進化而來的，而不是設計出來的” ，面對我們現在的瓶頸暫時通過負載均衡新增多臺Web伺服器就可以了。我們上面講到負載均衡器型別的時候有一種 Microsoft負載均衡，我們可以很輕鬆的通過伺服器管理器來將這些元件安裝到我們的伺服器中。 安裝我們就不講了，就是通過伺服器管理-> 新增角色和功能->在功能中選擇“網路負載均衡” 然後安裝就可以了。
注意：圖中的Load balancer實際上是不存在的，因為只要我們2臺Web伺服器安裝了網路負載平衡元件，在其中任意一臺上建立群集就可以了，圖是為了方便大家理解。
這樣的話我們的伺服器架構就成了下面這個樣子：
192.168.1.254 就是我們暴露的外部IP地址，訪問192.168.1.254的請求就會轉發給後面的兩臺WEB伺服器。
配置網路負載均衡
在我們為上面2臺WEB伺服器安裝NLB之後，我們在其中任意一臺上來新建群集，然後將另外一臺加入到這個群集中即可，我們就在web-01(192.168.1.130)上來新建這個群集。在建立群集之前，我們要確保這2臺伺服器都是使用的靜態IP，否則無法將他們加入到群集中。
- 在web-01(192.168.1.130)上從管理工具中開啟 網路負載均衡器
- 右擊“網路負載平衡群集”，選擇“新建群集”
- 在“新群集：連線”視窗中將 192.168.1.130新增為主機，點選下一步
- 進入 “新群集：主機引數”，直接下一步
- 進入 “新群集：群集IP地址”， 新增視窗中的“新增” 將192.168.1.254 新增到視窗中然後點選下一步
- 進入 “新群集：群集引數”，選擇“多播”然後點選下一步
- 進入 “新群集：埠規則”，選中全部，然後點選編輯
- 將埠範圍改成 80~80，協議選 “TCP”，相關性選“無”
- 點選確定回到主視窗，然後點選完成。
- 通過上面的步驟，我們已經建立了一個群集，並且將web-01加入到了群集中，我們還需要手動將web-02也加入到群集中。
- 在群集(192.168.1.254)上右鍵點選“新增主機到群集”
- 在“將主機新增到群集：連線”視窗中的 主機中輸入192.168.1.131然後後面一下點下一步即可。
現在我們就可以到我們的真實機器上去訪問192.168.1.254了，也就是說馬上我們就進入測試環節了。
測試結果
本文中所有的測試結果都沒有取第一次的結果，EF也需要預熱，同樣的查詢在EF中也是有快取的，所以第一次的結果會與後面的測試結果有很大的區別，後面的幾次（在相同引數下）基本差別就不大了。
可以看到現在我們的吞吐率大概平均在230左右，與一臺WEB伺服器+一臺DB伺服器相比，處理能力又提高了50%，為什麼不是100%呢？一臺WEB伺服器能處理150的併發，那兩臺應該是300才對呀？我能夠想到以下原因：
- 我們的資料庫伺服器只有一臺，資料庫的處理能力提不上去最終影響WEB伺服器的處理能力
- 我們採用的是虛擬機器，並非實際的機器，他們實際上是共用CPU，不知道在這種情況下對測試結果會不會有影響（虛擬化專家可以分享一下）。
為了驗證一下，我再擴充套件了一臺WEB伺服器，我們使用3臺WEB伺服器+1臺DB伺服器看看是什麼效果。
我們新建一臺虛擬機器web-03，然後將它也加入到我們的群集中。
測試開始！
在加入第三臺WEB伺服器之後，我們的吞吐率（每秒處理請求數）再次得到提升從230升至360，併發處理能力再次提升56%，並且大家可以看到，400併發以下的平均每請求處理時間都在1s以內，可喜可賀啊！
最後上兩圖讓大家更直觀的看一下這些效能的變化：
以上資料均來自本人機器上的測試，虛擬機器全部採用與第一臺伺服器同樣的配置。
小結
在網站架構的不斷演變中，負載均衡起著非常重要的位置，不僅僅為我們提升可靠性和可擴充套件性，有一些比較強大的硬體裝置還能提供快取，以及session機制。今天我們用到的負載均衡是Windows Server自帶的一個元件，它是最簡單實現負載均衡的方式，但是功能不是特別完善，而且一旦NLB本身發生錯誤那麼將導致所有的網站都不能訪問，我們後面就來通過引入APR(Application Request Router)來解決這個問題，想要真正瞭解大型網站的架構實現，而不是僅僅知道負載均衡，分散式快取，資料庫分離這些名詞麼？那就來跟我一起學習吧！另外我們今天只是用一個簡單的頁面做了壓力測試，只有讀資料的操作，還沒有寫的操作，也沒有任何複雜的事務，但是別擔心，我們一步一步來 :) 。
您還可以檢視本篇的續篇: Windows平臺下利用APM來做負載均衡方案 - 解決Session同步問題，以及徹底提高可用性。
作者：Jesse 原文地址：http://www.cnblogs.com/jesse2013/p/dlws-loadbalancer.html