大型網站的演化之路——讀《大型網站技術架構》
____
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、數據庫的性能調優，有……
有技術，有情懷，有溫度
歡迎關注我：姚毛毛& 妖生
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※專營大陸空運台灣貨物推薦
※台灣空運大陸一條龍服務
※評比南投搬家公司費用收費行情懶人包大公開
※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!
