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

• 網站的伸縮性是指不需要改變網站的軟硬件設計，僅僅通過改變部署的服務器數量就能夠擴大或縮小網站的服務處理能力
• 大型網站的“大型”：在用戶層面為大量用戶及大量訪問，在功能方面為功能龐雜，在技術層面為需要部署大量的服務器
• 大型網站是從小型網站漸進演變而來的，也有可能出現脈沖，傳統企業易忽視這點（1開始就試圖打造大型網站）

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

   • 不同功能進行物理分離實現伸縮
     新增服務器總是從現有服務器中分離出部份功能和服務進行處理
     
     • 縱向分離（分層后分離）
       將業務處理流程上的不同部份分離部署
     • 橫向分離（業務分割后分離）
       將不同的業務模塊分離部署，粒度可以很小，乃至1個關鍵網頁部署為1個獨立服務
   • 單1功能通過集群范圍實現伸縮
     不同功能分離部署，隨著網站訪問量的逐漸增加，即便最小粒度分離部署，也不能滿足業務范圍要求，因此要使用服務器集群，集群范圍需要同時斟酌對其可用性、性能及關聯服務集群的影響
     
     • 利用服務器集群
     • 數據服務器集群
       
       • 緩存數據服務器集群
       • 存儲數據服務器集群

2. 利用服務器集群的伸縮性設計
   利用服務器是無狀態的，如果負載均衡服務器可以感知或可以配置集群的服務器數量，可和時發現集群中新上線或下線的服務器，并能向新上線的服務器分發要求，停止向已下線的服務器分發要求，那末就實現了利用服務器集群的伸縮性

   負載均衡的實現技術有以下幾種

   • HTTP重定向負載均衡
     根據用戶HTTP要求計算服務器地址，返回302重定向給閱讀器再進行訪問
     
     • 優點：簡單
     • 缺點：1次訪問閱讀器需要兩次要求，性能較差；重定向服務器本身性能可能成為瓶頸；302響應重定向可能會被搜索引擎判斷為SEO做弊，下降搜索排名
   • DNS域名解析負載均衡
     DNS服務器中配置多個記錄，每次域名解析要求都會計算不同的服務器地址返回進行訪問
     
     • 優點：負載均衡工作交給DNS，省掉網站管理保護負載均衡服務器的麻煩；DNS還支持地理位置域名解析，可根據地理就近進行地址返回，加快訪問速度，改良性能
     • 缺點：DNS為多級解析，下線服務器時修改記錄后，生效需要較長的時間，這段時間致使訪問失敗；DNS負載均衡控制權在域名服務商那，網站沒法進行更多改良和強大的管理
   • 反向代理負載均衡
     反向代理服務器緩存資源改良網站性能的同時，計算服務器地址并進行要求轉發，服務器處理完后返回給反向代理服務器，反向代理服務器再將相應返回給用戶
     Web服務器不需要外部IP地址，反向代理服務器需要配置雙網卡和內部外部兩套IP地址
     
     • 優點：負載均衡和反向代理集成1起，部署簡單
     • 缺點：反向代理服務器成為所有要求響應的中轉站，本身性能可能成為瓶頸

   • IP負載均衡
     負載均衡服務器在操作系統內核進程獲得網絡數據包，計算服務器地址并進行目的IP地址修改，服務器處理完后返回給負載均衡服務器，負載均衡服務器再將數據包源地址修改成本身的IP地址并返回給用戶

     真實物理Web服務器響應數據包返回給負載均衡服務器的兩種方式  
         * 修改目的地址同時修改源地址為本身IP，即源地址轉換（SNAT）  
         * 將負載均衡服務器作為真實服務器集群的網關服務器
     

     • 優點：內核中完成數據分發，較反向代理服務器（在利用層分發數據）有更好的性能
     • 缺點： 數據吞吐量受限于負載均衡服務器網卡帶寬，對下載、視頻服務等難以滿足需求
   • 數據鏈路層負載均衡（直接路由方式）
     3角傳輸模式，計算服務器Mac地址，不修改IP地址，只修改目的mac地址，配置真實物理服務器集群所有機器虛擬IP和負載均衡服務器IP地址1致，到達數據分發的目的，物理服務器響應發送給網關服務器后直接返回給用戶
     
     • 優點：避免負載均衡服務器網卡寬帶成為瓶頸

   事實上，大型網站總是使用DNS域名解析作為第1級負載均衡，域名解析得到1組提供負載均衡服務的內部服務器，然后再進行負載均衡分發要求
   數據鏈路層負載均衡是目前大型網站使用最廣的1種負載均衡手段

   • 負載均衡算法
     
     • 輪詢（可加權）
     • 隨機（可加權）
     • 最少連接（可加權）
     • 源地址散列：會實現會話黏滯
3. 散布式緩存集群的伸縮性設計
   散布式緩存服務器集群中不同服務器緩存的數據各不相同，要求不可以在任意1臺緩存服務器上處理，嚴重制約了散布是緩存集群的伸縮性設計
   新加入緩存服務器后應當使全部緩存服務器集群中已緩存的數據盡量被訪問，這是散布式緩存集群伸縮性設計的最主要目標
   
   • Memcached散布式緩存集群的訪問模型
     利用程序通過Memcached客戶端訪問Memcached服務器集群，Memcached客戶端主要由1組API、Memcached服務器集群路由算法、Memcached服務器集群列表及通訊模塊構成
     讀寫使用相同的集群路由算法，因此只要緩存存在便能保證命中
   • Memcached散布式緩存集群的伸縮性挑戰
     簡單的路由算法使用余數Hash，也可略微改進為加權余數Hash，但是集群需要擴容時大部份數據不能命中，比例隨著范圍1起增大，利用就會直接訪問數據庫服務器，大大超過數據庫的負載能力，致使數據庫宕機，不能簡單重啟恢復，需要較長時間恢復正常
     1種解決辦法：網站訪問量最小時擴容，此時對數據庫負載沖擊最小，并且通過摹擬要求方式逐步預熱緩存，使緩存服務器中的數據重新散布
   • 散布式緩存的1致性Hash算法
     構造1致性Hash環（通常使用2叉查找樹），緩存服務器根據節點名稱的Hash值進行放置，緩存數據根據數據KEY值的Hash值在Hash環上順時針查找距離最近的緩存服務器節點，完成KEY到服務器的映照查找
     擴容時新加入節點只影響環中1小段，繼續命中率隨著范圍1起增大
     1致性Hash算法會帶來負載不均衡問題，可以通過增加1個虛擬層解決，將每臺物理緩存服務器虛擬為1組虛擬緩存服務器，然后根據虛擬緩存服務器Hash進行放置，終究結果是新加入服務器分攤原有緩存服務器集群中所有服務器的1小部份負載，總的影響范圍和不使用虛擬層相同
     1般1臺物理服務器虛擬為150個虛擬服務器比較公道

4. 數據存儲服務器集群的伸縮性設計

   • 關系數據庫集群的伸縮性設計
     
     • 業務分庫
     • 主從數據庫復制
     • 單表分片
       常見的產品有Amoeba、Cobar
       散布式關系數據庫訪問代理，利用程序訪問代理，代理根據SQL和分庫規則分解SQL，分發到MySQL集群不同的數據庫實例上履行，合并結果落后行統1返回利用程序
       代理通常是無狀態的利用服務器可以簡單負載均衡進行伸縮；MySQL數據庫服務器則利用1致性Hash算法和以Schema為單位的數據同步功能進行遷移，同步完成落后行Schema的IP修改并刪除原有機器中的相干Schema便可
       
       • 優點：性能和直接訪問數據庫相當；代理代替利用程序連接數據庫，需要保護更少的連接，減少沒必要要的資源消耗
       • 缺點：需要避免事務或利用事務補償機制代替數據庫事務；需要分解數據訪問邏輯避免Join操作；帶有Join功能的代理延遲太高
   • NoSQL數據庫的伸縮性設計
     
     • 放棄關系型數據庫的以關系代數為基礎的結構化查詢語言（SQL）和事務1致性保證（ACID），強化高可用性和可伸縮性
     • 利用最廣泛的產品有HBase
     • 數據以HRegion為單位進行管理，每一個Region存儲1段Key值間的數據，HRegionServer是物理服務器，每一個HRegionServer可以啟動多個HRegion實例，HRegion寫入數據太多到達閾值時會分裂成兩個HRegion，并在全部集群中進行遷移，使得HRegionServer的負載均衡
     • 數據寫入和訪問：利用程序通過Key向Zookeeper（散布式數據管理服務）要求主HMaster地址，利用程序再通過Key向HMaster要求HRegionServer地址，最后再要求HRegionServer上的HRegion得到數據