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

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

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了。
至於爲何？
呵呵，一個字，貴。兩個字，很貴。三個字，太貴了。

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

通常軟件演化到這裏就完事了。

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

而讀多的狀況雖然經過緩存配置消化了一部分，但仍是有一部分讀操做（緩存未命中、緩存過時）和所有的寫操做會訪問數據庫。
因此在你的用戶量又迅猛增長到必定規模時，又是數據庫成爲了咱們的瓶頸。

目前大部分數據庫都是支持主從熱備功能的，主數據庫經過主從複製機制將數據更新同步到從數據庫。
此時咱們的應用就能夠建設專門的讀、寫數據庫的訪問模塊，使數據庫讀寫分離對應用透明。

有時咱們甚至會將專門的查詢模塊剝離出來，成爲另外一個子系統。

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

爲何要作CDN？
移動、電信、聯通……，華東、華南、西南、西北……，網絡環境複雜，每一個地區訪問網站的速度都不太同樣。
CDN跟反向代理是加速訪問的一種手段，它們的基本原理都是緩存。
區別是CDN部署在網絡廠商的機房，反向代理是部署在網站機房。
CDN跟反向的目的都是儘早返回數據給用戶。

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

分佈式數據庫是一種最後手段，只有在單表數據很是龐大的時候才使用。
不少網站和軟件根本用不到這一步，分佈式數據庫會帶來更麻煩的複雜性。
網站更經常使用的手段是拆分業務，拆分不一樣的業務應用，拆分不一樣的業務庫，部署在不一樣的物理服務器上。

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

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

應用之間能夠經過首頁超連接創建關係，也能夠經過消息隊列進行數據分發，固然，最多的仍是訪問同一個數據存儲系統，來構成一個完整的系統。

這叫微服務。

隨着業務拆分愈來愈小，應用愈來愈複雜，其中又出現了一些能夠共用的服務。如用戶管理、商品管理，那麼就能夠將這些共用的業務提取出來，獨立部署。
用如今流行的話來講，叫業務中臺。

在技術上，你們又造了各類各樣的輪子，解決的問題其實有不少共性。例如文件、圖片的處理、數據的存儲與搜索系統。
技術中臺也有了。

在數據上，你們的系統由於拆分的越來越零碎，存儲到了不一樣的數據庫中，又造成了一個個數據孤島。把這些打通，作成數據倉庫，分析用戶畫像豈不美哉？優惠券推送、大數據殺熟了解一下。
而在技術上，隨着數據愈來愈多，數據存儲和檢索的技術需求也愈來愈高。因此咱們又會引用一些非關係型的技術如NoSQL、搜索引擎等等。
最後，數據中臺也有了。

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

---

歡迎關注個人公衆號：姚毛毛的博客

這裏有個人編程生涯感悟與總結，有Java、Linux、Oracle、mysql的相關技術，有工做中進行的架構設計實踐和讀書理論，有JVM、Linux、數據庫的性能調優，有……

有技術，有情懷，有溫度

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