我們知道，對於一個大型門戶網站來說，可伸縮性是非常重要的，怎麼樣在縱向和橫向有良好的可伸縮性，就需要在做架構設計的時候考慮到一個分的原則，我想在多個方面說一下怎麼分：
首先是橫向的分：
1. 大的網站化解為多個小網站：當我們一個網站有多個功能的時候，可以考慮把這個網站拆分成幾個小模塊，每一個模塊可以是一個網站，這樣的話我們到時候就可以很靈活地去把這些網站部署到不同的服務器上。
2. 靜態動態分離：靜態文件和動態文件最好分離開成2個網站，我們知道靜態網站和動態網站對服務器來說壓力的側重不同，前者可能重IO後者重CPU，那麼我們在選擇硬件的時候也可以有側重，而且靜態和動態內容的緩存策略也不一樣。典型的應用，我們一般會有獨立的文件或圖片服務器。
3. 按照功能來分：比如有一個模塊是負責上傳的，上傳操作很消耗時間，如果和其它應用混在一起的話很可能，一點點訪問就會使服務器癱瘓，這種特殊的模塊應該分開。安全的不安全的也要分開，還需要考慮到以後SSL的購買。
4. 我們不一定要全部用自己的服務器，搜索、報表可以依靠別人的服務，比如google的搜索和報表服務，自己做的不一定比得過別人，服務器帶寬都省了。
其次是縱向的分：
1. 文件也相當於數據庫，IO的流量可能比數據庫還大，這也算是縱向級別的訪問，上傳的文件圖片一定要和WEB服務器分開。當然，數據庫和網站都放在一個服務器上的很少了，這是最基本的。
2. 對於涉及到數據庫訪問的動態程序來說，我們可以使用一個中間層（所謂的應用層或邏輯層）來訪問數據庫（部署在獨立的服務器上），最大的好處就是緩存和靈活性。緩存的內存占用比較大，我們要把它和網站進程分開，而且這樣做我們可以很方便的去改變一些數據訪問的策略，即使到時候數據庫有分布的話在這裡可以做一個調配工作，這樣靈活性就很大了。還有好處是中間層可以做電線網通橋梁，可能網通訪問雙線再訪問電信會比網通直接訪問電信服務器快。
有人說我不分，我可以做負載均衡，對，是可以的，但是如果分的話，同樣的10台機器肯定比不分10台機器可以承受更多的訪問量，而且對硬件的需求可能不會很高，因為知道需要哪個硬件特別好。爭取讓每一個服務期都不空閒，又都不是太忙，合理進行組合調整和擴充，這樣的系統伸縮性就高了，能根據訪問量來調整的前提就是之前有考慮到分，分的好處是靈活性、伸縮性、隔離性以及安全性。
對服務器來說，我們有幾點是要長期觀察的，任何一點都可能是瓶頸：
1. CPU：動態文件的解析需要比較多的CPU，CPU出現瓶頸就要看是不是哪個功能過長時間占用線程，如果是就分出去。或者就是每一個請求處理時間不長，但是訪問量很高，那麼就加服務器。CPU是好東西，不能讓他干等，不做事情。
2. 內存：緩存從IIS進程獨立出去，一般對WEB服務器來說內存不夠的情況不是很多。內存比磁盤快，要合理利用。
3. 磁盤IO：用性能監視器找到哪些文件IO特別大，找到了就分到獨立的一組文件服務器上去，或者直接做CDN。磁盤慢，大規模讀取數據的應用靠緩存，大規模寫入數據的應用可以靠隊列來降低突發的並發。
4. 網絡：我們知道，網絡的通訊是比較慢的，比磁盤還慢，如果是做分布式緩存，分布式計算的話，要考慮到物理服務器之間網絡通訊的時間，當然，在流量大了以後，這可以提高系統的接納能力一個等級。靜態內容可以借助CSD分擔一部分，在做服務器假設的時候還要考慮中國特色的電信網通情況以及防火牆。
對SQL Server數據庫服務器來說[UPDATE]：
其實還是水平分割和縱向分割，一個二維表，水平分割就是橫過來切一刀，縱向分割就是豎直切一刀：
1、縱向分割就是，我們不同的應用可以分到不同的DB中，不同的實例中，或者說把某個擁有很多字段的表拆分成小表。
2、橫向分割就是，某些應用可能不負載，比如用戶注冊，但是用戶表會非常大，可以把大表分開。可以采用表分區，數據存儲在不同文件上，然後再部署到獨立物理服務器增加IO吞吐以改善讀寫性能，土一點的做法就是自己定期把老的數據存檔。表分區的另外一個優勢可以增加數據查詢速度，因為我們的頁索引可以有多層了，就像一個文件夾中的文件不要太多，多分幾層文件夾一樣。
3、還可以通過數據庫鏡像、復制訂閱、事物日志，把讀寫分開到不同的鏡像物理數據庫上，一般來說夠用，如果還不行可以用硬件來實現數據庫的負載均衡。當然，對於BI，我們可能還會有數據倉庫。
架構上考慮到了這些之後，流量大了，就可以在這個的基礎上再去調整或者做WEB服務器或者應用服務器的負載均衡。很多時候我們都是在重復發現問題-》找到瓶頸-》解決這個過程。
典型的架構如下：
動態WEB服務器配好點的CPU，靜態WEB服務器和文件服務器磁盤好點
應用服務器內存大點，緩存服務器也是，數據庫服務器當然內存和CPU都要好
