根據以往經驗和網友的總結
縱向擴充套件
硬體方面可以更換更強勁的伺服器，增加 cpu ，記憶體， 使用高速磁碟。
軟體方面可以對現有**的優化，重構。使用 non-blocking 非阻塞 io 模式，或者非同步 io 模式，使用執行緒模式或者改用 事件驅動形模式。
目標是提高單機 qps ，連線數，來支援更多的連線，更多的使用者，更多的業務量。
橫向擴充套件
使用集群，更多的伺服器代替單一伺服器。
可擴充套件系統設計模式
負載均衡
這種模式將請求分發到並行的處理機上。要求程式無狀態，請求對於每個處理機都應該是相同的。比如常見的 rest 模式既是無狀態模式。
分散聚集模式
這種模式將請求分發到多個處理機上，然後收集每個處理機返回的結果，得到整合的結果。比如map-reduce也可以看做這種模式。
結果快取
這種模式，首先檢視請求是不是發生過，如果發生過則直接返回之前的結果，來節約處理時間。這種模式非常常見比如靜態頁面的 反向** ，各層級的 cache。
共享空間
所有的處理機監控共享空間中的未處理資訊，處理完後將結果提交到共享空間，直到整個任務完成。
map reduce
這種模式通常用來解決 io 密集型的業務，通過並行化的分布式系統來解決 io 瓶頸。
佇列模式
每個處理機從待處理佇列提取任務進行處理然後將結果儲存到已處理佇列，多個處理機可以並行處理佇列任務。
要點
1. 快速失效並返回錯誤
2. 將複雜的大的請求分解成多個小請求
3. 利用 超時
4. 利用 快取
5. 用佇列來做緩衝
6. 精確測量每個步驟，記錄詳細日誌
伺服器可擴充套件性的要點
拓展和可拓展性 就web服務而言，購買昂貴的高速硬體以提高效能的 縱向拓展 方案，遠不如將大量廉價的，效能一般的硬體放在一起以提高系統效能的 橫向拓展 方案流行。為什麼橫向拓展更好呢？因為它更適合大多數web服務，雖然原因多種多樣，但 低廉和系統結構靈活是最重要的原因。可擴充套件性的要點 cpu負載...
可擴充套件的檔案同步設計
在老的cms系統中通過新配置的同步系統，對cms生成的檔案進行同步。方便對機器新增的擴充套件，新新增的機器首先執行同步初始化的功能模組，此圖暫時沒有加上。在同步模組中進行配置源與目標伺服器的服務模組url。cms的新聞新增，修改及刪除需增加同步函式，以使得新聞新增修改和刪除的動作記錄到同步表中。同步...
系統的可擴充套件性
到底什麼是可擴充套件性？這年頭，作為軟體設計架構師如果系統沒有可擴充套件性對外交流時都不好意思。但是如何選擇可擴充套件性方案？水平擴充套件還是垂直擴充套件？是不是很矛盾呢，本文為你分析可擴充套件性的真實含義和實際專案中的取捨。每每和別人提及可擴充套件性的含義時，很多人開始討論提高效能，實施高可用性，...