大型互連網網站架構心得

大型互連網網站架構心得之一：分

轉自 ： 朱曄 ID：LoveCherry  http://blog.csdn.net/LoveCherry/archive/2008/06/19/2564096.aspx

我們知道，對於一個大型網站來說，延展性是非常重要的，怎麼樣在縱向和橫向有良好的延展性，就需要在做架構設計的時候考慮到一個分的原則，我想在多個方面說一下怎麼分：

首先是橫向的分：
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都要好

大型互連網網站架構心得之二：並於換

“分”是一個比較大的原則也是一個比較高層的原則，這次我想說一下其它兩個原則：並與換。

  並  為什麼要分？是因為我們希望通過分來提高系統的承載能力，那並又是並什麼呢？我想了一下有幾個方面可以並： 1.       合并使用者請求，最基本的就是合并CSS/圖片/指令碼，還可以合并頁面。不過合并就可能產生流量的浪費，需要有一個平衡點。2.       合并介面的粒度，如果做分布式應用的話，我們可能不會直接存取資料庫而是調用應用程式層提供的介面，由於是網路調用，代價比較大，因此在設計的時候盡量提供粒度比較粗的介面，一次調用返回比較多的資料，而不是細化到添加刪除修改的層次。3.       合并介面的部署，對於頻繁的跨機器調用可以考慮有一些資料冗餘，把跨網路的服務編程進程間通訊，甚至轉到用戶端來做。比如論壇發貼時候髒詞的過濾，直接調用應用程式層提供的介面（跨機器）是可以的，但是可能代價比較大，可以把這個介面使用IPC方式部署在本機。  換 時間換空間，空間換時間是常見的做法，具體一點說： 1.       緩衝。緩衝的重要性早電腦的硬體中就有重要的體現。對於網站，有很多種緩衝，可以是用戶端資源的緩衝，可以是網頁輸出快取，也可以是應用程式層的資料緩衝，目的都是一樣的，或是減少了伺服器請求次數，或是減少了請求的處理過程，或是減少了資料庫的訪問次數。當然，產生靜態檔案也可以算是一種緩衝。不訪問磁碟固然不可能，但是我們要極大限度降低磁碟訪問的機會。2.       有的時候為了擷取極快的響應，我們還會不惜代價採用重複計算。比如，我們的某個操作很可能會由於網路問題等原因響應比較慢，在設計的時候可以有一個統一的處理介面，由這個介面分發到不同的伺服器去非同步實現這個操作，哪個伺服器先返回了結果我們就用這個結果，然後殺死其他伺服器的冗餘操作。3.       網站一般追求比較快的響應，一般不太會在比較高的層次用時間來換取空間，但是在一些使用者專屬資料的處理演算法上可能還是會考慮到空間的節省問題。4.       有的時候我們會用一些彙總表來存放彙總資料，也就是進行一些預計算提高複雜計算（比如報表）的效能。當然，對於資料分析，構建多維資料庫也是一種不錯的選擇。 有很多網友留言說說的比較粗，沒有什麼具體的東西。我覺得架構這個東西很難去說具體怎麼做，因為具體實施的時候要看情況去應用的，由於沒有完美的東西，所以做架構通常是去做一個平衡，很可能某一個側重不同會影響到架構的實施。希望我的這些文章能給大家一個提示的作用，看了之後如果你覺得“這點我倒沒有考慮到，以後要注意”那或許就是最大的協助了，下面我想說一些其它方面的問題，每一條都很零散，算是一個補充吧： 1.       到底是採用已有的東西還是自己去做需要詳細考慮的，採用別人的東西可能比較穩定，但是自己的控制少了一點，採用自己做的東西可以很靈活，但是可能會問題比較多。不管怎麼樣，我們在採用一個第三方架構的時候務必要進行縝密的調查，看到他的不足，否則項目很可能在後期被這個架構制約，反之，決定自己去做一個架構的時候也要看到自己需要什麼其他架構不能提供的東西。2.       資料轉送的時候可以做壓縮，但要考慮到壓縮解壓縮需要CPU資源，在IO（磁碟，頻寬，傳輸能力）和CPU之間有一個平衡的考慮。3.       理想的延展性架構是可以自由增加或替換伺服器，無需去停機維護或做很大的調整。在使用一個統一的調度中心來調度這些伺服器，分配請求的時候，我們要考慮一下調度伺服器能承受多少流量。4.       使用大量的廉價伺服器還是少量的高配伺服器？如何根據需求來組合伺服器發揮最大作用。5.       對於分布式構架，我們盡量讓每一個節點保持簡單的邏輯，盡量減少同一層次節點之間的依賴，另外。需要有統一的地方來管理所有的節點。6.       功能分解、使用非同步進行整合、容錯移轉、失效保護。7.       軟體的架構升級和電腦硬體的架構升級很像，可能有一段時期，我們是在慢慢提高整體能力，2年也才提高了幾倍，之後發現只有通過某種徹底的架構改變才能提高數十倍的能力，升級之後，我們或許又會遇到其他問題。就像CPU，是簡單提高主頻還是徹底更換架構。8.       資料方面，讀寫分離、資料庫分隔、功能劃分、緩衝、鏡像。9.       硬體網路上的架構很重要，但軟體開發中的一些細節不可忽略，好的架構不意味著不需要代碼審閱。