大型網際網路網站架構心得之二

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

 并

為什麼要分？是因為我們希望通過分來提高系統的承載能力，那并又是并什麼呢？我想了一下有幾個方面可以并：

1.      合并使用者請求，最基本的就是合并CSS/圖檔/腳本，還可以合并頁面。不過合并就可能産生流量的浪費，需要有一個平衡點。

2.      合并接口的粒度，如果做分布式應用的話，我們可能不會直接通路資料庫而是調用應用層提供的接口，由于是網絡調用，代價比較大，是以在設計的時候盡量提供粒度比較粗的接口，一次調用傳回比較多的資料，而不是細化到添加删除修改的層次。

3.      合并接口的部署，對于頻繁的跨機器調用可以考慮有一些資料備援，把跨網絡的服務程式設計程序間通訊，甚至轉到用戶端來做。比如論壇發貼時候髒詞的過濾，直接調用應用層提供的接口（跨機器）是可以的，但是可能代價比較大，可以把這個接口使用IPC方式部署在本機。

換

時間換空間，空間換時間是常見的做法，具體一點說：

1.      緩存。緩存的重要性早計算機的硬體中就有重要的展現。對于網站，有很多種緩存，可以是用戶端資源的緩存，可以是頁面輸出緩存，也可以是應用層的資料緩存，目的都是一樣的，或是減少了伺服器請求次數，或是減少了請求的處理過程，或是減少了資料庫的通路次數。當然，生成靜态檔案也可以算是一種緩存。不通路磁盤固然不可能，但是我們要極大限度降低磁盤通路的機會。

2.      有的時候為了擷取極快的響應，我們還會不惜代價采用重複計算。比如，我們的某個操作很可能會由于網絡問題等原因響應比較慢，在設計的時候可以有一個統一的處理接口，由這個接口分發到不同的伺服器去異步實作這個操作，哪個伺服器先傳回了結果我們就用這個結果，然後殺死其他伺服器的備援操作。

3.      網站一般追求比較快的響應，一般不太會在比較高的層次用時間來換取空間，但是在一些使用者獨有資料的處理算法上可能還是會考慮到空間的節省問題。

4.      有的時候我們會用一些聚合表來存放聚合資料，也就是進行一些預計算提高複雜計算（比如報表）的性能。當然，對于資料分析，建構多元資料庫也是一種不錯的選擇。

有很多網友留言說說的比較粗，沒有什麼具體的東西。我覺得架構這個東西很難去說具體怎麼做，因為具體實施的時候要看情況去應用的，由于沒有完美的東西，是以做架構通常是去做一個平衡，很可能某一個側重不同會影響到架構的實施。希望我的這些文章能給大家一個提示的作用，看了之後如果你覺得“這點我倒沒有考慮到，以後要注意”那或許就是最大的幫助了，下面我想說一些其它方面的問題，每一條都很零散，算是一個補充吧：

1.      到底是采用已有的東西還是自己去做需要詳細考慮的，采用别人的東西可能比較穩定，但是自己的控制少了一點，采用自己做的東西可以很靈活，但是可能會問題比較多。不管怎麼樣，我們在采用一個第三方架構的時候務必要進行缜密的調查，看到他的不足，否則項目很可能在後期被這個架構制約，反之，決定自己去做一個架構的時候也要看到自己需要什麼其他架構不能提供的東西。

2.      資料傳輸的時候可以做壓縮，但要考慮到壓縮解壓縮需要CPU資源，在IO（磁盤，帶寬，傳輸能力）和CPU之間有一個平衡的考慮。

3.      理想的可伸縮性架構是可以自由增加或替換伺服器，無需去停機維護或做很大的調整。在使用一個統一的排程中心來排程這些伺服器，配置設定請求的時候，我們要考慮一下排程伺服器能承受多少流量。

4.      使用大量的廉價伺服器還是少量的高配伺服器？如何根據需求來組合伺服器發揮最大作用。

5.      對于分布式構架，我們盡量讓每一個節點保持簡單的邏輯，盡量減少同一層次節點之間的依賴，另外。需要有統一的地方來管理所有的節點。

6.      功能分解、使用異步進行整合、故障轉移、失效保護。

7.      軟體的架構更新和計算機硬體的架構更新很像，可能有一段時期，我們是在慢慢提高整體能力，2年也才提高了幾倍，之後發現隻有通過某種徹底的架構改變才能提高數十倍的能力，更新之後，我們或許又會遇到其他問題。就像CPU，是簡單提高主頻還是徹底更換架構。

8.      資料方面，讀寫分離、資料庫分隔、功能劃分、緩存、鏡像。

9.      硬體網絡上的架構很重要，但軟體開發中的一些細節不可忽略，好的架構不意味着不需要代碼審閱。

寫的有點亂，請大家讨論。