1、軟體分層
分層思想很普及，把資料流拆成幾段，比如接入層（load balancer+webserver），應用服務層（platformserver），資料儲存層（資料庫database、nosql）。
2、伸縮性定義
2.1 接入層（loadbalancer + webserver）
請參考乙個客戶端請求到後台的流程：tcp-ip 7層網路通訊、負載均衡、api層、資料庫
中負載均衡部分的內容
（loadbalancer≈haproxy） + （webserver≈nginx）
haproxy+nginx 增加頻寬容量的對策：加更多網域名稱、更多**機器
負載均衡在有狀態情況下，怎麼去堆**機器？比如使用者uid=a的所有請求必須**到某個伺服器b上。請參考一致性hash
2.2 platform層
單例：某個程式，乙個時刻所有請求都打到一台機器上，由於一台機器cpu/記憶體有限，會導致單例效能瓶頸。比如設計了乙個請求計數器，讓所有請求都得經過這個機器上這個程序，在記憶體裡+1，最後得到結果。
正確做法如下：
（1）各個機器分別計數，然後查詢的時候查各個機器結果相加，盡量做分布式（讓請求均勻打在各個分布式機器上），避免單例。
（2）盡量只用這一層算，不要用這一層來存具體的資料結果，存資料的話，送到下一層的專門的資料儲存層。原因是：業務層的處理邏輯比較多，如果要是再用來維護資料的話，一方面很累，另一方面是資料儲存層會有通用的資料介面來存各種各樣的資料，沒必要用這層來存。儲存計算分離，儲存統一，計算多樣。
2.3 資料儲存層
做後台一般不會專門讓設計儲存層，有很多現成的模型。請參考乙個客戶端請求到後台的流程：tcp-ip 7層網路通訊、負載均衡、api層、資料庫
中資料庫部分的內容。
（1）讀寫分離，增加讀例項。
讀寫分離來確保寫和讀效率都很高。寫資料因為要確保資料不丟失，所以要寫入硬碟，機械硬碟有乙個擺臂，只適合採用log（尾部能新增的檔案）的方式順序寫，擺臂不需要來回移動，速度最快。讀資料需要隨機讀，硬碟訪問資料比較慢，擺臂來回移動效率低。實際上這裡面有三個程序：log方式順序寫，key-value方式隨機讀，把順序寫轉化為隨機讀（log格式轉為key-value格式）。
增加讀例項：實際應用中，往往有很多場景，寫資料次數很少，讀資料次數很多。比如說寫部落格只需要寫一次，但有可能同時有很多人在讀部落格。
（2）拆分：拆庫和拆表
redis這種非關係型資料庫相對來說好做伸縮，可以對key做雜湊，分片到某一台機器上。
關係型就比較難做伸縮，俗稱分庫（豎直拆分）分表（水平拆分）：
每個庫里的小業務可以拆到不同機器上。但是乙個表拆開的不同表必須放在同一臺機器上，因此拆庫比拆表效能好點。
系統伸縮性
系統伸縮性，是指在不改變系統軟硬體設計，僅僅通過新增伺服器的情況下，就能提公升系統的處理能力。系統成為大型的，分為2種，一種是開始就設計成大型的，例如12306 設計之初就要考慮能併發處理多少請求，要儲存多少資料。另外一種是從小系統慢慢演化成大型系統的，例如google 一開始只是幾台伺服器，然後隨...
ZooKeeper的伸縮性
經過前面的介紹，我想大家都已經知道了在zookeeper集群當中有兩種角色leader和follower。leader可以接受client 請求，也接收其他server 的寫請求，負責更新系統狀態。follower也可以接收client請求，如果是寫請求將 給leader來更新系統狀態，讀請求則由f...
13種提高系統伸縮性的最佳實踐
1,盡可能地使用非同步通訊.2,為提供不同服務的硬體引入故障隔離.3,在多層系統中,使用cache.4,從使用者角度監控你的系統效能.5,使用資料庫複製,降低單點讀壓力.6,根據使用者和業務的不同,將應用或資料庫分片.7,減少使用關係型資料庫的複雜特性.盡可能把它當做是乙個持久儲存裝置.8,以循序漸...