大型網站技術架構（六）--網站的伸縮性架構

大型網站技術架構（一）--大型網站架構演化

大型網站技術架構（二）--架構模式

大型網站技術架構（三）--架構核心要素

大型網站技術架構（四）--網站的高效能架構

大型網站技術架構（五）--網站高可用架構

 

 

         網站系統的伸縮性架構最重要的技術手段就是使用伺服器叢集功能，通過不斷地向叢集中新增伺服器來增強整個叢集的處理能力。“伸”即網站的規模和伺服器的規模總是在不斷擴大。

1、網站架構的伸縮性設計

網站的伸縮性設計可以分成兩類，一類是根據功能進行物理分離實現伸縮，一類是單一功能通過叢集實現伸縮。前者是不同的伺服器部署不同的服務，提供不同的 功能；後者是叢集內的多臺伺服器部署相同的服務，提供相關的功能。

1.1 不同功能進行物理分離實現伸縮

         縱向分離：即分層後分離，將業務處理流程上的不同部分分離部署，實現系統伸縮性。

         橫向分離：即分割業務後分離，將不同的業務模組分離部署，實現系統伸縮性。

1.2 單一功能通過你叢集規模實現伸縮

       當一頭牛拉不動車的時候，不要去尋找一頭更強壯的牛，而是用兩頭牛來拉車。
      叢集伸縮性又分為應用伺服器叢集伸縮性和資料伺服器叢集伸縮性。資料伺服器叢集也可分為快取資料伺服器叢集和儲存資料伺服器叢集。

2、 應用伺服器叢集的伸縮性設計

        所謂應用伺服器的伸縮性即：HTTP請求分發裝置可以感知或者可以配置叢集的伺服器數量，可以及時發現叢集中新上線或下線的伺服器，並能向新上線的伺服器分發請求 ，停止向已下線的伺服器分發請求。這個HTTP請求分發裝置被稱為負載均衡伺服器。
       負載均衡是網站必不可少的基礎技術手段，不但可以實現網站的伸縮性，同時還改善網站的可用性，可謂網站的殺手鐗之一。具體的技術實現也多種多樣，從硬體實現到軟體實現， 從商業產品到開源，應有盡有，但實現負載均衡的基礎技術不外以下幾種。

2.1 HTTP重定向負載均衡

        HTTP重定向伺服器是一臺普通的應用伺服器，其唯一的功能就是根據使用者的HTTP請求計算一臺真實的伺服器地址，並將真實的伺服器地址寫入HTTP重定向響應中（響應狀態嗎302）返回給瀏覽器，然後瀏覽器再自動請求真實的伺服器。

        這種負載均衡方案的優點是比較簡單，缺點是瀏覽器需要每次請求兩次伺服器才能拿完成一次訪問，效能較差；使用HTTP302響應嗎重定向，可能是搜尋引擎判斷為SEO作弊，降低搜尋排名。重定向伺服器自身的處理能力有可能成為瓶頸。因此這種方案在實際使用中並不見多。

2.2 DNS域名解析負載均衡

      利用DNS處理域名解析請求的同時進行負載均衡是另一種常用的方案。在DNS伺服器中配置多個A記錄，如：www.mysite.com IN A 114.100.80.1、www.mysite.com IN A 114.100.80.2、www.mysite.com IN A 114.100.80.3.

      每次域名解析請求都會根據負載均衡演算法計算一個不同的IP地址返回，這樣A記錄中配置的多個伺服器就構成一個叢集，並可以實現負載均衡。

      DNS域名解析負載均衡的優點是將負載均衡工作交給DNS，省略掉了網路管理的麻煩，缺點就是DNS可能快取A記錄，不受網站控制。

     事實上，大型網站總是部分使用DNS域名解析，作為第一級負載均衡手段，然後再在內部做第二級負載均衡。 

2.3 反向代理負載均衡

      前面我們已經講過，反向代理可以快取資源，改善網站效能，事實上，反向代理業可以做負載均衡，如圖所示。

      由於反向代理伺服器轉發請求在HTTP協議層面，因此也叫應用層負載均衡。優點是部署簡單，缺點是可能成功系統的瓶頸。

2.4 IP負載均衡

       IP負載均衡：即在網路層通過修改請求目標地址進行負載均衡。

       使用者請求資料包到達負載均衡伺服器後，負載均衡伺服器在作業系統核心進行獲取網路資料包，根據負載均衡演算法計算得到一臺真實的WEB伺服器地址，然後將資料包的IP地址修改為真實的WEB伺服器地址，不需要通過使用者程式處理。真實的WEB伺服器處理完畢後，相應資料包回到負載均衡伺服器，負載均衡伺服器再將資料包源地址修改為自身的IP地址傳送給使用者瀏覽器。

       這裡的關鍵在於真實WEB伺服器相應資料包如何返回給負載均衡伺服器，一種是負載均衡伺服器在修改目的IP地址的同時修改源地址，將資料包源地址改為自身的IP，即源地址轉換（SNAT），另一種方案是將負載均衡伺服器同時作為真實物理伺服器的閘道器伺服器，這樣所有的資料都會到達負載均衡伺服器。

       IP負載均衡在核心程式完成資料分發，較反向代理均衡有更好的處理效能。但由於所有請求響應的資料包都需要經過負載均衡伺服器，因此負載均衡的網路卡頻寬成為系統的瓶頸。

2.5 資料鏈路層負載均衡

        顧名思義：資料鏈路層負載均衡是指在通訊協議的資料鏈路層修改mac地址進行負載均衡，如下圖：

        這種資料傳輸方式又稱作三角傳輸模式，負載均衡資料分發過程中不修改IP地址，只修改目的的mac地址，通過配置真實物理伺服器叢集所有機器虛擬IP和負載均衡伺服器IP地址一樣，從而達到負載均衡，這種負載均衡方式又稱為直接路由方式（DR）.

        在上圖中，使用者請求到達負載均衡伺服器後，負載均衡伺服器將請求資料的目的mac地址修改為真是WEB伺服器的mac地址，並不修改資料包目標IP地址，因此資料可以正常到達目標WEB伺服器，該伺服器在處理完資料後可以經過網管伺服器而不是負載均衡伺服器直接到達使用者瀏覽器。

        使用三角傳輸模式的鏈路層負載均衡是目前大型網站所使用的最廣的一種負載均衡手段。在linux平臺上最好的鏈路層負載均衡開源產品是LVS(linux virtual server)。

2.6 負載均衡演算法

 負載均衡伺服器的實現可以分成兩個部分：
        1、根據負載均衡演算法和WEB伺服器列表計算得到叢集中一臺WEB伺服器的地址；
        2、將請求資料傳送到改地址對應的WEB伺服器上。

   常用的負載均衡演算法如下幾種：
         1、輪詢：即將請求依次分發到每臺應用伺服器上。
         2、加權輪詢：根據應用伺服器硬體效能情況，在輪詢的基礎上，安裝配置的權重將請求分發到每個伺服器。
         3、隨機：將請求隨機分配到各個應用伺服器。
         4、最少連線：記錄每個伺服器正在處理的連線數，將新到的請求分發到最少連線的伺服器上。
         5、原地址雜湊：根據請求來源的IP地址進行Hash計算，得到應用伺服器，這樣來自同一個IP地址請求總在同一個伺服器上處理。

 

3、分散式快取叢集的伸縮性設計

         分散式快取伺服器叢集中不同伺服器中快取的資料不相同，快取訪問請求不可用在快取伺服器叢集中的任意一臺處理，必須先找到快取有需要資料的伺服器，然後才能訪問。 這個特點會嚴重製約分散式快取叢集的伸縮性設計，因為新上線的快取伺服器沒有快取資料，而已下線的快取伺服器還快取著網站的許多熱點資料。
 分散式快取叢集伸縮性設計的最主要目標即：必須讓新上線的快取伺服器對整個分散式快取叢集影響最小，也就是說新加入快取伺服器後應使整個快取伺服器叢集中已經快取的資料 儘可能還被訪問到。

3.1 memcached分散式快取叢集訪問模型

3.2 分散式快取的一致性Hash演算法

        一致性hash演算法通過一個叫做一致性hash環的資料結構實現KEY到快取伺服器的Hash對映，如下圖：

        如果使用上面資料結構的話，那麼當新新增一臺快取伺服器時，只是影響到了其中一臺快取伺服器，其他兩頭快取伺服器的壓力並沒有得到緩解，因此此方案還是存在問題。 一種替代的方案就是增加一個虛擬層，即把每臺快取伺服器虛擬為一組伺服器（比如3個虛擬網元）平均放到上面的環裡面。這樣當新增加快取伺服器時，把新增加的虛擬網元平均分配 到環中，這樣就能緩解每臺快取伺服器，達到分散式快取叢集高伸縮性。

4、資料儲存伺服器叢集的伸縮性設計

        和快取伺服器叢集的伸縮性設計不同，資料儲存伺服器叢集的伸縮性對資料的永續性和可用性提出了更高的要求。具體來說，又可分為關聯式資料庫叢集的伸縮性設計和NoSql資料庫的伸縮性設計。

4.1 關聯式資料庫叢集的伸縮性設計

       主要的關聯式資料庫都支援資料複製功能，使用這個功能可以對資料庫進行簡單伸縮。
       另外除了利用資料庫主從讀寫分離外，也可以利用業務分隔模式使不同業務的資料表部署在不同的資料庫叢集上，即俗稱的資料分庫。但是這種方式的制約條件時跨庫不能進行join操作。
       在大型網站的實際應用中，即使使用了分庫和主從複製，對一些單表資料任然很大的表還需要進行分片，將一張表拆開分別儲存在多個資料庫中。
       目前支援分散式資料分片的關聯式資料庫產品主要有開源的Amoeba和Cobar（阿里巴巴），下圖為Cobar部署模型。

       Cobar是一個分散式關聯式資料庫訪問代理，介於應用伺服器和資料庫伺服器之間。應用程式通過JDBC驅動訪問Cobar叢集，Cobar伺服器根據SQL和分庫規則分解SQL，分發到MySQL叢集不同 的資料庫例項上執行（每個MySQL例項都部署為主/從結構，保證資料高可用）。
       Cobar系統元件模型如下圖：

       前端通訊模組負責和應用程式通訊，接搜到SQL請求（select * from users where userid in (12,22,23)）後轉交給SQL解析模組，SQL解析模組解析獲得SQL中的路由規則查詢條件（userid in （12,22,23））再轉交給 SQL路由模組，SQL路由模組根據路由規則配置（userid為偶數路由至資料庫A，奇數則路由至資料庫B）將應用程式提交的SQL分解成兩條SQL(select * from users where userid in (12,22)；select * from users where userid in (23))轉交給SQL執行代理模組，傳送至資料庫A和資料庫B分別執行。 資料庫A和資料庫B的執行結果返回至SQL執行模組，通過結果合併模組將兩個返回結果集合併成一個結果集，最終返回該應用程式，完成在分散式關聯式資料庫中的一次訪問請求。

 

       Cobar的伸縮有兩點：Cobar伺服器叢集的伸縮和MySQL伺服器叢集的伸縮。
       Cobar伺服器可以看做是無狀態的應用伺服器，因此其叢集伸縮可以簡單實用負載均衡的手段實現。而MySQL中儲存著資料，要保證叢集擴容後資料一致負載均衡，必須要做資料遷移，如下圖（利用資料同步功能進行資料遷移）。

4.2 NoSQL資料庫的伸縮設計

NoSQL主要是指非關係的、分散式的資料庫設計模式。一般而言，NoSQL資料庫產品都放棄了關聯式資料庫的兩大重要基礎：以關係代數為基礎的結構化查詢語言（SQL）和事物一致性保證（ACID），而強化了高可用性和可伸縮性。目前應用最廣泛的是Apache HBase。