網際網路上有很多關於網站架構的各種分享，有些主要是從運維和基礎架構的角度去分析的（堆機器，做叢集），太關注技術細節實現，普通的開發人員基本看不太懂。

本文第一章節將主要介紹大型網站基礎架構的擴充套件，第二章節則重點從應用程式的角度去介紹網站架構的擴充套件和演變。

草根時期，快速開發網站並上線。當然，通常只是先試水，使用者規模也沒有形成，經濟能力和投入也非常有限。

有一定的業務量和使用者規模了，想提升網站速度，於是，快取出場了。

市場反響還不錯，使用者量每天在增長，資料庫瘋狂讀寫，逐漸發現一臺伺服器快撐不住了。於是，決定把DB和APP做分離。

單臺數據庫也感覺快撐不住了，一般都會嘗試做“讀寫分離”。由於大部分網際網路“讀多寫少”的特性所決定的。Salve的臺數，取決於按業務評估的讀寫比例。

資料庫層面是緩解了，但是應用程式層面也出現了瓶頸，由於訪問量增大，加上早期程式設計師水平有限寫的程式碼也很爛，人員流動性也大，很難去維護和優化。所以，很常用的辦法還是“堆機器”。

加機器誰都會加，關鍵是加完之後得有效果，加完之後可能會引發一些問題。例如非常常見的：頁面輸出快取和本地快取的問題，Session儲存的問題......

到這裡，已經基本做到了DB層面和應用層面的橫向擴充套件了，可以開始關注一些其它方面，例如：站內搜尋的精準度，對DB的依賴，開始引入全文索引。

Java領域用的較多的是Lucene、Solr等，而php領域用的比較多的是sphinx/coreseek。

到目前為止，一個能夠承載日均百萬級訪問量的中型網站架構基本介紹完了。

在做擴充套件滿足了基本的效能需求後，我們會逐漸關注“可用性”（也就是我們通常聽別人吹牛時說的SLA、幾個9）。如何保證真正“高可用”，也是個難題。

幾乎主流的大中型網際網路公司，都會有用到類似的架構，只是節點數不同而已。

還有一招用的比較多的，那就是動靜分離。可以需要開發人員配合（把靜態資源放獨立站點下），也可以不需要開發人員配合（利用7層反向代理來處理，根據字尾名等資訊來判斷資源型別）。有了單獨的靜態檔案伺服器之後，儲存也是個問題，也需要擴充套件。多臺伺服器的檔案怎麼保持一致，買不起共享儲存怎麼辦？分散式檔案系統也派上用場了。

還有一專案前國內外用的非常普遍的技術CDN加速。目前該領域競爭激烈，也已經比較便宜了。國內南北網際網路問題比較嚴重，使用CDN可以有效解決這個問題。

CDN的基本原理並不複雜，可以理解為智慧DNS+Squid反向代理快取 ，然後需要有很多機房節點提供訪問。

截止目前為止，都沒有怎麼去改動應用程式的架構，或者說通俗點，都不怎麼需要大面積的修改程式碼。

如果上面那些手段都用光了，還是支撐不住怎麼辦？不停的加機器也不是辦法啊？

隨著業務越來越複雜，網站的功能越來越多，雖然部署層面是採用的叢集，但是應用程式架構層面還是“集中式”的，這樣會導致很多耦合，不便於開發、維護，而且容易“一榮俱損”。所以，通常會把網站拆分出不同的子站點來單獨宿主。

應用都拆了，由於單個數據庫的連線，QPS，TPS，I/O處理能力都非常有限，DB層面也可以去做垂直分庫操作

拆分應用和DB之後，其實還是會有很多問題。不同的站點，裡面可能會有相同邏輯和功能的程式碼。當然，對於一些基礎的功能我們可以封裝DLL或者Jar包去到處提供引用，但是這種強依賴也很容易造成一些問題（版本問題、依賴關係等處理起來非常麻煩）。這樣，傳說中的SOA的價值就得到體現了。

應用、服務之間還是會出現一些依賴問題，這時候，高吞吐量的解耦利器出現了

最後，還介紹一個大型網際網路公司都用的絕技--分庫分表。個人經驗，不是業務發站和各方面非常迫切，不要輕易走這一步。

因為分庫分表誰都會幹，關鍵是拆完之後怎麼辦。分庫分表主要考慮以下幾個維度：橫向拆分，縱向拆分，分散式資料訪問層，資料庫中介軟體（代理）

推薦閱讀：

覺得有幫助？請轉發給更多人！

架構師小祕圈，聚集10萬架構師的小圈子！不定期分享技術乾貨，行業祕聞！彙集各類奇妙好玩的話題和流行動向！長按左側圖片，掃碼加入架構師微信群！