大型網站技術架構的演進

最近我在閱讀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的分時賣票就是一個典型例子。

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