大型網站技術架構之伸縮性
什麼是伸縮性
當面臨大量併發，大流量時，爲了能夠提高系統的處理能力，通過增加機器來提升系統性能，能夠方便並且性能提升會根據增加機器數量呈線性增長，這個稱爲網站的伸縮性
負載均衡算法
- 隨機
- 輪詢
- 隨機加權
- 最少連接數(通過zk同步服務連接數量)
應用層的伸縮
通過負載均衡器將請求分發到應用層的服務，常用的負載均衡器爲Nginx 反向代理，Ngnix會通過心跳方式(定時發送一個http請求，收到200算正常)去檢查後端服務是否可用，當心跳發送失敗了就會從待發送服務列表中移除對應ip，當增加一臺服務器時，修改nginx配置，這樣就會將請求發送到新的服務上
服務層的伸縮
服務層爲應用層而服務的，將應用層使用到的公共邏輯抽象成單獨一個服務，這樣可以複用代碼，避免同樣的業務在各個應用中出現，便於控制和管理
服務層的伸縮性如何做：負載均衡策略放在服務調用端做的，當下架服務是通過zookeeper通知消費端，然後消費端就不會再轉發請求到該服務上，上架服務時首先被zookeeper感知到，然後通知消費端，由消費端向新服務發送請求
數據層的伸縮
數據層服務和應用層和服務層服務不一樣，數據層的服務是有狀態的，因爲存放的是數據，數據層的服務伸縮會比較棘手，因爲還需要進行數據同步
緩存服務：通過一致性hash 當擴容緩存服務時儘可能少的影響現有的緩存數據，避免大量請求打到數據庫層
數據庫(MySQL)：對於主從模式，伸縮性還不夠好，因爲即使再增加很多臺從庫，一旦數據量很大時還是會出現性能瓶頸和存儲的瓶頸
爲了能有更強的伸縮性，需要對數據進行分區，需要每個業務模塊單獨一個數據庫，當某個業務數據量很大時例如用戶服務，需要根據用戶某個維度例如用戶id散落到多個數據庫中，如果庫中單表的數據量還是很大的話，就需要根據某個分區鍵將數據分到不同的表中，提高查詢性能。
以上操作可以在一個數據庫中間件(代理服務器)幫你完成，分庫分表邏輯對於調用方是透明，數據庫中間件幫你拆解SQL，分發到不同數據庫和表中，然後組裝各個庫中返回的數據，最後吐給調用端。
以上操作會犧牲數據庫本有的特性，例如事務(後面衍生出分佈式事務)、join操作
除了單獨提供一個服務外，可以將分庫分表邏輯封裝到一個jar包，調用端進行引入。