最近.NET的世界開(kāi)始鬧騰了，微軟官方終于加入到了對(duì).NET跨平臺(tái)的支持，并且在不久的將來(lái)，我們?cè)赩S里面寫(xiě)的代碼可能就可以通過(guò)Mono直接在Linux和Mac上運(yùn)行。那么大家(開(kāi)發(fā)者和企業(yè))為什么那么的迫切的希望.NET跨平臺(tái)呢?第一個(gè)理由是便宜，淘寶號(hào)稱4萬(wàn)多臺(tái)服務(wù)器全部運(yùn)行在Linux，Linux平臺(tái)下還有免費(fèi)的MySql,這些都是免費(fèi)的，這些省下來(lái)直接就是利潤(rùn)呀，做企業(yè)的成本可以降低又沒(méi)有任何損失，何樂(lè)而不為呢?第二個(gè)理由是在Linux系統(tǒng)下還有很多非常優(yōu)秀的構(gòu)架(當(dāng)然同樣也是免費(fèi)的)，分布式緩存Memcached, 大數(shù)據(jù)處理構(gòu)架Hadoop等等，這些都為一些大型的分布式系統(tǒng)提供了很好的支撐，當(dāng)然還有諸如Liniux系統(tǒng)本身的一些安全和網(wǎng)絡(luò)方面的優(yōu)勢(shì)，等等。 所以也難怪大佬們都紛紛不約而同的沒(méi)有選擇.NET。

但是如果.NET也支持跨平臺(tái)之后，那這樣的格局可能就要發(fā)生變化了。上面所有的優(yōu)勢(shì)依然可以保留，并且加上它語(yǔ)法的優(yōu)越性，以及快速的開(kāi)發(fā)效率等，還是會(huì)為其爭(zhēng)得一席之地的。

但是，是不是Windows平臺(tái)下就不能實(shí)現(xiàn)這些大型的分布式系統(tǒng)呢?我相信這個(gè)問(wèn)題已經(jīng)被廣泛討論過(guò)，但是至少我沒(méi)有看到比較清晰的，完整的案例。帶著這些問(wèn)題，我決定升級(jí)我的機(jī)器，自己從頭到尾在windows平臺(tái)下搭建一個(gè)高可擴(kuò)展性的分布式網(wǎng)站出來(lái)。我經(jīng)驗(yàn)尚淺，很多的東西還處于摸索階段，所以如果有錯(cuò)誤，還請(qǐng)大師多多指點(diǎn)。

什么是負(fù)載均衡

負(fù)載均衡可以幫我們解決兩個(gè)方面的問(wèn)題，第一個(gè)即提高可用性。這里面的可用性主要是從WEB服務(wù)器，的角度來(lái)講的，如果說(shuō)我們只有一臺(tái)Web服務(wù)器，而它遇到了某種未知的錯(cuò)誤導(dǎo)致IIS無(wú)法啟動(dòng)，那么我們的網(wǎng)站就無(wú)法訪問(wèn)了，這就是一種比較低的可用性。那么利用負(fù)載均衡，放在我們Web服務(wù)器的前面，由它來(lái)收集所有的請(qǐng)求，然后轉(zhuǎn)發(fā)給我們的Web服務(wù)器， 這時(shí)候我們就可以添加兩臺(tái)Web服務(wù)器，如果其中有一臺(tái)壞了，至少還有另一臺(tái)在工作，也不至于導(dǎo)致我們的網(wǎng)絡(luò)無(wú)法訪問(wèn)。

 

 

當(dāng)然，有人可能會(huì)問(wèn)，如果那臺(tái)Load balancer壞了怎么辦?那不是還是訪問(wèn)不了網(wǎng)站么?我們這里討論的是提高可用性，在做到365天*24小時(shí)不間斷的服務(wù)，需要有另外的組件來(lái)支撐，我們留在后面討論。除了可用性以外，負(fù)載均衡還可以幫助我們提高可擴(kuò)展性，當(dāng)然這個(gè)可擴(kuò)展性同樣是指的Web服務(wù)器層面。從網(wǎng)站性能的角度來(lái)講，好幾個(gè)程序員花上好幾天的時(shí)間做了一些優(yōu)化所帶來(lái)的效果有時(shí)候可能還沒(méi)有直接加一根內(nèi)存條來(lái)的快。內(nèi)存加完了沒(méi)什么影響，我們還可以換更好的CPU，CPU換完了，我們還可以用固態(tài)硬盤(pán)，甚至很多公司已經(jīng)開(kāi)始直接把數(shù)據(jù)放到內(nèi)存中了(注：具體場(chǎng)景具體對(duì)待)。 如果這些都不可以再加了呢?那就再加機(jī)器吧，一臺(tái)服務(wù)器可以處理1000個(gè)并發(fā)，那么兩臺(tái)理論上是2000了，所以這就有了我們的橫向擴(kuò)展。

 

 

負(fù)責(zé)均衡器分發(fā)請(qǐng)求的類(lèi)型

所有的請(qǐng)求首先全部到達(dá)Load balancer，再由它轉(zhuǎn)發(fā)到具體的Web服務(wù)器，轉(zhuǎn)發(fā)的方式分為以下幾種：

輪轉(zhuǎn)調(diào)度(Round-robin):最簡(jiǎn)單的方式，這種方式基本上不能算是負(fù)載均衡。第一個(gè)請(qǐng)求給web1，下一個(gè)給web2，再下一個(gè)給web3... 不會(huì)考慮某 一個(gè)服務(wù)器是不是負(fù)荷太重等等。

基于權(quán)重的分配(Weight-based): 可以配置每一臺(tái)服務(wù)器處理請(qǐng)求數(shù)據(jù)的比例，特別適合那種有某臺(tái)服務(wù)器配置不一樣的場(chǎng)景。比如說(shuō)某臺(tái)服務(wù)器配置特別好，那我們可以讓它多處理一些請(qǐng)求。

隨機(jī)(Random): 隨機(jī)分配。

粘性session(Sticky Session): Load balancer會(huì)跟蹤請(qǐng)求，確保同一個(gè)session id的請(qǐng)求都交給同一樣服務(wù)器。

最空閑優(yōu)先(Least current request)：將最新的請(qǐng)求轉(zhuǎn)發(fā)給當(dāng)前處理請(qǐng)求數(shù)量最小的那個(gè)服務(wù)器。

響應(yīng)時(shí)間優(yōu)先(Response time)：哪臺(tái)服務(wù)器當(dāng)前響應(yīng)時(shí)間最短就給哪臺(tái)。

用戶或URL參數(shù)選擇(User or URL information)：部分負(fù)載均衡器還提供根據(jù)一些參數(shù)來(lái)決定哪臺(tái)服務(wù)器來(lái)處理，比如說(shuō)根據(jù)用戶信息，地址位置，URL參數(shù)，cookie信息等 。

我們還可以根據(jù)負(fù)載均衡器所使用的技術(shù)將它們分為以下幾類(lèi)：

反向代理：負(fù)載均衡器作為一個(gè)代理，同時(shí)維持著兩個(gè)TCP請(qǐng)求，從客戶端接收請(qǐng)求，然后將請(qǐng)求轉(zhuǎn)發(fā)給相應(yīng)的Web 服務(wù)器,等Web返回Response的時(shí)候是返回給了代理服務(wù)器，然后再由代理服務(wù)器轉(zhuǎn)交給真正的客戶端。這樣就會(huì)導(dǎo)致有一些功能不可用，比如在WEB服務(wù)器環(huán)境查看請(qǐng)求的來(lái)源IP實(shí)際上成了我們代理服務(wù)器的IP等。

透明反向代理：和上面的代理服務(wù)器一樣，只不過(guò)WEB服務(wù)器從Request中獲取到的信息是真正客戶端的信息，就是好像沒(méi)有使用代理一樣的。

直接服務(wù)器返回：通過(guò)更改WEB服務(wù)器的MAC 地址來(lái)實(shí)現(xiàn)分發(fā)請(qǐng)求，在這種方式下，WEB服務(wù)器不會(huì)像上面使用代理服務(wù)器一樣，請(qǐng)求處理完之后是直接返回給客戶端的，所有相對(duì)于反向代理來(lái)說(shuō)這種方式的性能會(huì)更快一些。

NAT 負(fù)載均衡：NAT(Network Address Translation網(wǎng)絡(luò)地址轉(zhuǎn)換)，將網(wǎng)絡(luò)包(可以理解成TCP包)中的目標(biāo)IP地址變成實(shí)現(xiàn)要處理這個(gè)請(qǐng)求的WEB服務(wù)器的地址。

Microsoft 網(wǎng)絡(luò)負(fù)載均衡：Windows 自帶的負(fù)載均衡組件，一會(huì)我們就用它來(lái)做測(cè)試。

不使用負(fù)載均衡的測(cè)試結(jié)果

一臺(tái)獨(dú)立的服務(wù)器

我們可以從一個(gè)網(wǎng)站的最初級(jí)版本開(kāi)始說(shuō)起，最開(kāi)始的時(shí)候我們決定搭建一個(gè)網(wǎng)站，但是我們也不知道效果會(huì)怎么樣，光鍵是那時(shí)候，我們很窮，于是我們租用了一臺(tái)托管主機(jī)，它可能承擔(dān)了至少三個(gè)或以上的角色：WEB服務(wù)器、靜態(tài)資源服務(wù)器，以及數(shù)據(jù)庫(kù)服務(wù)器。我們可以用ASP.NET MVC4 + SQL 2008來(lái)做一個(gè)基本的電子商務(wù)網(wǎng)站，基本夠用了。但是能夠承載多大的訪問(wèn)量呢?下面我們來(lái)做一個(gè)簡(jiǎn)單的測(cè)試(注意：本文以后本系列所面所有的測(cè)試都是在虛擬機(jī)上進(jìn)行的，忽略網(wǎng)絡(luò)的因素，以及多臺(tái)虛擬機(jī)同時(shí)運(yùn)行時(shí)CPU資源的因素，所以測(cè)試結(jié)果只是一個(gè)參考)。

在我的機(jī)器上有一臺(tái)虛擬機(jī)配置如下：

CPU: Intel Core I5- 4570, 3.19GHz,

內(nèi)存: 4G

硬盤(pán)：20G (ShineDisk 固態(tài)硬盤(pán))

測(cè)試頁(yè)面沒(méi)有什么復(fù)雜的邏輯，利用ASP.NET MVC4 + Entityframework 6.0 + SQL 2008 + IIS8.5來(lái)實(shí)現(xiàn)， 我們的頁(yè)面也只是一個(gè)簡(jiǎn)單的列表頁(yè)，列出系統(tǒng)里面所有的商品。

Home Controller 代碼

 

 

Index.cshtml 代碼

 

 

在數(shù)據(jù)庫(kù)初始化的時(shí)候插入500條測(cè)試數(shù)據(jù)

 

 

連接字符串就使用本地連接就可以了。

1

2

3

 

我們使用的輕量級(jí)的ab來(lái)做壓力測(cè)試，如果不熟悉ab的可以點(diǎn)這里，下面是測(cè)試的結(jié)果：

ab -n1000 -c100 http://192.168.1.131

 

 

通過(guò)測(cè)試發(fā)現(xiàn)，我們這單個(gè)服務(wù)器的吞吐率接近在110~130之間，而一旦并發(fā)數(shù)達(dá)到200以后，每個(gè)請(qǐng)求的處理時(shí)間就達(dá)到1.5s多了，400個(gè)并發(fā)用戶的時(shí)候每個(gè)請(qǐng)求要花上3s多的時(shí)間。如果在真實(shí)的網(wǎng)絡(luò)環(huán)境中可能會(huì)更差。由此我們可以得出我們這個(gè)服務(wù)器可能最大支持120人左右同時(shí)訪問(wèn)。

WEB服務(wù)器與數(shù)據(jù)庫(kù)服務(wù)器分離

現(xiàn)在我們來(lái)做一個(gè)花費(fèi)不是很大，又空間做的擴(kuò)展，也不需要改任何架構(gòu)，我們只是再加一臺(tái)專(zhuān)門(mén)的數(shù)據(jù)庫(kù)服務(wù)器。

 

 

下面我們?cè)賮?lái)看一下測(cè)試結(jié)果：

 

 

大家可以看到，這里我們的吞吐率(每秒處理請(qǐng)求數(shù)已經(jīng)提升到了150左右)，并發(fā)處理能力提升了50%，并且300和400并發(fā)的時(shí)候響應(yīng)時(shí)間也比上面的架構(gòu)要好一些。#p#

使用負(fù)載均衡的測(cè)試結(jié)果

安裝網(wǎng)絡(luò)負(fù)載均衡(NLB)

上面我們一臺(tái)獨(dú)立的Web服務(wù)器和一臺(tái)獨(dú)立的數(shù)據(jù)庫(kù)服務(wù)器的組合已經(jīng)可以處理150左右的并發(fā)了，現(xiàn)在我們假想一下如果網(wǎng)站的的知名度越來(lái)越大，如果同時(shí)有400個(gè)用戶來(lái)訪問(wèn)怎么辦? 從上面的圖中我們可以看到400個(gè)并發(fā)的時(shí)候服務(wù)器的處理時(shí)間為2582.637ms(實(shí)現(xiàn)上這是拿到響應(yīng)的時(shí)間，因?yàn)槲覀兪且慌_(tái)機(jī)器上的不同虛擬機(jī)，我是在主機(jī)上做測(cè)試，所以我們就忽略網(wǎng)絡(luò)傳輸?shù)臅r(shí)間，假設(shè)這個(gè)就是我們的服務(wù)器處理時(shí)間)，這個(gè)服務(wù)器響應(yīng)時(shí)間也就是我們通過(guò)F12->網(wǎng)絡(luò) 中看到的等待時(shí)間 。

 

 

頁(yè)面什么時(shí)候能拿到這個(gè)響應(yīng)還要加上網(wǎng)絡(luò)傳輸?shù)臅r(shí)間，也就是Receiving。1ms的傳輸時(shí)間堪稱神速啊!我家用的長(zhǎng)城寬帶10M，總是早上網(wǎng)絡(luò)出奇的好，一到晚上就掛掉了，還有可能就是你們現(xiàn)在都沒(méi)有上博客園 :)

用戶體驗(yàn)黃金法則之一: 網(wǎng)站加載時(shí)間 = 用戶體驗(yàn)，別說(shuō)3S，可能等個(gè)2S你頁(yè)面還不出來(lái)，用戶準(zhǔn)備離開(kāi)了，下面是淘寶購(gòu)物車(chē)頁(yè)面的加載時(shí)間 。

 

 

國(guó)內(nèi)很多大型的網(wǎng)站的響應(yīng)時(shí)間基本上都控制在100ms以內(nèi)，基本達(dá)到那種一輸入地址敲回車(chē)，眨眼之間頁(yè)面就出來(lái)了。當(dāng)然這并不是光有個(gè)負(fù)載均衡加幾臺(tái)web服務(wù)器就能解決的，我們后來(lái)再來(lái)一步一步的實(shí)踐下去。 話說(shuō)回來(lái)，我們上面的測(cè)試結(jié)果基本上只有并發(fā)為10的時(shí)候響應(yīng)時(shí)間是在100ms以內(nèi)的， 看來(lái)我們還有很長(zhǎng)的一段路要走啊。

正所謂“最好的架構(gòu)是進(jìn)化而來(lái)的，而不是設(shè)計(jì)出來(lái)的” ，面對(duì)我們現(xiàn)在的瓶頸暫時(shí)通過(guò)負(fù)載均衡添加多臺(tái)Web服務(wù)器就可以了。我們上面講到負(fù)載均衡器類(lèi)型的時(shí)候有一種 Microsoft負(fù)載均衡，我們可以很輕松的通過(guò)服務(wù)器管理器來(lái)將這些組件安裝到我們的服務(wù)器中。 安裝我們就不講了，就是通過(guò)服務(wù)器管理-> 添加角色和功能->在功能中選擇“網(wǎng)絡(luò)負(fù)載均衡” 然后安裝就可以了。

 

 

注意：圖中的Load balancer實(shí)際上是不存在的，因?yàn)橹灰覀?臺(tái)Web服務(wù)器安裝了網(wǎng)絡(luò)負(fù)載平衡組件，在其中任意一臺(tái)上建立群集就可以了，圖是為了方便大家理解。

這樣的話我們的服務(wù)器架構(gòu)就成了下面這個(gè)樣子：

 

 

192.168.1.254 就是我們暴露的外部IP地址，訪問(wèn)192.168.1.254的請(qǐng)求就會(huì)轉(zhuǎn)發(fā)給后面的兩臺(tái)WEB服務(wù)器。#p#

配置網(wǎng)絡(luò)負(fù)載均衡

在我們?yōu)樯厦?臺(tái)WEB服務(wù)器安裝NLB之后，我們?cè)谄渲腥我庖慌_(tái)上來(lái)新建群集，然后將另外一臺(tái)加入到這個(gè)群集中即可，我們就在web-01(192.168.1.130)上來(lái)新建這個(gè)群集。在建立群集之前，我們要確保這2臺(tái)服務(wù)器都是使用的靜態(tài)IP，否則無(wú)法將他們加入到群集中。

在web-01(192.168.1.130)上從管理工具中打開(kāi) 網(wǎng)絡(luò)負(fù)載均衡器

右擊“網(wǎng)絡(luò)負(fù)載平衡群集”，選擇“新建群集”

 

 

在“新群集：連接”窗口中將 192.168.1.130添加為主機(jī)，點(diǎn)擊下一步

進(jìn)入 “新群集：主機(jī)參數(shù)”，直接下一步

進(jìn)入 “新群集：群集IP地址”， 添加窗口中的“添加” 將192.168.1.254 添加到窗口中然后點(diǎn)擊下一步

 

 

 

 

進(jìn)入 “新群集：群集參數(shù)”，選擇“多播”然后點(diǎn)擊下一步

進(jìn)入 “新群集：端口規(guī)則”，選中全部，然后點(diǎn)擊編輯

 

 

將端口范圍改成 80~80，協(xié)議選 “TCP”，相關(guān)性選“無(wú)”

 

 

點(diǎn)擊確定回到主窗口，然后點(diǎn)擊完成。

通過(guò)上面的步驟，我們已經(jīng)建立了一個(gè)群集，并且將web-01加入到了群集中，我們還需要手動(dòng)將web-02也加入到群集中。

 

 

在群集(192.168.1.254)上右鍵點(diǎn)擊“添加主機(jī)到群集”

在“將主機(jī)添加到群集：連接”窗口中的 主機(jī)中輸入192.168.1.131然后后面一下點(diǎn)下一步即可。

 

 

現(xiàn)在我們就可以到我們的真實(shí)機(jī)器上去訪問(wèn)192.168.1.254了，也就是說(shuō)馬上我們就進(jìn)入測(cè)試環(huán)節(jié)了。

測(cè)試結(jié)果

本文中所有的測(cè)試結(jié)果都沒(méi)有取第一次的結(jié)果，EF也需要預(yù)熱，同樣的查詢?cè)贓F中也是有緩存的，所以第一次的結(jié)果會(huì)與后面的測(cè)試結(jié)果有很大的區(qū)別，后面的幾次(在相同參數(shù)下)基本差別就不大了。

 

 

可以看到現(xiàn)在我們的吞吐率大概平均在230左右，與一臺(tái)WEB服務(wù)器+一臺(tái)DB服務(wù)器相比，處理能力又提高了50%，為什么不是100%呢?一臺(tái)WEB服務(wù)器能處理150的并發(fā)，那兩臺(tái)應(yīng)該是300才對(duì)呀?我能夠想到以下原因：

我們的數(shù)據(jù)庫(kù)服務(wù)器只有一臺(tái)，數(shù)據(jù)庫(kù)的處理能力提不上去最終影響WEB服務(wù)器的處理能力

我們采用的是虛擬機(jī)，并非實(shí)際的機(jī)器，他們實(shí)際上是共用CPU，不知道在這種情況下對(duì)測(cè)試結(jié)果會(huì)不會(huì)有影響(虛擬化專(zhuān)家可以分享一下)。

為了驗(yàn)證一下，我再擴(kuò)展了一臺(tái)WEB服務(wù)器，我們使用3臺(tái)WEB服務(wù)器+1臺(tái)DB服務(wù)器看看是什么效果。

 

 

我們新建一臺(tái)虛擬機(jī)web-03，然后將它也加入到我們的群集中。

 

 

測(cè)試開(kāi)始!

 

 

在加入第三臺(tái)WEB服務(wù)器之后，我們的吞吐率(每秒處理請(qǐng)求數(shù))再次得到提升從230升至360，并發(fā)處理能力再次提升56%，并且大家可以看到，400并發(fā)以下的平均每請(qǐng)求處理時(shí)間都在1s以內(nèi)，可喜可賀啊!

最后上兩圖讓大家更直觀的看一下這些性能的變化：

 

 

 

 

以上數(shù)據(jù)均來(lái)自本人機(jī)器上的測(cè)試，虛擬機(jī)全部采用與第一臺(tái)服務(wù)器同樣的配置。

小結(jié)

在網(wǎng)站架構(gòu)的不斷演變中，負(fù)載均衡起著非常重要的位置，不僅僅為我們提升可靠性和可擴(kuò)展性，有一些比較強(qiáng)大的硬件設(shè)備還能提供緩存，以及session機(jī)制。今天我們用到的負(fù)載均衡是Windows Server自帶的一個(gè)組件，它是最簡(jiǎn)單實(shí)現(xiàn)負(fù)載均衡的方式，但是功能不是特別完善，而且一旦NLB本身發(fā)生錯(cuò)誤那么將導(dǎo)致所有的網(wǎng)站都不能訪問(wèn)，我們后面就來(lái)通過(guò)引入APR(Application Request Router)來(lái)解決這個(gè)問(wèn)題，想要真正了解大型網(wǎng)站的架構(gòu)實(shí)現(xiàn)，而不是僅僅知道負(fù)載均衡，分布式緩存，數(shù)據(jù)庫(kù)分離這些名詞么?那就來(lái)跟我一起學(xué)習(xí)吧!另外我們今天只是用一個(gè)簡(jiǎn)單的頁(yè)面做了壓力測(cè)試，只有讀數(shù)據(jù)的操作，還沒(méi)有寫(xiě)的操作，也沒(méi)有任何復(fù)雜的事務(wù)，但是別擔(dān)心，我們一步一步來(lái) :) 。