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

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

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、數據庫的性能調優,有……

有技術,有情懷,有溫度

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

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※專營大陸空運台灣貨物推薦

台灣空運大陸一條龍服務

※評比南投搬家公司費用收費行情懶人包大公開

南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!