負載均衡原理剖析與實踐：負載均衡第一篇-介紹篇

負載均衡第一篇-介紹篇

系列文章索引：

<a href="http://www.agilesharp.com/u/yanyangtian/Blog.aspx/t-197" target="_blank">負載均衡第一篇-介紹篇</a>

<a href="http://www.agilesharp.com/u/yanyangtian/Blog.aspx/t-202" target="_blank">負載均衡第二篇-負載均衡基礎知識普及</a>

前言：相信朋友們對負載均衡應該不陌生了！特别是對搞運維的朋友！可能很多的技術人員認為，負載均衡不是搞IT運維的人管的嗎，關我們開發人員什麼事情？曾經，我也是這樣想的，但是後來發現我錯了。開發人員，需要懂性能方面的問題，而負載均衡也是屬于性能的範疇，so…！如果開發人員想繼續不斷的提升自己，走向設計，架構的角色，那麼，你就必須對技術的有全面的把握和整體的評估，才能在項目中從軟體和硬體多方面考慮，真正的實作可用性，擴充性，靈活性。

    曾經經曆過很多的項目，特别實在做外包的時候，基本上涉及不到什麼性能的問題，極少涉及到負載均衡。當我接觸了網際網路之後，常常被人笑話我是搞企業開發的，不懂性能，于是我開始關注性能，也知道有負載均衡，那時候，感覺思維一下子被打開了，發現了一個不一樣的天地！但是負載均衡缺少很多的資料，網絡上很多的地方和文章都隻是講了點皮毛，剛要深入的時候，就沒了！

    技術，入門容易，學精難！不精，就沒有核心競争力，因為誰都懂，誰都可以替代你！是以要精！

    在這裡，我将會深入的剖析負載均衡的原理，使用！甚至你可以感覺到，之後，你可以自己寫一個負載均衡的軟體出來！之後，在分析問題，思考問題的時候，你會遊刃有餘！

    ….

    負載均衡已經不是什麼新的概念了，負載均衡也不僅僅就指的把一些伺服器放在一起實作分壓。負載均衡是一個統稱。而我們平時談的最多的就是伺服器負載均衡，全球負載均衡，防火牆負載均衡，緩存負載均衡！（在後面，會慢慢的講述各個方面）。

    就拿伺服器負載均衡而言，它主要是把請求分攤在多個伺服器資源上面。負載均衡還可以實作很精确的伺服器健康檢查機制，請求的轉發。另外，因為負載均衡部署在伺服器的前端，是以，它也可以包含伺服器免受惡意使用者的攻擊，提高安全。同時，還可以基于IP資料包中的資訊進行智能的選擇不同的程式，不同的伺服器來處理！

    負載均衡的必要性

随着網際網路的普及，越來越多的人開始線上使用服務。同時，也不能容忍網絡突然崩潰或者網速、服務的性能超低，特别是對于涉及到網上交易的應用而言，任何一點問題的出現，都是重大的經濟損失。為了保證提供更好，更穩定的服務，我們會不斷更新伺服器的相關裝置。

    雖然說根據摩爾定律：計算機的處理速度每18個月會翻一番。但是這個速度依然趕不上網際網路放在的速度和使用者對服務的需要，并且購買更好的裝置，不僅僅昂貴，成本效益也不理想。

    那麼這裡其實就已經涉及到了一個可伸縮性的挑戰。下面，我們就來看看一些常用的可伸縮性方案。

    正如之前所說的，計算機的更新速度無法趕上使用者需要，這個時候叢集技術就應用而生了，這個技術主要是那些大型計算機廠商提供的，叢集技術的提出在一定的程度上面緩和了之前的問題。下面，我們就來看看兩種比較典型的叢集技術：松耦合系統，對稱多處理器系統。

松耦合系統

    松耦合系統是由很多的完全相同的計算機塊組成，這些計算機塊之間通過系統的總線連接配接。其中，每一個塊都包含各種的處理器，記憶體，磁盤控制器，磁盤驅動，網絡接口等。其實，每個塊都可以看出是一個獨立的計算機，隻不過現在他們被聚在了一起。下面的草圖顯示這個關系：

<a href="http://www.agilesharp.com/Services/BlogAttachment.ashx?AttachmentID=111" target="_blank"></a>

    松耦合的計算機叢集系統采用處理器通信技術，講負責分攤到多個處理器上面。這個系統隻有在任務可以被分割的情況下發揮很好的伸縮性。例如，我們現在有一個任務要去傳回一個表中所有的資料，并且這個表中的資料已經分割成為了多個不同的檔案，放在磁盤上面。這個時候，采用松耦合的計算機叢集技術，就可以講查詢任務分為多個不同的并行的子任務去查詢，每個子任務去一個檔案中查找，最後将結果合并後傳回。

    但是，不是所有的任務都是可以被分割的。例如，有個任務需要去更新之前那個表中的某個字段，那麼此時，即使有這個更新任務被再次分割為小的子任務，但是因為需要更新的字段肯定是位于之間的一個檔案中的，那就是說：最後隻有一個子任務在真正執行，其餘的子任務在打混，閑了。

    另外，為了使得松耦合的計算機叢集系統擷取很好的伸縮性，這個系統還需要很多的技術去支援，也需要很多的人員維護，成本非常的高。

對稱多處理器系統

    對稱多處理器系統(SMP)采用多核共享記憶體（其實這也會導緻性能問題，現在很多的計算機，特别是多核的伺服器，都是采用的非對稱記憶體的方式，大家感興趣可以去研究下）。在這種系統中，為了達到很好的伸縮性，我們開發的應用程式必須采用多線程的技術（并且，也是需要将一個任務分為結果子任務來運作，而不同的子任務運作在不同的線程上面）。這些線程共享記憶體，并且通過内在的方式進行通信。同時，作業系統也會去排程這些線程，使得他們運作在多核上面。同樣，這個前面 的系統有這同樣類似的問題。

    OK，對之前的兩種方式就簡要的介紹一下。沒有深究，并且不是重點。

    下面，我們就看看負載均衡技術出現的一些基礎。

我們知道，傳統的交換機和路由器會根據資料包中的IP位址和MAC位址來決定将資料包發送到何處。但是，這個簡單的轉發能力無法滿足現在負責的Web Farm的需求。例如，傳統的路由器或交換機不能夠比較智能的将資料包發送給特定的應用程式、特定的伺服器等。即使有伺服器down了，路由器等還是會将資料包發給這個伺服器。

    那麼，我們到底如何來實作負載均衡呢？

    首先，我們還看看比較重要的一些理論基礎：OSI網絡模型,如圖

<a href="http://www.agilesharp.com/Services/BlogAttachment.ashx?AttachmentID=112" target="_blank"></a>

    這個圖，非常熟悉，我這裡隻是簡述一下！OSI，就是開放的網絡協定的标準了。從圖中可以看到，這OSI模型，定義了七層，從實體層一直到最上面的應用層。網絡協定，例如Tcp,UDP,IP，Http等分别對應模型中的不同層。其中IP協定處于第三層，TCP，UDP處理第四層。

大家就要問了？這個有啥用呢？

    我們又知道：傳統的路由器和交換器會位于OSI的第二或者第三層。也就說，它們決定了一個資料包必須如何被處理以及必須發往何處。盡管第二、三層的交換器做了非常了不起的事情，但是，其實在資料包的頭資訊中，有更多的有價值的資訊沒有被使用。如果我們在這個時候，将資料包擷取，然後分析裡面的頭資訊，然後将請求按照我們的需要進行轉發，那麼就可以在第二、層實作負載均衡等技術。這也是我們常常看到或者聽到的Layer 2/3 Switching。

    另外，如果在第四層到第七層中擷取資料包，分析頭資訊，然後按需轉發請求，就是所謂的“Layer 4 through 7 Switching”。在第四層中，TCP和UDP的頭中包含了大量的資訊，而這些資訊可以使得我們更加智能的實作請求的轉發。例如，當使用者發送Http請求到部署到Tcp 80端口的站點的時候,我們可以分析通過分析頭資訊得到這個資訊，進而可以将請求轉發到其他的伺服器上去。

    今天先到這裡，東西不多，廢話可能一大堆 J！

本文轉自yanyangtian51CTO部落格，原文連結： http://blog.51cto.com/yanyangtian/819848，如需轉載請自行聯系原作者