隨著智慧型裝置的普及使得高併發場景越來越多，可擴充套件成為系統設計的必要條件，下面分別介紹下可擴充套件系統的四個重要組成部分
冗餘容錯：一台伺服器宕機不會影響服務的正確性，只是降低系統的負載能力。
一般的冗餘和水平擴充套件等，都可以通過負載均衡來實現。主要有3種實現方法：
客戶端負載均衡：這裡的客戶端是廣義的客戶端，例如服務a呼叫服務b，我們認為服務a是客戶端。客戶端配置n個服務端的位址，採取round-robin或者其他隨機策略訪問服務端。優點是編碼實現簡單；缺點是變更困難，服務端遷移需要公升級所有客戶端配置，當然你可以搭建配置服務，這個服務本身也是單點，然後為配置服務實現負載均衡……
硬體負載均衡：購買專用的負載均衡器，例如citrix netscaler。優點：效能卓越； 缺點：昂貴，高富帥專用。
軟體負載均衡：通過路由分發，心跳探測等方法，實現軟體層面的負載均衡，典型的開源元件有：lvs，nginx和haproxy等。目前大多數網際網路公司均採用軟體負載均衡。
快取是乙個系統中效能提公升的關鍵。主要有5種實現方法：
應用層：應用自己在本地記憶體或其他介質中快取部分資料，一般通過lru演算法淘汰。
資料庫層：資料庫引擎自身的快取，需要dba來配置優化，當然現在也有不少nosql的快取+儲存解決方案如mongodb、帶handlersocket外掛程式mysql、ttserver等。資料庫快取的好處是應用側**不需要更改。
記憶體快取：目前的主流解決方案，代表有memcached和redis，redis的優點是資料結構 豐富，可以輕鬆支援排名等場景，缺點是單程序實現導致持久化方案不夠完美，今年4月redis cluster終於迎來了第乙個穩定版本，可以實現資料自動sharding和容錯，穩定性有待後續檢驗。
網頁快取：在apache等http伺服器上，配置full-page cache等策略。
cdn：對於靜態檔案，一般採用cdn來加速。
使用快取的過程中，必須要注意快取有效性，在資料來源更新後，要及時更新快取中的資料。目前主要有read-through和write-through兩種策略，採用write-through的多些。
定期任務：每天每小時的任務，使用crontab或者其他cron服務來排程。
平行計算：採用mapreduce，其它主流開源元件有hive，impala等。
訊息佇列：任務排隊，併發處理等，主流開源元件有rabbitmq，kafka。
提供給應用的，不是一堆元件，而是一組api，把底層架構隱藏起來。這樣有兩個主要的好 處：
底層架構重用，可支撐多應用，運營更方便。
應用和底層架構解耦合，底層架構可自我演進，是scale的必備基礎。
架構師不可不知的十大可擴充套件架構
對於大多數架構師而言，可擴充套件性 在軟體架構方面是最虛無縹緲的說法。這毫不奇怪，因為可擴充套件性正是如今軟體設計領域最值得優先考慮的要素。然而，計算機科學家們還無法了解一套單獨的架構如何才能擴充套件至各類應用環境當中。相反，我們在數量繁多的方案中所設計出的可擴充套件性架構，往往以業界較為通用的已知...
架構師不可不知的十大可擴充套件架構
對於大多數架構師而言，可擴充套件性 在軟體架構方面是最虛無縹緲的說法。這毫不奇怪，因為可擴充套件性正是如今軟體設計領域最值得優先考慮的要素。然而，計算機科學家們還無法了解一套單獨的架構如何才能擴充套件至各類應用環境當中。相反，我們在數量繁多的方案中所設計出的可擴充套件性架構，往往以業界較為通用的已知...
架構師不可不知的十大可擴充套件架構
可擴充套件性正是如今軟體設計領域最值得優先考慮的要素。然而，計算機科學家們還無法了解一套單獨的架構如何才能擴充套件至各類應用環境當中。相反，我們在數量繁多的方案中所設計出的可擴充套件性架構，往往以業界較為通用的已知可擴充套件模式及個人偏好為標準。本文列出了十大大家耳熟能詳的可擴充套件性架構，以供借鑑...