開篇明義：

【大型網(wǎng)站技術(shù)架構(gòu)筆記】系列是閱讀《大型網(wǎng)站技術(shù)架構(gòu)核心原理與實(shí)踐》一書的一些筆記，記錄了原書的一些重要內(nèi)容以及我的個(gè)人理解。其中很多內(nèi)容網(wǎng)上都能找得到。其實(shí)整本書，我最贊同的是作者闡述的網(wǎng)站架構(gòu)的價(jià)值觀——“業(yè)務(wù)成就技術(shù)，而不是相反”。在沒有業(yè)務(wù)場(chǎng)景的時(shí)候就一味追逐架構(gòu)，為技術(shù)而技術(shù)，或者一上來就想要設(shè)計(jì)出一個(gè)可以適用所有場(chǎng)景的解決方案，是不理智的。我們有的時(shí)候可能會(huì)陷入技術(shù)的怪圈而忘了考慮業(yè)務(wù)本身。我曾經(jīng)看到的一句我很喜歡的話，在這邊也與諸君分享：好的架構(gòu)都是進(jìn)化來的，不是設(shè)計(jì)來的。

以下為 （一）演化過程 內(nèi)容：

一、初始階段

初始階段考慮到使用量規(guī)范較小，且快速開發(fā)等原因，采用單服務(wù)器，將文件、數(shù)據(jù)庫(kù)與應(yīng)用程序一起部署即可。語(yǔ)言可以采用LAMP。如下圖：

二、應(yīng)用服務(wù)于數(shù)據(jù)服務(wù)分離

隨著訪問量的增多，導(dǎo)致存儲(chǔ)空間不足，所以需要將應(yīng)用與數(shù)據(jù)存儲(chǔ)分離部署。文件和數(shù)據(jù)庫(kù)存儲(chǔ)需要分開。以避免由于大文件io而導(dǎo)致實(shí)時(shí)數(shù)據(jù)庫(kù)服務(wù)的長(zhǎng)響應(yīng)延時(shí)。文件服務(wù)器需要更多的磁盤空間，數(shù)據(jù)庫(kù)服務(wù)由于需要進(jìn)行磁盤檢索和數(shù)據(jù)緩存，所以需要較多的磁盤和內(nèi)存。而應(yīng)用服務(wù)器由于需要業(yè)務(wù)邏輯帶來的頻繁密集計(jì)算，所以需要較好的CPU。如下圖。

三、使用緩存改善網(wǎng)站性能

網(wǎng)站訪問中，對(duì)訪問頻率比較高的數(shù)據(jù)進(jìn)行本地緩存和分布式緩存，能夠很好地提高網(wǎng)站性能。什么時(shí)候采用本地緩存，什么時(shí)候采用分布式緩存呢？一些公司會(huì)選擇將熱點(diǎn)數(shù)據(jù)存入本地緩存，同時(shí)異步寫入分布式緩存。而更多時(shí)候，我們較少采用本地緩存，因?yàn)槠鋾?huì)占用寶貴的應(yīng)用程序的內(nèi)存空間。采用本地緩存只有那種占用少量?jī)?nèi)存，且使用率非常高的數(shù)據(jù)。比如每次請(qǐng)求都需要判斷用戶是否在黑名單中。此時(shí)就可以把名單加載入本地緩存。分布式緩存我們常用的就是memcached和redis。二者的伸縮性都非常優(yōu)秀。

四、應(yīng)用服務(wù)集群化

單一的服務(wù)器存在著并發(fā)處理能力不足，高峰期負(fù)載過高，單點(diǎn)等問題。此時(shí)可以用過簡(jiǎn)單的同構(gòu)集群化部署來解決這一問題。

 五、數(shù)據(jù)庫(kù)讀寫分離

    隨著網(wǎng)站的發(fā)展，數(shù)據(jù)庫(kù)的負(fù)載會(huì)變得越來越大。而且讀、寫數(shù)據(jù)庫(kù)的操作本身就不是一個(gè)時(shí)間量級(jí)上的操作。如果都混在一起處理，則將很可能導(dǎo)致操作長(zhǎng)時(shí)間阻塞等其他問題。大部分的主流數(shù)據(jù)庫(kù)都自帶主從熱備的功能，所以部署起來還是比較簡(jiǎn)單的。而讀寫分離以及下面將提到的分庫(kù)之后，我們常會(huì)采用一些中間件來對(duì)這個(gè)底層數(shù)據(jù)訪問進(jìn)行封裝，從而對(duì)應(yīng)用透明。比如mybatis有阿里巴巴的cobar client框架。讀寫分離后，我們的應(yīng)用服務(wù)的設(shè)計(jì)中，就需要慎重考慮，讀寫同步的延時(shí)這一最終一致性的保證，對(duì)用戶體驗(yàn)帶來的影響是否可以接受。

六、采用其他緩存代理技術(shù)

以上說的基本都是服務(wù)器端的優(yōu)化，而用戶訪問網(wǎng)站時(shí)候，帶寬、地域等其他因素會(huì)對(duì)訪問體驗(yàn)帶來不可忽視的影響。來改善這一體驗(yàn)，加快網(wǎng)站訪問速度的辦法主要有cdn加速和反向代理。可以認(rèn)為cdn是一種特殊的反向代理，其也是基于反向代理的原理過來實(shí)現(xiàn)的緩存和加速。其主要緩存一些靜態(tài)資源到離用戶最近的網(wǎng)絡(luò)提供商的機(jī)房。而此處的反向代理則是部署在網(wǎng)站服務(wù)端的機(jī)房。其既可以進(jìn)行一些靜態(tài)數(shù)據(jù)的高速緩存，也由于采用了SSL與內(nèi)部服務(wù)器進(jìn)行交互從而節(jié)省了大量開銷。

七、采用分布式數(shù)據(jù)庫(kù)和分布式文件系統(tǒng)

隨著網(wǎng)站規(guī)模的增大，單一的數(shù)據(jù)庫(kù)和文件服務(wù)器已經(jīng)無法很好迎合業(yè)務(wù)場(chǎng)景。所以同理地，也會(huì)將其集群化部署。

八、采用nosql和搜索引擎

隨著數(shù)據(jù)需求越來越復(fù)雜，比如需要對(duì)log進(jìn)行存儲(chǔ)和分析以及檢索。此時(shí)可以引入nosql數(shù)據(jù)庫(kù)（如mongodb、hbase等）和搜索引擎技術(shù)（如lucense等）。同時(shí)，此時(shí)的數(shù)據(jù)源可能已經(jīng)比較多，可以來自關(guān)系型數(shù)據(jù)庫(kù)集群、非關(guān)系型數(shù)據(jù)庫(kù)、緩存、文件系統(tǒng)甚至從消息隊(duì)列訂閱的數(shù)據(jù)等等。所以需要一個(gè)統(tǒng)一的數(shù)據(jù)訪問模塊（DAL）來統(tǒng)一對(duì)這一過程進(jìn)行封裝和管理。

九、業(yè)務(wù)拆分與分布式化

前面我們提到，對(duì)業(yè)務(wù)服務(wù)進(jìn)行同構(gòu)部署來實(shí)現(xiàn)業(yè)務(wù)的并發(fā)處理。而我們知道這樣簡(jiǎn)單的加機(jī)器在前期確實(shí)可以實(shí)現(xiàn)服務(wù)性能的線性增長(zhǎng)，但是到了后期，并發(fā)量上來了之后，會(huì)發(fā)現(xiàn)這一處理將會(huì)很快達(dá)到瓶頸。而且于此同時(shí)，各個(gè)子業(yè)務(wù)的差異性帶來的架構(gòu)以及請(qǐng)求量方面的差異將日趨明顯，如果還這樣進(jìn)行同構(gòu)化的混部，其服務(wù)的性能將可能最終跟不上業(yè)務(wù)的發(fā)展，甚至可能導(dǎo)致雪崩。所以最好的做法，就是對(duì)業(yè)務(wù)服務(wù)進(jìn)行垂直拆分。同時(shí)對(duì)基礎(chǔ)服務(wù)進(jìn)行水平拆分。真正實(shí)現(xiàn)SOA。

如此，便是一個(gè)網(wǎng)站架構(gòu)演化的常見路徑