開始由於某些想法於網際網路上搭建了網站時候甚至有能主機都租借由於篇文章我們只關注架構演變歷程因此假設時候已經託管了臺主機並且有定帶寬了時候由於網站具備了定特色吸引了部分人訪問逐漸發現系統壓力越來越高響應速度越來越慢而時候比較明顯資料庫和應用互相影響應用出問題了資料庫也容易出現問題而資料庫出問題時候應用也容易出問題於進入了第步演變階段：應用和資料庫從物理上分離變成了兩臺機器時候技術上沒有新要求發現確實起效了系統又恢復前響應速度了並且支撐住了更高流量並且會因資料庫和應用形成互相影響步架構演變對技術上知識體系基本沒有要求

架構演變第二步：增加頁面快取

   好景長隨著訪問人越來越多發現響應速度又開始變慢了查詢原因發現訪問資料庫操作太多導致資料連線競爭激烈所響應變慢資料庫連線又能開太多否則資料庫機器壓力會高因此考慮採用快取機制來減少資料庫連線資源競爭和對資料庫讀壓力時候首先也許會選擇採用squid 等類似機制來系統相對靜態頁面（例兩天才會有更新頁面）進行快取（當也採用頁面靜態化方案）樣程式上做修改能夠好減少對webserver壓力及減少資料庫連線資源競爭OK於開始採用squid來做相對靜態頁面快取
前端頁面快取技術例squid想用好還得深入掌握下squid實現方式及快取失效演算法等

架構演變第三步：增加頁面片段快取

增加了squid做快取整體系統速度確實提升了webserver壓力也開始下降了隨著訪問量增加發現系統又開始變有些慢了嚐了squid之類動態快取帶來好處開始想能能讓現些
 
動態頁面裡相對靜態部分也快取起來呢因此考慮採用類似ESI之類頁面片段快取策略OK於開始採用ESI來做動態頁面相對靜態片段部分快取步涉及了些知識體系：
頁面片段快取技術例ESI等想用好同樣需要掌握ESI實現方式等；

架構演變第四步：資料快取
採用ESI之類技術再次提高了系統快取效系統壓力確實進步降低了同樣隨著訪問量增加系統還開始變慢經過查詢能會發現系統存些重複獲取資料資訊地方像獲取使用者資訊等時候開始考慮些資料資訊也快取起來呢於些資料快取本地記憶體改變完畢完全符合預期系統響應速度又恢復了資料庫壓力也再度降低了少步涉及了些知識體系：

快取技術包括像Map資料結構、快取演算法、所選用框架本身實現機制等

架構演變第五步： 增加webserver

     好景長髮現隨著系統訪問量再度增加webserver機器壓力高峰期會上升比較高時候開始考慮增加臺webserver也了同時解決用性問題避免單臺webserver down機沒法使用了做了些考慮決定增加臺webserver增加臺webserver時會碰些問題典型有：
1、何讓訪問分配兩臺機器上時候通常會考慮方案Apache自帶
 
負載均衡方案或LVS類軟體負載均衡方案；
2、何保持狀態資訊同步例使用者session等時候會考慮方案有寫入資料庫、寫入儲存、cookie或同步session資訊等機制等；
3、何保持資料快取資訊同步例之前快取使用者資料等時候通常會考慮機制有快取同步或分散式快取；
4、何讓上傳檔案些類似功能繼續正常時候通常會考慮機制使用共享檔案系統或儲存等；
解決了些問題終於把webserver增加了兩臺系統終於又恢復了往速度步涉及了些知識體系：

負載均衡技術（包括限於硬體負載均衡、軟體負載均衡、負載演算法、linux轉發協議、所選用技術實現細節等）、主備技術（包括限於 ARP欺騙、linux heart-beat等）、狀態資訊或快取同步技術（包括限於Cookie技術、UDP協議、狀態資訊廣播、所選用快取同步技術實現細節等）、
 
共享檔案技術（包括限於NFS等）、儲存技術（包括限於儲存裝置等）

架構演變第六步：分庫

享受了段時間系統訪問量高速增長幸福發現系統又開始變慢了次又狀況呢經過查詢發現數據庫寫入、更新些操作部分資料庫連線資源競爭非常激烈導致了系統變慢下辦呢此時選方案有資料庫叢集和分庫策略叢集方面像有些資料庫支援並好因此分庫會成比較普遍策略分庫也意味著要對原有程式進行修改通修改實現分庫錯目標達了系統恢復甚至速度比前還快了步涉及了些知識體系：

步更多需要從業務上做合理劃分實現分庫具體技術細節上沒有其要求；

同時隨著資料量增大和分庫進行資料庫設計、調優及維護上需要做更好因此對些方面技術還提出了高要求

架構演變第七步：分表、DAL和分散式快取
隨著系統斷執行資料量開始大幅度增長時候發現分庫查詢仍會有些慢於按照分庫思想開始做分表工作當避免會需要對程式進行些修改也許時候會發現應用自己要關心分庫分表規則等還有些複雜於萌生能否增加通用框架來實現分庫分表資料訪問ebay架構對應DAL演變過程相對而言需要花費較長時間當也有能通用框架會等分表做完才開始做同時階段能會發現之前快取同步方案出現問題因資料量太大導致現太能快取存本地同步方式需要採用分散式快取方案了於又通考察和折磨終於大量資料快取轉移分散式快取上了步涉及了些知識體系：
分表更多同樣業務上劃分技術上涉及會有動態hash演算法、consistent hash演算法等；

DAL涉及比較多複雜技術例資料庫連線管理（超時、異常）、資料庫操作控制（超時、異常）、分庫分表規則封裝等；

架構演變第八步：增加更多webserver

做完分庫分表些工作資料庫上壓力已經降比較低了又開始過著每天看著訪問量暴增幸福生活了突有天發現系統訪問又開始有變慢趨勢了時候首先檢視資料庫壓力切正常之檢視webserver發現apache阻塞了多請求而應用伺服器對每請求也比較快看來請求數太高導致需要排隊等待響應速度變慢還好辦般來說時候也會有些錢了於新增些webserver伺服器新增 webserver伺服器過程有能會出現幾種挑戰：
1、Apache軟負載或LVS軟負載等無法承擔巨大web訪問量（請求連線數、網路流量等）排程了時候經費允許會採取方案購買硬體負載例F5、Netsclar、Athelon之類經費允許會採取方案應用從邏輯上做定分類分散同軟負載叢集；
2、原有些狀態資訊同步、檔案共享等方案能會出現瓶頸需要進行改進也許時候會根據情況編寫符合網站業務需求分散式檔案系統等；
做完些工作開始進入看似完美無限伸縮時代當網站流量增加時應對解決方案斷新增webserver步涉及了些知識體系：

了步隨著機器數斷增長、資料量斷增長和對系統用性要求越來越高時候要求對所採用技術都要有更深入理解並需要根據網站需求來做更加定製性質產品

架構演變第九步：資料讀寫分離和廉價儲存方案

突有天發現完美時代也要結束了資料庫噩夢又次出現眼前了由於新增webserver太多了導致資料庫連線資源還夠用而時候又已經分庫分表了開始分析資料庫壓力狀況能會發現資料庫讀寫比高時候通常會想資料讀寫分離方案當方案要實現並容易另外能會發現些資料儲存資料庫上有些浪費或者說過於佔用資料庫資源因此階段能會形成架構演變實現資料讀寫分離同時編寫些更廉價儲存方案例BigTable種步涉及了些知識體系：

資料讀寫分離要求對資料庫複製、standby等策略有深入掌握和理解同時會要求具備自行實現技術；

廉價儲存方案要求對OS檔案儲存有深入掌握和理解同時要求對採用語言檔案塊實現有深入掌握

架構演變第十步：進入大型分散式應用時代和廉價伺服器群夢想時代

經過上面漫長而痛苦過程終於再度迎來了完美時代斷增加webserver支撐越來越高訪問量了對於大型網站而言人氣重要毋庸置疑隨著人氣越來越高各種各樣功能需求也開始爆發性增長時候突發現原來部署webserver上web應用已經非常龐大了當多團隊都開始對其進行改動時真相當方便複用性也相當糟糕基本每團隊都做了或多或少重複事情而且部署和維護也相當麻煩因龐大應用包N臺機器上覆制、啟動都需要耗費少時間出問題時候也好查另外更糟糕狀況有能會出現某應用上bug導致了全站都用還有其像調優好操作（因機器上部署應用都要做根本無法進行鍼對性調優）等因素根據樣分析開始痛下決心繫統根據職責進行拆分於大型分散式應用誕生了通常步驟需要耗費相當長時間因會碰多挑戰：
1、拆成分散式需要提供高效能、穩定通訊框架並且需要支援多種同通訊和遠端呼叫方式；
2、龐大應用拆分需要耗費長時間需要進行業務整理和系統依賴關係控制等；
3、何運維（依賴管理、執行狀況管理、錯誤追蹤、調優、監控和報警等）好龐大分散式應用
經過步差多系統架構進入相對穩定階段同時也能開始採用大量廉價機器來支撐著巨大訪問量和資料量結合套架構及多次演變過程吸取經驗來採用其各種各樣方法來支撐著越來越高訪問量步涉及了些知識體系：

步涉及知識體系非常多要求對通訊、遠端呼叫、訊息機制等有深入理解和掌握要求都從理論、硬體級、作業系統級及所採用語言實現都有清楚理解
運維塊涉及知識體系也非常多多數情況下需要掌握分散式平行計算、報表、監控技術及規則策略等等
     說起來確實費力整網站架構經典演變過程都和上面比較類似當每步採取方案演變步驟有能有同另外由於網站業務同會有同專業技術需求篇blog更多從架構角度來講解演變過程當其還有多技術也未此提及像資料庫叢集、資料探勘、搜尋等真實演變過程還會藉助像提升硬體配置、網路環境、改造作業系統、CDN映象等來支撐更大流量因此真實發展過程還會有多同另外大型網站要做遠遠僅僅上面些還有像安全、運維、運營、服務、儲存等要做好大型網站真容易