大型網站的演化之路——讀《大型網站技術架構》
____

author：姚毛毛的部落格 & 妖生

01 大型網站or軟體有什麼特點？

高併發、大流量，微信都日活10億了
7×24的高可用，俗稱的4個9（99.99%）
海量資料的儲存與管理
全國甚至全球的使用者分佈，複雜網路
安全環境很差
需求變更頻繁，需要快速迭代

最後，是漸進式的發展。
所有大型網站都是從一個小網站發展起來的。
好的網站與複雜的架構都是演化來的，而不是一開始就設計好的。
當年才出發的時候，誰也想不到微信可以日活十億，最初的時候肯定也沒有成千上萬的伺服器叢集對不對。

02 最初與第一次的演化之路：應用與資料的分離

我們最初的小型網站是什麼樣的？
從邏輯上看，一個應用服務、一個數據庫；從物理上看，一臺伺服器就搞定了。
在使用者量增多後，我們開始需要將應用跟資料庫分離。

那應用跟資料庫所需要的伺服器配置是一樣的嗎？
當然是NO。
應用需要處理更多的業務邏輯，所以需要好一點多一點的CPU。
資料庫則要快速檢索磁碟跟放置資料快取，因此需要快一點的磁碟和大一點的記憶體。

當然，所有演進的目的都是想更高、更快、更強。只是有時候沒法做到面面俱到，需要取捨。

03 第二次演進：快取優化

恭喜你，網站優化了一次，體驗變好了，使用者也開始增多了，可是煩惱的又來了。
使用者的增多，帶來的資料庫壓力也大了，怎麼辦?

在IT行業甚至所有現實模型中都存在一個顛撲不破的真理，即二八原則。
在網站訪問上也是如此，80%的業務訪問總是集中在20%的資料上。
淘寶買東西就翻前面那麼一點，淘寶已經為我們找好了信用好、成交量高的賣家；百度一下也就是翻前面那兩三頁，甚至一頁裡的前幾條（如果沒有廣告的話）；微博熱搜吃瓜也就看前十吧，後面的你會一個個點過去嗎？

那麼，把這20%的資料快取起來，是不是就可以減少資料庫的訪問壓力，提高網站訪問效能了？
YES。

那麼，怎麼快取呢？
我們通常使用的快取方案有兩種，即應用伺服器上的本地快取，和獨立的分散式快取。

有什麼優缺點？
本地快取速度快些，但是受限於應用伺服器的記憶體，且會導致與應用爭用的情況。
獨立的分散式快取可以使用叢集，速度稍慢，但也很快，基本只有網路IO的消耗；但是缺點就一個字：貴。因為需要購買獨立的快取伺服器。
所以在現實中，有時候，我們有時並不會購買獨立的快取伺服器，而是放在大記憶體的應用或資料庫伺服器上，設定好閾值，共用記憶體。

04 第三次演進：應用叢集與資料庫的叢集和讀寫分離

哇，用了快取後，訪問資料好快啊。
可是使用者又增多了，應用支撐不過來了怎麼辦?真是幸福的煩惱啊。
單臺數據庫是不是有宕機的危險啊？

唉，叢集唄。花錢就完事了。

應用叢集、資料庫叢集。

這也是我們當今的軟體架構中最常用的部署方案。

通過負責均衡排程器（nginx、F5等），可以將使用者請求通過輪詢或者IP指定的方式，分發到應用伺服器叢集中的任意一臺伺服器上，緩解應用壓力。
而資料庫以Oracle為例，則是可以在生產伺服器上安裝RAC版本，而應用可以通過訪問資料庫的VIP（Virtual IP），或者JDBC叢集訪問的方式訪問資料庫。
但是在網站的應用開發中，則一般選擇mysql的較多。雖然淘寶早期也是使用了Oracle，但是後期也轉mysql了。
至於為什麼？
呵呵，一個字，貴。兩個字，很貴。三個字，太貴了。

叢集的好處有兩個：1、緩解服務壓力；2、高可用，其中一臺壞了，另一臺還可以繼續使用，給你恢復服務的機會。

一般軟體演化到這裡就完事了。

但是網站有個不一樣的地方，很多時候，都是讀多寫少。
點讚的、吃瓜的比上場評論的少很多對吧？

而讀多的情況雖然通過快取配置消化了一部分，但還是有一部分讀操作（快取未命中、快取過期）和全部的寫操作會訪問資料庫。
所以在你的使用者量又迅猛增加到一定規模時，又是資料庫成為了我們的瓶頸。

目前大部分資料庫都是支援主從熱備功能的，主資料庫通過主從複製機制將資料更新同步到從資料庫。
此時我們的應用就可以建設專門的讀、寫資料庫的訪問模組，使資料庫讀寫分離對應用透明。

有時我們甚至會將專門的查詢模組剝離出來，成為另一個子系統。

05 不算演進的第四次演進：CDN與反向代理

為什麼要做CDN？
移動、電信、聯通……，華東、華南、西南、西北……，網路環境複雜，每個地區訪問網站的速度都不太一樣。
CDN跟反向代理是加速訪問的一種手段，它們的基本原理都是快取。
區別是CDN部署在網路廠商的機房，反向代理是部署在網站機房。
CDN跟反向的目的都是儘早返回資料給使用者。

06 三國演義式的第五次演進：分散式演進、業務的拆分與合併

分散式資料庫是一種最後手段，只有在單表資料非常龐大的時候才使用。
很多網站和軟體根本用不到這一步，分散式資料庫會帶來更麻煩的複雜性。
網站更常用的手段是拆分業務，拆分不同的業務應用，拆分不同的業務庫，部署在不同的物理伺服器上。

這一招，在圍棋上，叫分治。在三國裡，叫合久必分。

以商城網站為例，可以將首頁、店鋪、訂單、賣家、買家拆分不同的產品線，這其中不同的產品線又可以拆分多個應用，分歸不同的業務團隊管理。

應用之間可以通過首頁超連結建立關係，也可以通過訊息佇列進行資料分發，當然，最多的還是訪問同一個資料儲存系統，來構成一個完整的系統。

這叫微服務。

隨著業務拆分越來越小，應用越來越複雜，其中又出現了一些可以共用的服務。如使用者管理、商品管理，那麼就可以將這些共用的業務提取出來，獨立部署。
用現在流行的話來說，叫業務中臺。

在技術上，大家又造了各種各樣的輪子，解決的問題其實有很多共性。例如檔案、圖片的處理、資料的儲存與搜尋系統。
技術中臺也有了。

在資料上，大家的系統因為拆分的愈來愈零碎，儲存到了不同的資料庫中，又形成了一個個資料孤島。把這些打通，做成資料倉庫，分析使用者畫像豈不美哉？優惠券推送、大資料殺熟了解一下。
而在技術上，隨著資料越來越多，資料儲存和檢索的技術需求也越來越高。所以我們又會引用一些非關係型的技術如NoSQL、搜尋引擎等等。
最後，資料中臺也有了。

所謂分久必合，新三國成型了。

---

歡迎關注我的公眾號：姚毛毛的部落格

這裡有我的程式設計生涯感悟與總結，有Java、Linux、Oracle、mysql的相關技術，有工作中進行的架構設計實踐和讀書理論，有JVM、Linux、資料庫的效能調優，有……

有技術，有情懷，有溫度

歡迎關注我：姚毛毛& 妖生

相關推薦