我們知道，對于一個大型網(wǎng)站來說，可伸縮性是非常重要的，怎么樣在縱向和橫向有良好的可伸縮性，就需要在做架構(gòu)設(shè)計的時候考慮到一個分的原則，我想在多個方面說一下怎么分：
首先是橫向的分：
1. 大的網(wǎng)站化解為多個小網(wǎng)站：當(dāng)我們一個網(wǎng)站有多個功能的時候，可以考慮把這個網(wǎng)站拆分成幾個小模塊，每一個模塊可以是一個網(wǎng)站，這樣的話我們到時候就可以很靈活地去把這些網(wǎng)站部署到不同的服務(wù)器上。
2. 靜態(tài)動態(tài)分離：靜態(tài)文件和動態(tài)文件最好分離開成2個網(wǎng)站，我們知道靜態(tài)網(wǎng)站和動態(tài)網(wǎng)站對服務(wù)器來說壓力的側(cè)重不同，前者可能重IO后者重CPU，那么我們 在選擇硬件的時候也可以有側(cè)重，而且靜態(tài)和動態(tài)內(nèi)容的緩存策略也不一樣。典型的應(yīng)用，我們一般會有獨(dú)立的文件或圖片服務(wù)器。而且，使用不用的域名還可以提 高瀏覽器并行加載的能力。
3. 按照功能來分：比如有一個模塊是負(fù)責(zé)上傳的，上傳操作很消耗時間，如果和其它應(yīng)用混在一起的話很可能，一點(diǎn)點(diǎn)訪問就會使服務(wù)器癱瘓，這種特殊的模塊應(yīng)該分開。安全的不安全的也要分開，還需要考慮到以后SSL的購買。
4. 我們不一定要全部用自己的服務(wù)器，搜索、報表可以依靠別人的服務(wù)，比如google的搜索和報表服務(wù)，自己做的不一定比得過別人，服務(wù)器帶寬都省了。
其次是縱向的分：
1. 文件也相當(dāng)于數(shù)據(jù)庫，IO的流量可能比數(shù)據(jù)庫還大，這也算是縱向級別的訪問，上傳的文件圖片一定要和WEB服務(wù)器分開。當(dāng)然，數(shù)據(jù)庫和網(wǎng)站都放在一個服務(wù)器上的很少了，這是最基本的。
2. 對于涉及到數(shù)據(jù)庫訪問的動態(tài)程序來說，我們可以使用一個中間層（所謂的應(yīng)用層或邏輯層）來訪問數(shù)據(jù)庫（部署在獨(dú)立的服務(wù)器上），最大的好處就是緩存和靈活 性。緩存的內(nèi)存占用比較大，我們要把它和網(wǎng)站進(jìn)程分開，而且這樣做我們可以很方便的去改變一些數(shù)據(jù)訪問的策略，即使到時候數(shù)據(jù)庫有分布的話在這里可以做一 個調(diào)配工作，這樣靈活性就很大了。還有好處是中間層可以做電線網(wǎng)通橋梁，可能網(wǎng)通訪問雙線再訪問電信會比網(wǎng)通直接訪問電信服務(wù)器快。
有人說我不分，我可以做負(fù)載均衡，對，是可以的，但是如果分的話，同樣的10臺機(jī)器肯定比不分10臺機(jī)器可以承受更多的訪問量，而且對硬件的需求可能不 會很高，因?yàn)橹佬枰膫€硬件特別好。爭取讓每一個服務(wù)期都不空閑，又都不是太忙，合理進(jìn)行組合調(diào)整和擴(kuò)充，這樣的系統(tǒng)伸縮性就高了，能根據(jù)訪問量來調(diào)整 的前提就是之前有考慮到分，分的好處是靈活性、伸縮性、隔離性以及安全性。
對服務(wù)器來說，我們有幾點(diǎn)是要長期觀察的，任何一點(diǎn)都可能是瓶頸：
1. CPU：動態(tài)文件的解析需要比較多的CPU，CPU出現(xiàn)瓶頸就要看是不是哪個功能過長時間占用線程，如果是就分出去。或者就是每一個請求處理時間不長，但是訪問量很高，那么就加服務(wù)器。CPU是好東西，不能讓他干等，不做事情。
2. 內(nèi)存：緩存從IIS進(jìn)程獨(dú)立出去，一般對WEB服務(wù)器來說內(nèi)存不夠的情況不是很多。內(nèi)存比磁盤快，要合理利用。
3. 磁盤IO：用性能監(jiān)視器找到哪些文件IO特別大，找到了就分到獨(dú)立的一組文件服務(wù)器上去，或者直接做CDN。磁盤慢，大規(guī)模讀取數(shù)據(jù)的應(yīng)用靠緩存，大規(guī)模寫入數(shù)據(jù)的應(yīng)用可以靠隊(duì)列來降低突發(fā)的并發(fā)。
4. 網(wǎng)絡(luò)：我們知道，網(wǎng)絡(luò)的通訊是比較慢的，比磁盤還慢，如果是做分布式緩存，分布式計算的話，要考慮到物理服務(wù)器之間網(wǎng)絡(luò)通訊的時間，當(dāng)然，在流量大了以 后，這可以提高系統(tǒng)的接納能力一個等級。靜態(tài)內(nèi)容可以借助CSD分擔(dān)一部分，在做服務(wù)器假設(shè)的時候還要考慮中國特色的電信網(wǎng)通情況以及防火墻。
對SQL SERVER數(shù)據(jù)庫服務(wù)器來說：
其實(shí)還是水平分割和縱向分割，一個二維表，水平分割就是橫過來切一刀，縱向分割就是豎直切一刀：
1、縱向分割就是，我們不同的應(yīng)用可以分到不同的DB中，不同的實(shí)例中，或者說把某個擁有很多字段的表拆分成小表。
2、橫向分割就是，某些應(yīng)用可能不負(fù)載，比如用戶注冊，但是用戶表會非常大，可以把大表分開。可以采用表分區(qū)，數(shù)據(jù)存儲在不同文件上，然后再部署到獨(dú)立 物理服務(wù)器增加IO吞吐以改善讀寫性能，土一點(diǎn)的做法就是自己定期把老的數(shù)據(jù)存檔。表分區(qū)的另外一個優(yōu)勢可以增加數(shù)據(jù)查詢速度，因?yàn)槲覀兊捻撍饕梢杂卸?層了，就像一個文件夾中的文件不要太多，多分幾層文件夾一樣。
3、還可以通過數(shù)據(jù)庫鏡像、復(fù)制訂閱、事物日志，把讀寫分開到不同的鏡像物理數(shù)據(jù)庫上，一般來說夠用，如果還不行可以用硬件來實(shí)現(xiàn)數(shù)據(jù)庫的負(fù)載均衡。當(dāng)然，對于BI，我們可能還會有數(shù)據(jù)倉庫。
架構(gòu)上考慮到了這些之后，流量大了，就可以在這個的基礎(chǔ)上再去調(diào)整或者做WEB服務(wù)器或者應(yīng)用服務(wù)器的負(fù)載均衡。很多時候我們都是在重復(fù)發(fā)現(xiàn)問題-》找到瓶頸-》解決這個過程。
典型的架構(gòu)如下：
動態(tài)WEB服務(wù)器配好點(diǎn)的CPU，靜態(tài)WEB服務(wù)器和文件服務(wù)器磁盤好點(diǎn)
應(yīng)用服務(wù)器內(nèi)存大點(diǎn)，緩存服務(wù)器也是，數(shù)據(jù)庫服務(wù)器當(dāng)然內(nèi)存和CPU都要好
上次說的“分”是一個比較大的原則也是一個比較高層的原則，這次我想說一下其它兩個原則：并與換。
并
為什么要分？是因?yàn)槲覀兿Ｍㄟ^分來提高系統(tǒng)的承載能力，那并又是并什么呢？我想了一下有幾個方面可以并：
1. 合并用戶請求，最基本的就是合并CSS/圖片/腳本，還可以合并頁面。不過合并就可能產(chǎn)生流量的浪費(fèi)，需要有一個平衡點(diǎn)。
2. 合并接口的粒度，如果做分布式應(yīng)用的話，我們可能不會直接訪問數(shù)據(jù)庫而是調(diào)用應(yīng)用層提供的接口，由于是網(wǎng)絡(luò)調(diào)用，代價比較大，因此在設(shè)計的時候盡量提供粒度比較粗的接口，一次調(diào)用返回比較多的數(shù)據(jù)，而不是細(xì)化到添加刪除修改的層次。
3. 合并接口的部署，對于頻繁的跨機(jī)器調(diào)用可以考慮有一些數(shù)據(jù)冗余，把跨網(wǎng)絡(luò)的服務(wù)編程進(jìn)程間通訊，甚至轉(zhuǎn)到客戶端來做。比如論壇發(fā)貼時候臟詞的過濾，直接調(diào)用應(yīng)用層提供的接口（跨機(jī)器）是可以的，但是可能代價比較大，可以把這個接口使用IPC方式部署在本機(jī)。
換
時間換空間，空間換時間是常見的做法，具體一點(diǎn)說：
1. 緩存。緩存的重要性早計算機(jī)的硬件中就有重要的體現(xiàn)。對于網(wǎng)站，有很多種緩存，可以是客戶端資源的緩存，可以是頁面輸出緩存，也可以是應(yīng)用層的數(shù)據(jù)緩存， 目的都是一樣的，或是減少了服務(wù)器請求次數(shù)，或是減少了請求的處理過程，或是減少了數(shù)據(jù)庫的訪問次數(shù)。當(dāng)然，生成靜態(tài)文件也可以算是一種緩存。不訪問磁盤 固然不可能，但是我們要極大限度降低磁盤訪問的機(jī)會。
2. 有的時候?yàn)榱双@取極快的響應(yīng)，我們還會不惜代價采用重復(fù)計算。比如，我們的某個操作很可能會由于網(wǎng)絡(luò)問題等原因響應(yīng)比較慢，在設(shè)計的時候可以有一個統(tǒng)一的 處理接口，由這個接口分發(fā)到不同的服務(wù)器去異步實(shí)現(xiàn)這個操作，哪個服務(wù)器先返回了結(jié)果我們就用這個結(jié)果，然后殺死其他服務(wù)器的冗余操作。
3. 網(wǎng)站一般追求比較快的響應(yīng)，一般不太會在比較高的層次用時間來換取空間，但是在一些用戶獨(dú)有數(shù)據(jù)的處理算法上可能還是會考慮到空間的節(jié)省問題。
4. 有的時候我們會用一些聚合表來存放聚合數(shù)據(jù)，也就是進(jìn)行一些預(yù)計算提高復(fù)雜計算（比如報表）的性能。當(dāng)然，對于數(shù)據(jù)分析，構(gòu)建多維數(shù)據(jù)庫也是一種不錯的選擇。
有很多網(wǎng)友留言說說的比較粗，沒有什么具體的東西。我覺得架構(gòu)這個東西很難去說具體怎么做，因?yàn)榫唧w實(shí)施的時候要看情況去應(yīng)用的，由于沒有完美的東西，所 以做架構(gòu)通常是去做一個平衡，很可能某一個側(cè)重不同會影響到架構(gòu)的實(shí)施。希望我的這些文章能給大家一個提示的作用，看了之后如果你覺得“這點(diǎn)我倒沒有考慮 到，以后要注意”那或許就是最大的幫助了，下面我想說一些其它方面的問題，每一條都很零散，算是一個補(bǔ)充吧：
1. 到底是采用已有的東西還是自己去做需要詳細(xì)考慮的，采用別人的東西可能比較穩(wěn)定，但是自己的控制少了一點(diǎn)，采用自己做的東西可以很靈活，但是可能會問題比 較多。不管怎么樣，我們在采用一個第三方框架的時候務(wù)必要進(jìn)行縝密的調(diào)查，看到他的不足，否則項(xiàng)目很可能在后期被這個框架制約，反之，決定自己去做一個框 架的時候也要看到自己需要什么其他框架不能提供的東西。
2. 數(shù)據(jù)傳輸?shù)臅r候可以做壓縮，但要考慮到壓縮解壓縮需要CPU資源，在IO（磁盤，帶寬，傳輸能力）和CPU之間有一個平衡的考慮。
3. 理想的可伸縮性架構(gòu)是可以自由增加或替換服務(wù)器，無需去停機(jī)維護(hù)或做很大的調(diào)整。在使用一個統(tǒng)一的調(diào)度中心來調(diào)度這些服務(wù)器，分配請求的時候，我們要考慮一下調(diào)度服務(wù)器能承受多少流量。
4. 使用大量的廉價服務(wù)器還是少量的高配服務(wù)器？如何根據(jù)需求來組合服務(wù)器發(fā)揮最大作用。
5. 對于分布式構(gòu)架，我們盡量讓每一個節(jié)點(diǎn)保持簡單的邏輯，盡量減少同一層次節(jié)點(diǎn)之間的依賴，另外。需要有統(tǒng)一的地方來管理所有的節(jié)點(diǎn)。
6. 功能分解、使用異步進(jìn)行整合、故障轉(zhuǎn)移、失效保護(hù)。
7. 軟件的架構(gòu)升級和計算機(jī)硬件的架構(gòu)升級很像，可能有一段時期，我們是在慢慢提高整體能力，2年也才提高了幾倍，之后發(fā)現(xiàn)只有通過某種徹底的架構(gòu)改變才能提高數(shù)十倍的能力，升級之后，我們或許又會遇到其他問題。就像CPU，是簡單提高主頻還是徹底更換架構(gòu)。
8. 數(shù)據(jù)方面，讀寫分離、數(shù)據(jù)庫分隔、功能劃分、緩存、鏡像。
9. 硬件網(wǎng)絡(luò)上的架構(gòu)很重要，但軟件開發(fā)中的一些細(xì)節(jié)不可忽略，好的架構(gòu)不意味著不需要代碼審閱。