6、永無止境：網站的伸縮性架構

（1）網站架構的伸縮性設計

1.不一樣功能進行物理分離實現伸縮。縱向分離和橫向分離，不一樣的服務器部署不一樣的業務。

2.單一功能經過集羣規模實現伸縮。集羣內的多臺服務器部署相同的服務，提供相同的功能。

（2）應用服務器集羣的伸縮性設計

  若是HTTP請求分發裝置能夠感知或者能夠配置集羣的服務器數量，能夠及時發現集羣中新上線或下線的服務器，並能向新上線的服務器分發請求，中止向已下線的服務器分發請求，那麼就實現了應用服務器集羣的伸縮性。
  這裏，這個HTTP請求分發裝置被稱做均衡負載服務器。

  實現負載均衡的技術，如下幾種：
1.HTTP重定向負載均衡。
  HTTP重定向服務器是一臺普通的應用服務器，其惟一的功能就是根據用戶的HTTP請求一臺真實的Web服務器地址，並將該Web服務器地址寫入HTTP重定向響應中（響應狀態碼爲302）返回給用戶瀏覽器。在圖6.5中，瀏覽器請求訪問域名 www.mysite.com 。DNS服務器解析獲得IP地址是114.100.80.10，即HTTP重定向服務器的IP地址。而後瀏覽器經過IP地址 114.100.80.10訪問HTTP重定向負載均衡服務器後，服務器根據某種負載均衡算法計算得到一臺實際物理服務器的地址(114.100.80.3)，構造一個包含該實際物理服務器地址的重定向響應返回給瀏覽器，瀏覽器自動從新請求實際物理服務器的IP地址(114.100.80.3)，完成訪問。
  這種負載均衡方案的優勢是比較簡單。缺點是瀏覽器須要兩次請求才能完成一次訪問，性能較差；重定向服務器自身的處理能力有可能成爲瓶頸，整個集羣的伸縮性規模有限；使用HTTP302響應碼重定向，有可能使搜索引擎判斷爲SEO做弊，下降搜索排名。所以實踐中使用這種方案進行均衡負載的案例並很少見。

2.DNS域名解析負載均衡 

  每次域名解析請求都會根據負載均衡算法計算一個不的IP地址返回，這樣A記錄中配置多個服務器就構成一個集羣，並能夠實現負載均衡。
  DNS域名解析負載均衡的優勢是將負載均衡的工做轉交給DNS，省掉了網站管理維護負載均衡服務器的麻煩，同時許多DNS還支持基於地理位置的域名解析，即會將域名解析成距離用戶地理最近的一個服務器地址，這樣可加快用戶訪問速度，改善性能。可是DNS域名解析負載均衡也有缺點，就是目前的DNS是多級解析，每一級DNS均可能緩存A記錄，當下線某臺服務器後，即便修改了DNS的A記錄，要使其生效也須要較長時間，這段時間，DNS依然會將域名解析到已經下線的服務器，致使用戶訪問失敗；並且DNS負載均衡的控制權在域名服務商那裏，網站沒法對其做更多改善和更強大的管理。

3.反向代理負載均衡
  前面提到利用反向代理緩存資源，以改善網站性能。實際上，在部署位置上，反向代理服務器處於Web服務器前面（這樣才能夠緩存Web響應，加速訪問），這個位置也正好是負載均衡服務器的位置，因此大多數反向代理服務器同時提供負載均衡的功能，管理一組Web服務器，將請求根據負載均衡算法轉發到不一樣Web服務器上。Web服務器處理完成的響應也須要經過反向代理服務器返回給用戶。因爲Web服務器不直接對外提供訪問，所以Web服務器不須要使用外部IP地址，而反向代理服務器則須要配置雙網卡和內部外部兩套IP。
  因爲反向代理服務器轉發請求在HTTP協議層面，所以也叫應用層負載均衡。其優勢是和反向代理服務器功能集成在一塊兒，部署簡單。缺點是反向代理服務器是全部請求和響應的中轉站，其性能可能會成爲瓶頸。

4.IP負載均衡
  用戶請求數據包到達負載均衡服務器114.100.80.10(該服務器位於中間層| * |，*爲該服務器)後，負載均衡服務器在操做系統內核進程獲取網絡數據包，根據負載均衡算法計算獲得一臺真實Web服務器10.0.0.1，而後將數據目的IP地址修改成10.0.0.1，不須要經過用戶進程處理。真實Web應用服務器處理完成後，響應數據包回到負載均衡服務器，負載均衡服務器再將數據包源地址修改成自身的IP地址(114.100.80.10)發送給用戶瀏覽器
  這裏的關鍵在於真實物理Web服務器響應數據包如何返回給負載均衡服務器。一種方案是負載均衡服務器在修改目的IP地址的同時修改源地址，將數據包源地址設爲自身IP，即源地址轉換(SNAT)，這樣Web服務器的響應會再回到負載均衡服務器；另外一種方案是將負載均衡服務器同時做爲真實物理服務器集羣的網關服務器，這樣全部響應數據都會到達負載均衡服務器。

5.數據鏈路層負載均衡
  數據鏈路層負載均衡是指在通訊協議的數據鏈路層修改mac地址進行負載均衡。這種數據傳輸方式又稱做三角傳輸模式，負載均衡數據分發過程當中不修改IP地址，只修改目的mac地址，經過配置真實物理服務器集羣所在機器虛擬IP和負載均衡服務器IP地址一致，從而達到不修改數據包的源地址和目的地址就能夠進行數據分發的目的，因爲實際處理請求的真實物理服務器IP和數據請求目的IP一致，不須要經過負載均衡服務器進行地址轉換，可將響應數據包直接返回給用戶瀏覽器，避免負載均衡服務器網卡帶寬成爲瓶頸。這種負載均衡方式又稱做直接路由方式（DR）。
  使用三角傳輸模式的鏈路層負載均衡是目前大型網站使用最廣的一種負載均衡手段。在Linux平臺上最好的鏈路層負載均衡開源產品是LVS(Linux Virtual Server)。

6.負載均衡算法
  負載均衡服務器的實現分紅兩個部分：1.根據負載均衡算法和Web服務器列表計算獲得集羣中一臺Web服務器的地址。2.將請求數據發送到該地址對應的Web服務器上。

  a.輪詢(Round Robin, RR)。全部請求被依次分發到每臺應用服務器上，即每臺服務器須要處理的請求數目都相同，適用於全部服務器硬件都相同的場景。
  b.加權輪詢(Weighted Round Robin, WRR)。根據應用服務器硬件性能的狀況，在輪詢的基礎上，按照配置的權重將請求分發到每一個服務器，高性能的服務器能分配更多請求。
  c.隨機(Random)。請求被隨機分配到各個應用服務器，在許多場合下，這種方案都很簡單實用，由於好的隨機數自己就很均衡。即便應用服務器硬件配置不一樣，也可使用加權隨機算法。
  d.最少鏈接(Least Connections)。記錄每一個應用服務器正在處理的鏈接數（請求數），將新到的請求分發到最少鏈接的服務器上，這是符合負載均衡定義的算法。一樣，最少鏈接算法也能夠實現加權最少鏈接。
  e.源地址散列(Source Hashing)。根據請求來源的IP地址進行Hash計算，獲得應用服務器，這樣來自同一個IP地址的請求總在同一個服務器上處理，該請求的上下文信息能夠存儲在這臺服務器上，在一個會話週期內重複使用，從而實現會話黏滯。

（3）分佈式緩存集羣的伸縮性設計

1.Memcached分佈式緩存集羣的訪問模型。
  應用程序經過Memcached客戶端訪問Memcached服務器集羣，Memcached客戶端主要由一組API、Memcached服務器集羣路由算法、Memcached服務器集羣列表及通訊模塊構成。
  其中路由算法負責根據應用程序輸入的緩存數據KEY 計算獲得應該將數據寫入到Memcache的哪臺服務器（寫緩存）或者應該從哪臺服務器讀數據（讀緩存）。

2.Memcached分佈式緩存集羣的伸縮性挑戰
  簡單的路由算法可使用餘數Hash，用服務器數目除緩存數據KEY的Hash值，餘數爲服務器列表下標編號。假設"BEIJING"的Hash值是490806430(Java中HashCode返回值)，用服務器數目3除該值，獲得餘數1，對應節點NODE1。因爲HashCode具備隨機性，所以使用餘數Hash路由算法可保證緩存數據在整個Memcached服務集羣中比較均衡地分佈。
  假如業務發展，須要從3臺擴容到4臺，原本路由算法是除以3，如今除以4,致使不少數據緩存都不會命中，不能命中的機率爲3/4（N/(N+1)）。
  緩存不能命中的話將會給數據庫帶來巨大壓力。因此咱們能夠在網站訪問量最少的時候擴容緩存服務器集羣，這時候對數據庫的負載衝擊最小，而後經過模擬請求的方法逐漸預熱緩存，使緩存服務器中的數據從新分佈。

3.分佈式緩存的一致性Hash算法
  一致性Hash算法經過一個叫做一致性Hash環的數據結構實現KEY到緩存服務器的Hash映射。
  具體算法過程爲：先構造一個長度爲0-2的32次方的整數環（這個環被稱做一致性Hash環），根據節點名稱的Hash值（其分佈範圍一樣爲0到2的32次方）將緩存服務器節點放置在這個Hash環上。而後根據須要緩存的數據的KEY值計算獲得其Hash值（其分佈範圍也一樣爲0~2的32次方），而後在Hash環上順時針查找距離這個KEY的Hash值最近的緩存服務器節點，完成KEY到服務器的Hash映射查找。
  假設NODE1的Hash值爲3,594,963,423，NODE2的Hash值爲1,845,328,979，而KEY0的Hash值爲2,534,256,785，那麼KEY0在環上順時針查找，找到的最近的節點就是NODE1。
  當緩存服務器集羣須要擴容的時候，只須要將新加入的節點名稱(NODE3)的Hash值放入一致性Hash環中，因爲KEY是順時針查找距離其最近的節點，所以新加入的節點隻影響整個環中的一小段。
  具體應用中，這個長度爲2的32次方的一致性Hash環一般使用二叉查找樹實現，Hash查找過程其實是在二叉查找樹中查找不小於查找樹的最小數值。固然這個二叉樹的最右邊葉子節點和最左邊的葉子節點相鏈接，構成環。

4.數據存儲服務器集羣的伸縮性設計
  與緩存服務器集羣的伸縮性設計不一樣，數據存儲服務器集羣的伸縮性對數據的持久性和可用性提出了更高的要求。
  緩存的目的是加速數據讀取的速度並減輕數據存儲服務器的負載壓力，所以部分緩存數據的丟失不影響業務的正常處理，由於數據還能夠從數據庫等存儲服務器上獲取。
  而數據存儲服務器必須保證數據的可靠存儲，任何狀況下都必須保證數據的可用性和正確性。所以緩存服務器集羣的伸縮性架構方案不能直接適用於數據庫等存儲服務器。存儲服務器集羣的伸縮性設計相對更復雜一些，具體來講，又可分爲關係數據庫集羣的伸縮性設計和NoSQL數據庫的伸縮性設計。

  a.關係數據庫集羣的伸縮性設計。讀寫分離、數據分庫（不一樣業務數據表部署在不一樣的數據庫集羣上）   b.NoSQL數據庫的伸縮性設計。NoSQL數據庫產品都放棄了關係數據庫的兩大重要基礎：以關係代數爲基礎的結構化查詢語言(SQL)和事務一致性保證(ACID)。而強化其餘一些大型網站更關注的特性：高可用性和可伸縮性。