互聯(lián)網(wǎng)上有很多關(guān)于網(wǎng)站架構(gòu)的各種分享，有些主要是從運維和基礎(chǔ)架構(gòu)的角度去分析的（堆機(jī)器，做集群），太關(guān)注技術(shù)細(xì)節(jié)實現(xiàn)，普通的開發(fā)人員基本看不太懂。
本文上篇將主要介紹大型網(wǎng)站基礎(chǔ)架構(gòu)的擴(kuò)展，下篇則重點從應(yīng)用程序的角度去介紹網(wǎng)站架構(gòu)的擴(kuò)展和演變。
草根時期，快速開發(fā)網(wǎng)站并上線。當(dāng)然，通常只是先試水，用戶規(guī)模也沒有形成，經(jīng)濟(jì)能力和投入也非常有限。
有一定的業(yè)務(wù)量和用戶規(guī)模了，想提升網(wǎng)站速度，于是，緩存出場了。
市場反響還不錯，用戶量每天在增長，數(shù)據(jù)庫瘋狂讀寫，逐漸發(fā)現(xiàn)一臺服務(wù)器快撐不住了。于是，決定把DB和APP做分離。
單臺數(shù)據(jù)庫也感覺快撐不住了，一般都會嘗試做“讀寫分離”。由于大部分互聯(lián)網(wǎng)“讀多寫少”的特性所決定的。Salve的臺數(shù)，取決于按業(yè)務(wù)評估的讀寫比例。
數(shù)據(jù)庫層面是緩解了，但是應(yīng)用程序?qū)用嬉渤霈F(xiàn)了瓶頸，由于訪問量增大，加上早期程序員水平有限寫的代碼也很爛，人員流動性也大，很難去維護(hù)和優(yōu)化。所以，很常用的辦法還是“堆機(jī)器”。
加機(jī)器誰都會加，關(guān)鍵是加完之后得有效果，加完之后可能會引發(fā)一些問題。例如非常常見的：頁面輸出緩存和本地緩存的問題，Session保存的問題......
到這里，已經(jīng)基本做到了DB層面和應(yīng)用層面的橫向擴(kuò)展了，可以開始關(guān)注一些其它方面，例如：站內(nèi)搜索的精準(zhǔn)度，對DB的依賴，開始引入全文索引。
Java領(lǐng)域用的較多的是Lucene、Solr等，而PHP領(lǐng)域用的比較多的是sphinx/coreseek。
到目前為止，一個能夠承載日均百萬級訪問量的中型網(wǎng)站架構(gòu)基本介紹完了。當(dāng)然，每一步擴(kuò)展里面都會有很多技術(shù)實現(xiàn)的細(xì)節(jié)，后續(xù)有時間會寫文章單獨去剖析那些細(xì)節(jié)。
在做擴(kuò)展?jié)M足了基本的性能需求后，我們會逐漸關(guān)注“可用性”（也就是我們通常聽別人吹牛時說的SLA、幾個9）。如何保證真正“高可用”，也是個難題。
幾乎主流的大中型互聯(lián)網(wǎng)公司，都會有用到類似的架構(gòu)，只是節(jié)點數(shù)不同而已。
還有一招用的比較多的，那就是動靜分離?？梢孕枰_發(fā)人員配合（把靜態(tài)資源放獨立站點下），也可以不需要開發(fā)人員配合（利用7層反向代理來處理，根據(jù)后綴名等信息來判斷資源類型）。有了單獨的靜態(tài)文件服務(wù)器之后，存儲也是個問題，也需要擴(kuò)展。多臺服務(wù)器的文件怎么保持一致，買不起共享存儲怎么辦？分布式文件系統(tǒng)也派上用場了。
還有一項目前國內(nèi)外用的非常普遍的技術(shù)CDN加速。目前該領(lǐng)域競爭激烈，也已經(jīng)比較便宜了。國內(nèi)南北互聯(lián)網(wǎng)問題比較嚴(yán)重，使用CDN可以有效解決這個問題。
CDN的基本原理并不復(fù)雜，可以理解為智能DNS+Squid反向代理緩存 ，然后需要有很多機(jī)房節(jié)點提供訪問。
截止目前為止，都沒有怎么去改動應(yīng)用程序的架構(gòu)，或者說通俗點，都不怎么需要大面積的修改代碼。
如果上面那些手段都用光了，還是支撐不住怎么辦？不停的加機(jī)器也不是辦法啊？
隨著業(yè)務(wù)越來越復(fù)雜，網(wǎng)站的功能越來越多，雖然部署層面是采用的集群，但是應(yīng)用程序架構(gòu)層面還是“集中式”的，這樣會導(dǎo)致很多耦合，不便于開發(fā)、維護(hù)，而且容易“一榮俱損”。所以，通常會把網(wǎng)站拆分出不同的子站點來單獨宿主。
應(yīng)用都拆了，由于單個數(shù)據(jù)庫的連接，QPS，TPS，I/O處理能力都非常有限，DB層面也可以去做垂直分庫操作
拆分應(yīng)用和DB之后，其實還是會有很多問題。不同的站點，里面可能會有相同邏輯和功能的代碼。當(dāng)然，對于一些基礎(chǔ)的功能我們可以封裝DLL或者Jar包去到處提供引用，但是這種強(qiáng)依賴也很容易造成一些問題（版本問題、依賴關(guān)系等處理起來非常麻煩）。這樣，傳說中的SOA的價值就得到體現(xiàn)了。
應(yīng)用、服務(wù)之間還是會出現(xiàn)一些依賴問題，這時候，高吞吐量的解耦利器出現(xiàn)了
最后，還介紹一個大型互聯(lián)網(wǎng)公司都用的絕技--分庫分表。個人經(jīng)驗，不是業(yè)務(wù)發(fā)站和各方面非常迫切，不要輕易走這一步。
因為分庫分表誰都會干，關(guān)鍵是拆完之后怎么辦。目前，市面上還沒有完全開源免費的方案，能讓你一勞永逸地解決數(shù)據(jù)庫拆分問題。
