高擴展性網站的50條原則

《高擴展性網站的50條原則》，利用一天半的時間快速瀏覽總結的電子書，對網站的建設有一個原則性的把握，書中提到的大部分原則如今已成爲互聯網行業的共識，但並不妨礙咱們從新整理分類，從全局層面把控高擴展性網站的建設思路，文中的每一條儘管高度凝練，但都值得細細品味。完成於2015年6月11日11:02:19。

（一）化簡方程

1. 不要過分設計：基於成本的考慮，只設計能知足要求的系統便可，過於理想化的設計不利於系統的維護與成本控制；
2. 設計時考慮擴展性：設計20倍的容量，實現3倍的容量，部署1.5倍的容量，即所謂的D-I-D方法；
3. 在設計複雜系統時將方案的設計、範圍和實施一簡再簡，在精簡過程當中能夠參考2-8原則，優先最主要，最核心的實現；
4. 減小頁面的DNS查找：
5. 經過減小與合併等機制，儘量減小頁面上的對象，下降請求資源的次數；
6. 使用同一品牌的網絡設備，減小不一樣品牌的網絡設備間帶來的擴展性問題；

總結：

（二）分佈工做

1. 橫向複製：複製服務或數據庫來分散事務負載，X軸原則；
2. 縱向拆分：根據動詞或名詞，拆分服務和數據
3. 拆分相近的東西：利用某些主題的屬性進行查分，如利用客戶的ID、所在地等進行拆分；

總結：

（三）橫向擴展設計

1. 設計橫向擴展方案；
2. 採用經濟型系統，包括服務器及其餘硬件，節約成本；
3. 橫向擴展數據中心：設計具備三個或更多實時數據中心的系統，分散數據，分散事務負載；
4. 利用雲計算進行設計，面對突發的擴展，利用自建或第三方的雲技術能夠幫助快速環境準備；

總結：

（四）使用正確的工具

1. 合理選擇數據存儲：尤爲是對於RDBMS的選擇，看是否有事務要求，若是隻是簡單存儲，考慮文件系統或緩存等；
2. 謹慎使用防火牆；
3. 利用監控工具收集並分析系統日誌文件

總結：

（五）不要重複工做

1. 不要當即檢查剛作過的工做，即不要當即讀剛寫入大數據，由於這種寫出錯的機率微乎其微；
2. 避免使用重定向，若是必須使用，優先考慮服務器配置；
3. 放鬆時序約束，數據的分佈總會給狀態帶來短暫的不一致，強行約束時序會使系統處理緩慢；

總結:

（六）積極利用緩存

1. 大用戶流程使用CDN；
2. 使用HTTP頭中的Expires、Cache-Control、Last-Modified等過時設置，包括對Web服務器對應HTTP頭信息的設置；
3. 緩存Ajax調用；
4. 應用頁面緩存，在web服務器前加上頁面靜態內容緩存；
5. 應用緩存使用；
6. 在數據庫和應用層之間加入對象緩存，如memcached；
7. 將對象緩存獨立成單獨的層爲上層提供服務；

總結：

（七）從錯誤中吸收教訓

1. 從偶爾錯誤事件及失敗中總結學習；
2. 不要依靠QA發現錯誤，更多的從控制編程角度控制；
3. 沒有回退共的設計是失敗的設計；
4. 討論失敗並從中吸收教訓；

總結：

（八）數據庫原則

1. 在設計數據模型時，考慮實體間較複雜的關係，爲未來的數據庫分割或其餘處理作好準備；
2. 使用類型正確的數據庫鎖，如隱式鎖、顯式鎖、行鎖、頁鎖、範圍鎖、表鎖、數據庫鎖；
3. 不要使用多階段提交協議處理存儲或事務，由於其是阻斷性提議，對數據庫的鎖定要求更強；
4. 避免使用select for update ,由於該語句查詢到的行都會被鎖住；
5. 不要使用select * 選擇全部數據列，使用select或insert的時候都制定列名；

總結：

（九）容錯設計與故障設計

1. 採用隔離故障的泳道，經過將服務拆分或將大數據量的表按屬性劃分進行隔離，減小隔離域之間的同步調用及數據共享；
2. 避免單點故障，採用master/master的模式，經過負載均衡器均衡跨服務的流量；
3. 避免系統串聯，若是要串聯，也要將單個系統和核心環節的系統設置成集羣模式；
4. 對於有風險或共享的服務，須要建立一種結果作到啓用或禁用（可經過配置文件、數據庫、啓動參數、同步命令、文件標記等方式）

總結：

（十）避免狀態或分發狀態

1. 避免狀態：努力實現無狀態，經過合理的設計選擇；
2. 分發狀態：儘可能在瀏覽器端維護會話，保持在cookie中；
3. 分發狀態：利用分佈式緩存存放狀態，經過緩存數據提升存取速度，須要考慮支持持久化的緩存服務選擇或利用數據庫進行持久化

總結：

（十一）異步通訊和消息總線

1. 儘量使用異步通訊保證每一個服務和層都是獨立的，即便必定要用同步服務，須要設置服務超時時間；使用異步通信的常見四種狀況：（調用外部API或第三方方法；調用長時間運行的進程；調用容易出錯和頻繁更改的方法；調用無時間約束或業務連續性約束的系統或服務）；
2. 確保消息總線可以擴展：經過服務按不一樣類型或不一樣處理方式進行拆分；
3. 避免讓消息總線過於擁擠，不要發佈全部消息，減小低價值高成本的流程，對低價值/低成本和高價值/高成本的流量進行採樣；

總結：

（十二）其餘原則

1. 慎用第三方解決方案擴展；
2. 從成本角度合理使用存儲，對於不一樣價值的數據採用不一樣的存儲策略；
3. 刪除數據庫事務處理過程當中的業務邏輯處理，讓數據庫只作數據事務處理方面的共走，與業務邏輯無相關；
4. 設計可以監控的應用，在設計階段就要考慮監控，作到從業務的角度監控而不只僅是CPU、內存、網絡等純技術監控；
5. 團隊中的技術能力要能勝任對系統、組件、服務等相關能力的須要，作到自助可控；

總結：