大型網站架構體系的演變

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

本文上篇將主要介紹大型網站基礎架構的擴展，下篇則重點從應用程序的角度去介紹網站架構的擴展和演變。

 

草根時期，快速開發網站並上線。固然，一般只是先試水，用戶規模也沒有造成，經濟能力和投入也很是有限。

有必定的業務量和用戶規模了，想提高網站速度，因而，緩存出場了。

市場反響還不錯，用戶量天天在增加，數據庫瘋狂讀寫，逐漸發現一臺服務器快撐不住了。因而，決定把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的價值就獲得體現了。

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

 

 

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

由於分庫分表誰都會幹，關鍵是拆完以後怎麼辦。目前，市面上尚未徹底開源免費的方案，能讓你一勞永逸地解決數據庫拆分問題。