大型網站技術架構的演進

最近我在閱讀 2 本關於大型網站架構的書：《大型網站技術架構——核心原理與案例分析》李智慧、《大型網站系統與 Java 中介軟體實踐》曾憲傑。
我期望從這些書中學習到大型網站是如何做架構的，這個過程會遇到什麼問題。當看完這 2 本書後，我總結出兩個大問題：
1. 網站技術架構為什麼會演進？換個說法就是為什麼網站會變大？
2. 演進的過程會遇到什麼問題？或者說為了演進，會遇到什麼問題？

網站技術架構為什麼會演進
我個人總結出來我們的技術架構演進的兩種驅動力，驅動著我們為什麼演進網站的技術架構：
1. 內在驅動力：我們期望把當前的業務做得更好，開發更多新業務
2. 外在驅動力：使用者量的上升、使用者種類的多樣化
這兩種驅動力不是獨立的，更多時候是並行的。我想淘寶就是兩種驅動力並行驅動的結果。
演進的原因很簡單。但是在什麼時機我們就應該演進網站的技術架構了，以及如何演進？面對這些問題，說實話，我沒有任何經驗，再說現實中每家企業當時都面臨的問題都不一樣，所以，我很難從經驗中總結出什麼是演進的時機。
但是我可以從另一個角度切入這個問題：研究網站內外結構，找到這些結構可能出現的問題點，知道或者預見到問題點了，你當然就知道應該怎麼演進了。類似於你瞭解了 PC 機的結構，你也就知道什麼時候要加記憶體了，什麼時候要加硬碟了。

那麼我們先看看網站的外部結構：

外部結構中，我們可以看由以下幾個部分構成：
U：代表使用者群。當使用者群變了，我們的網站如何演進？使用者群的分析，我目前能知道的維度有：數量，種類，地理位置（區域）。
N：代表網路環境。網路環境在每個地區都不同。你可以想像我們為什麼需要 CDN。當我們期望每個區域的使用者都能得到好的體驗，我們的網站如何演進？
S：代表安全。就是我們要安全到什麼程度？這與網站當前所處階段及你網站的性質有關。
C：代表我們的網站。屬於內部結構

網站的內部結構：

內部結構的組成：
A：應用服務。
D：資料服務
總結下來就是我們在考慮網站是否應該演進了或者如何演進時，這些組成部分為我們提供了考慮問題的基準。
那麼我們為什麼不一開始就把網站設計成“大型”的。李智慧在後記裡寫到：“不要企圖去設計一個大型網站”，“原因是網際網路發展執行有其自己的規律，短暫的網際網路歷史已經一再證明這種企圖行不通”。還說了：“大型網站不是設計出來的，而是逐步演化出來的”。對於最後這句話，我需要提醒下：“不是設計出來的”並不代表“隨意設計”。
對於“大型網站的設計”，我個人的看法是現在我們的有“雲”了，計算是可以買的，只要我們的設計能適應“雲”，我是不是就可以一開始就設計大型網站了？

演進的過程會遇到什麼問題
- 最初
從一個小網站說起。一臺伺服器也就足夠了。

- 資料服務與應用服務分離
越來越多的使用者代表著越來越多的資料，一臺伺服器已經滿足不了。我們將資料服務和應用服務分離，給應用伺服器配置更好的 CPU，記憶體。而給資料伺服器配置更好更大的硬碟。

- 使用快取
因為 80% 的業務訪問都集中在 20% 的資料上，如果我們能將這部分資料快取下來，效能一下子就上來了。而快取又分為兩種：本地快取和遠端分散式快取。具體使用哪種？還是兩種都用，我目前不知道。

這裡有一個問題，書沒有提到：應該快取哪些資料？應該有一些原則的吧。
- 使用伺服器叢集
當這臺伺服器的處理能力達到上限時，它就會成為瓶頸。雖然你是可以通過購買更強大的硬體，但總會有上限。這時，我們就需要伺服器的叢集。這時，就必須加個新東西：負載均衡排程伺服器。

但是，使用伺服器叢集時，需要考慮一個問題：Session 的管理問題。Session 的管理有以下幾種方式：
Session Sticky：打個比方就是如果我們每次吃飯都要保證我們用的是自己的碗筷，而只要我們在一家飯店裡存著我們的碗筷，只要我們每次去這家飯店吃飯就好了。

這種方式的問題：
1. 一臺伺服器重啟，上面的 session 都沒了
2. 負載均衡器成了有狀態的機器，要實現容災會有麻煩
Session 複製：就像我們在所有的飯店裡都存一份自己的碗筷。不適合做大規模叢集，適合機器不多的情況

這種方案的問題：
1. 應用伺服器間頻寬問題
2. 大量使用者線上時，佔用記憶體過多
基於 Cookie：類似於每次吃飯都把自己的碗筷帶上

這種方案的問題：
1. Cookie 的長度限制
2. 安全性
3. 資料中心外部頻寬的消耗
4. 效能影響，伺服器處理每次的請求的內容又多了
Session 伺服器：同樣可以是叢集的。這種方式適用於 session 數量及 web 伺服器數量大的情況

這種方案需要考慮的是：
1. 保證 session 伺服器的可用性
2. 我們在寫應用時需要做調整，我目前不知道應用伺服器能否將這部分邏輯透明化
- 資料庫讀寫分離
資料庫的一部分讀（未快取、快取過期）及所有的寫操作都還需要經過資料庫。當使用者量達到一定量，資料庫將會成為瓶頸。這邊我們使用資料庫提供的熱備功能，將所有的讀操作引入 slave 伺服器。注意：讀寫分離解決的是讀壓力大的問題。

因為資料庫的讀寫分離了，所以，我們的應用程式也得做相應的變化。我們實現一個資料訪問模組使上層寫程式碼的人不知道讀寫分離的存在。這裡，我很想知道如果我使用 ORM 模型時，如何實現讀寫的分離？

資料庫讀寫分離會遇到如下問題：

• 資料複製問題： 考慮時延、資料庫的支援、複製條件支援。不要忘了，分機房後，這個更是問題。
• 應用對於資料來源的路由問題

- 使用反向代理和 CDN 加速網站響應
使用 CDN 可以很好的解決不同的地區的訪問速度問題，反向代理則在伺服器機房中快取使用者資源：

- 使用分散式檔案系統

- 資料庫專庫專用：資料垂直拆分。
這樣可以解決部分資料寫的問題

垂直拆分資料庫時，會遇到的問題：

• 跨業務的事務
• 應用的配置項多了

關於事務的問題，有兩種辦法：

• 使用分散式事務
• 去掉事務或不追求強事務

- 某個業務的資料表的資料量或者更新量達到了單個資料庫的瓶頸：資料水平拆分
將同一個表的資料拆分到兩個資料庫中

資料水平拆分會遇到的問題：

• SQL 的路由問題，需要知道某個 User 在哪個資料庫上。
• 主鍵的策略會有不同。
• 查詢時的效能問題，如分頁問題

 

• 使用搜尋引擎：解決資料查詢問題
• 部分場景可使用 NoSQL 提高效能
• 開發資料統一訪問模組：解決上層應用開發的資料來源問題

- 業務拆分及應用拆分
網站的業務日益複雜，建立一個獨立的大型應用來完成這所有的業務變得不實際。從管理角度來，也不方便管理。然而，業務的拆分很難找到一種通用的模式，這是一個企業管理問題和技術問題的混合問題。同時和每個企業的具體情況有關。
但是從這兩本書來看，最終架構都走向服務化，也就是 SOA。而如何實現 SOA，是另一個很大的話題，不是本篇文章的範疇。
我從程立 08 年的演講中截個圖來說明 SOA 後的架構大概是怎樣的：

- 非功能性問題
– 安全性問題、監控問題
– 釋出問題：新的架構意味著新的釋出方式
– 分機房
– 這兩本書都沒有說分機房的問題。我沒有經驗，可是也可以猜到如果要分機房了，所有上面的問題都可能要重新考慮。
– 組織架構的變化 
我們的技術架構的變化，勢必會引起我們的組織架構的變化，反之亦然。
這部分看似不應該由我們來管，但是，我覺得，我們技術人員也要參與一部分的組織架構的設計。舉個例子，組織架構的設計會涉及績效，而績效有時很像一個國家的法律。如果一個國家的法律不健全，會發生什麼？你懂的。
同時，我們還必須考慮人員對新架構的學習成本。
這部分我目前在看相關的書籍，還沒有一個系統的認識。
 
總結：
- 關於演進的順序
在現實中，技術架構的演進不一定就是按文章從頭到尾這樣列下來的，所以，要視具體情況來下決定。
- 關於傳統演進與現代有“雲”環境下的演進
很可惜，只有李智慧談到雲，而且只點了一下——“現在越來越多人的網站從建立之初就是搭建在大型網站提供的雲端計算服務基礎之上，所需的一切資源：計算、儲存、網路都可以按需購買線性伸縮，不需要自己一點一點地拼湊各種資源，綜合使用各種技術方案逐步去完善自己的網站架構”。
因為我用“雲”的時間也不長，還不能總結出有云架構與傳統的無雲架構在演進的時候有什麼不同。

說回傳統的架構演進，我自己總結和思考的結果是：
在對網站進行架構調整時，可以從兩大的維度考慮：資料服務和應用服務。而這個調整的過程中，需要分清當前哪個點是瓶頸，需要知道哪個點優化的優先順序最高。同時，最重要的一點：我們雖然作為技術人員，也應該去學習業務知識，這樣我們在考慮問題時分清哪些是業務問題，哪些是技術問題，分清後才能對症下藥。你要知道有些問題用技術手段並不比用業務手段更有效。12306 的分時賣票就是一個典型例子。

以上總結及思考有不對，歡迎斧正。非常感謝。