看的一個pdf說的。。大型網站架構演變

第一步：物理分離 webserver 和數據庫

                            將應用和數據庫從物理上分離，變成了兩臺機器

第二步：增長頁面緩存

                            例如 squid

第三步：增長頁面片斷緩存

                            例如 ESI 等

第四步：數據緩存

                            緩存技術，包括像 Map 數據結構、緩存算法、所選用的框架自己的實現機制等

第五步： 增長 webserver

                            一、如何讓訪問分配到這兩臺機器上，這個時候一般會考慮的方案是 Apache 自帶的負載均衡

                            方案，或 LVS 這類的軟件負載均衡方案；

                            二、如何保持狀態信息的同步，例如用戶 session 等，這個時候會考慮的方案有寫入數據庫、

                            寫入存儲、cookie 或同步 session 信息等機制等；

                            三、如何保持數據緩存信息的同步，例如以前緩存的用戶數據等，這個時候一般會考慮的機

                            制有緩存同步或分佈式緩存；

                            四、如何讓上傳文件這些相似的功能繼續正常，這個時候一般會考慮的機制是使用共享文件

                            系統或存儲等；

第六步：分庫

                    這一步更多的是須要從業務上作合理的劃分，以實現分庫，具體技術細節上沒有其餘的要求

第七步：分表、DAL 和分佈式緩存

                    分表更多的一樣是業務上的劃分，技術上涉及到的會有動態 hash 算法、consistent hash 算法

                    等；

                    DAL 涉及到比較多的複雜技術，例如數據庫鏈接的管理（超時、異常）、數據庫操做的控

                    制（超時、異常）、分庫分表規則的封裝等；

第八步：增長更多的 webserver

            一、Apache 的軟負載或 LVS 軟負載等沒法承擔巨大的 web 訪問量（請求鏈接數、網絡流量等）

            的調度了，這個時候若是經費容許的話，會取的方案是購 買硬件負載，例如 F五、Netsclar

            、Athelon 之類的，如經費不容許的話，會取的方案是將應用從邏輯上作必定的分類，然

            後分散到不一樣的軟負載集羣中；

            二、原有的一些狀態信息同步、文件共享等方案可能會出現瓶頸，須要進行改進，也許這個

            時候會根據狀況編寫符合網站業務需求的分佈式文件系統等；

            在作完這些工做後，開始進入一個看似完美的無限伸縮的時代，當網站流量增長時，應對的

            解決方案就是不斷的添加 webserver。

第九步：數據讀寫分離和廉價存儲方案

                數據讀寫分離要求對數據庫的複製、standby 等策略有深刻的掌握和理解，同時會要求具有

                自行實現的技術；

                廉價存儲方案要求對 OS 的文件存儲有深刻的掌握和理解，同時要求對採用的語言在文件這

                塊的實現有深刻的掌握、

第十步：進入大型分佈式應用時代和廉價服務器羣夢想時代

                一、拆成分佈式後須要提供一個高性能、穩定的通訊框架，而且須要支持多種不一樣的通訊和

                遠程調用方式；

                二、將一個龐大的應用拆分須要耗費很長的時間，須要進行業務的整理和系統依賴關係的控

                制等；

                三、如何運維（依賴管理、運行情況管理、錯誤追蹤、調優、監控和報警等）好這個龐大的

                分佈式應用。