好的架構源於不停地衍變，而非設計

好的架構源於不停地衍變，而非設計

好的架構不是設計出來的，而是演進出來的

對很多創業公司而言，很難在初期就預估到流量十倍、百倍以及千倍以後網站架構會是什麼樣的一個狀況。同時，如果系統初期就設計一個千萬級並發的流量架構，很難有公司可以支撐這個成本。
因此，這裡主要會關注架構的眼花。在每個階段，找到對應該階段網站架構所面臨的問題，然後在不斷解決這些問題，在這個過程中整個架構會一直演進。
在建立之初，站點的流量非常小，可能也就是十萬級別，這也就意味著，平均每秒鐘也就是幾次的訪問，此時網站架構的特點是：請求量比較低，數據量比較小，代碼量也比較小。這個時候的站點可以被幾個工程師輕易搞定，因此根本沒什麼“架構”可言。

就像一個單機系統，所有的東西都部署在一台機器上，包括站點、數據庫、文件等等。而工程師每天的核心工作就是CURD，前端傳過來一些數據，然後業務邏輯層拼裝成一些CURD訪問數據庫，數據庫返回數據，數據拼裝成頁面，最終返回到瀏覽器。相信很多創業團隊初期都面臨一個與之類似的情況，每天寫代碼，寫SQL、接口參數、訪問數據等等。

如果可以重來？那麼會選擇LAMP

很多創業的同學可能會想，初期什麼樣的一個架構合適？如果重來，站在現在這個角度上會選擇LAMP，為什麼？首先是無須編譯，而且快速發布功能強大，從前端到後端、數據庫訪問、業務邏輯處理等等全部可以搞定，最重要都是成熟的開源產品，完全免費的。如果使用LAMP搭建一個論壇，兩天的時間就足夠了。所以，如果在創業初期，就盡量不要再使用Windows。

在這個階段面臨的主要問題是什麼？其實就是招人，最初工程師寫CURD都容易出錯。當時引進了DAO和ORM，從而避免直接面對CURD語句，而是面對工程師比較擅長的是面向對象，能夠極大的提高工作效率，降低出錯率。
中等規模：流量跨過十萬的階段，數據庫成為瓶頸
隨著高速增長，系統很快跨越了十萬流量階段。主要需求是什麼？網站能夠正常訪問，當然速度更快點就好了。而此時系統面臨的問題有：在流量峰值期容易宕機，因為大量的請求會壓到數據庫上，所以數據庫成為新的瓶頸，從而，人越多訪問越慢。而在這個時候，機器數量也從一台變成了多台，所以很自然的行程了分佈式架構

首先，使用了一些非常常見的技術，一方面是動靜分離，動態的頁面通過Web-Servre訪問，靜態的像圖片等就單獨放到了一些服務器上。另外一點就是讀寫分離。其實，或者說絕大部分的站點而言，一般來說都是讀多寫少。絕大部分用戶是訪問信息，只有很少的用戶過來發貼。那麼如何擴展整個站點架構的讀請求呢？常用的是主從同步，讀寫分離。同時原來只有一個數據庫，現在使用多個不同的數據庫提供服務，這樣的話，就擴展了讀寫，很快就解決了中等規模下數據訪問的問題。

大家都知道做數據庫讀請求和寫請求，分佈在不同的數據庫上，這個時候如果再讀取可能讀到的是舊數據，因為讀寫有一個延時。如果有用戶發帖子，馬上去找的話肯定找不到，很可能帶來的後果就是陸續在發布兩條信息，這就是一個很大的問題。尤其是在請求量越來越大的時候，這個問題就更加突出。

在解決這些問題時，最先想到的是針對原來站點的核心業務做切分，然後工程師根據自己的站點和業務場景進行細分。首先，業務拆分是最先嘗試的優化——將業務垂直拆分成了首頁和發布頁。另外，在數據庫層面，隨之也進行了拆分，將大數據量拆分成一個個小的數據量。這樣，讀寫延時就馬上得到了緩解。尤其是在代碼拆分成了不同的層面之後，站點耦合也得到了緩解，數據加載速度也提升了很多。

還使用了一些技術，前面也提到了對動態資源和靜態資源進行拆分。其中，我們對靜態資源使用了CDN服務，便於數據緩存和就近訪問，訪問速度得到很明顯的提升。除此之外，還使用了MVC模式，擅長前端的去做展示層，擅長協作邏輯的工程師就做Contorller，擅長數據的人就負責數據，效率就會逐步的提高，最後就是負載均衡技術。