你是如何看待技術架構演進？

一個只分享架構技術乾貨的公眾號

網站技術架構為什麼會演進

我個人總結出來我們的技術架構演進的兩種驅動力，驅動著我們為什麼演進網站的技術架構：

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，是另一個很大的話題，不是本篇文章的範疇。

我從程立 08 年的演講中截個圖來說明 SOA 後的架構大概是怎樣的：

- 非功能性問題

– 安全性問題、監控問題

– 發布問題：新的架構意味著新的發布方式

– 分機房

– 組織架構的變化

我們的技術架構的變化，勢必會引起我們的組織架構的變化，反之亦然。

這部分看似不應該由我們來管，但是，我覺得，我們技術人員也要參與一部分的組織架構的設計。舉個例子，組織架構的設計會涉及績效，而績效有時很像一個國家的法律。如果一個國家的法律不健全，會發生什麼？你懂的。

同時，我們還必須考慮人員對新架構的學習成本。

這部分我目前在看相關的書籍，還沒有一個系統的認識。

總結

- 關於演進的順序

在現實中，技術架構的演進不一定就是按文章從頭到尾這樣列下來的，所以，要視具體情況來下決定。

- 關於傳統演進與現代有「雲」環境下的演進

很可惜，只有李智慧談到雲，而且只點了一下——「現在越來越多人的網站從建立之初就是搭建在大型網站提供的雲計算服務基礎之上，所需的一切資源：計算、存儲、網路都可以按需購買線性伸縮，不需要自己一點一點地拼湊各種資源，綜合使用各種技術方案逐步去完善自己的網站架構」。

因為我用「雲」的時間也不長，還不能總結出有雲架構與傳統的無雲架構在演進的時候有什麼不同。

說回傳統的架構演進，我自己總結和思考的結果是：

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

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

「如果覺得本文有用，轉發一下分享給更多的人看到吧」

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！