大型網站架構讀後心得 : 大型網站架構的演化

Charlie Lee

Follow

Published in

Bucketing

11 min readDec 29, 2020

--

大型網站閱讀心得，網站架構的演化

Photo by Ricardo Gomez Angel on Unsplash

前言

此篇文章式閱讀大型网站技术架构：核心原理与案例分析(2013)第一章節-網站演化的心得，雖然已經七年但整體概念到現下都還是持續看得到，這本書沒有講太多關於細節與實踐，比較適合初學者作為架構的入門書，可以幫助打開視野。

章節內容

描述網站架構的特點
描述網站架構的演化
描述網站架構的誤區

網站架構的特點

高併發高流量
高可用
海量數據
用戶分佈廣泛/網路情況複雜
安全環境惡劣
需求變更快速/發布頻率
漸進式發展

以Medium來舉例，Medium每天需要負擔成千上萬的讀者與作者24/7不中斷(小時/天)的連接服務，而且這樣的內容創作平台資料量一定非常龐大，使用者幾乎涵蓋全球，全球的有心人士一定都想趁虛而入攻擊Server，而且Medium的競爭者眾多，一定需要不斷的迭代功能保持自己的競爭性，最重要的上述的解決方法一定都是不斷的從回饋中修正與演進。

網站架構的演化

1.初始階段

簡單明瞭的架構，使用者不多，一台家用PC就可以開始創業。

2.網站真的開始有使用者了，為了未來著想，開始應用與數據分離

因為新聞開始報導公司網站，使用者開始上升，一台簡單的PC撐不住了，預防未來還需要持續擴增，將應用和儲存分離吧!

3.資料量越來越大，每次搜尋都要花好久時間，加上快取吧

使用快取緩存減輕DB壓力，快取可以分為單機與獨立的快取Server，當然可以兩個同時使用，而使用獨立的快取Server可以方便擴增(水平擴增)，其實機器裡面最容易需要擴增的就是Cache Server了，記憶體真的是容易無限擴張，尤其程式水平不夠時…，目前常用的Cache App大概就是Redis了。

關鍵字: Memcache/Redis

4. 連線數量撐不住了讓應用也變成集群

每個使用者向網站要資料時都會啟用TCP連線，當使用者過多一台Server是很難維持住這些連線的，可能會導致整個Server卡死不動，如此也只能讓Application Server變成集群，並且搭配Load Balance Server進行流量條配，分配每個Request該通往哪個Server。Application變成集群後就可以做到理論上的無限擴增，以及當其中一台Server掛掉時，還可以持續提供服務。目前最常使用的Load Balance大致上就是Nginx了，偶爾會用Apache來擋一下。

關鍵字: Load Balance/Ngnix

5.DB Server在大量的讀寫下效率極度緩慢，讓我們加上讀寫分離

DB Server因為RDBMS保持ACID的關係，為了保障一致性會使用Lock，以及若要對大Table新增資料時，需要花時間修正Index的B+ Tree，所以在讀資料庫時可能因為前一個Write操作導致整個DB block住。這時就可使用讀寫分離的方式拆解DB的行為，準備兩個資料庫一個負責寫，一個負責讀，在通過Sync的方法(通常使用的資料庫都會有內建功能支持)同步資料庫內容，當然這會導致短時間的資料不一致(根據自己設定Sync的間隔)，可以再根據自己的服務決定那些只能從寫庫讀資料，而可忍受不一致的服務則可以完全從讀庫取資料，(這樣的方法到後面又會導致一些新的問題出現，讓我們繼續往下看)。

關鍵字: 讀寫分離/B+ Tree/RDBMS Index

6.使用者不再單單只是同一區域，為了提昇網站被瀏覽時的使用體驗，使用CDN與反代理加速回應時間

當網站使用者越來越多，甚至開始有國外的使用者，此時就必須加上CDN(Content Delivery Network) 與反向代理服務了，CDN主要架設在網路營運商(中華電信)的機房裡，當使用者封包過營運商機房時，可以第一時間將我們存放在CDN上的靜態資料 (Video/CSS/Javascript/IMAGE) 快速回傳給使用者，而反向代理可以紓解Load Balance Server的壓力，讓流量再次分離，比如一張網頁讀取時會對Server發出五種Request(拿使用者資料/購物車資料/商品資料) ，就可以透過五個反向代理分別接收這五種Request，這些反向代理在將訊息送到Load Balance Server上，而反向代理也跟CDN一樣可以先將靜態資料緩存在機器上，可以先放不需要Server處理但是比較追求一致性的資料(Javascript)給使用者加速體驗。

關鍵字: CDN / Reverse Proxy / DNS

7.讀寫分離也只是暫時之計，最終的瓶頸還是會到來，將DB做集群吧，順便也把文件Server做集群

如同前面所說，當一致性要求高的服務變多(需要讀寫庫)，那DB的瓶頸還是會到來，所以這時候可以透過分庫分表或是針對業務性質不同對DB做集群與猜分，分庫分表:就是將一張大Table切分為不同部分(分表)(可以透過Hash的方法，或是自定義區間)，再將這些表分到不同的資料庫(分庫)，當然這樣要讀資料庫就會比較麻法需要特別設計，不能在像以前一樣簡單的用SQL Client搜尋，這時就需要特別寫儲存模組(Storage Module)針對資料庫去做CRUD，要搜尋哪一台資料庫的邏輯就可以封裝在此Module了，業務Application就可以不受影響繼續開發，而分散式文件系統，因為工作基本沒碰到，甚至連文章都沒看過，就無法多作說明，這也可以做為自我開地圖的一個學習吧。

關鍵字: 分散式文件系統

8.資料越來越多樣化，其實並不是每種資料都是合SQL / 讓NoSQL/搜尋引擎進入系統

雖然有了資料庫群集，但是一段時間後他還是會到達上限，這時就需要採納治本的方法了，許多根本不需要Transaction、ACID和關聯的資料，就可以透過NoSQL儲存(K-V結構)，將資料從RDBMS脫離，而搜尋引擎，最著名的大概是ELK中的Elastic Search了，對四散在系統機器上的Log搜尋。

關鍵字: NoSQL / 搜尋引擎 / NoSQL vs SQL

9.流量無限上漲，需求迭代快速，切分Application

使用者又更多了，而且為了讓網站更加火熱，更多的功能要更快的上線測試反應，這時候就需要將Application，根據不同的業務切分，而大量的Request則透過Message Queue消化，Message Queue主要可以幫助系統做流量削峰和系統解偶，流量削峰:每當特殊時間到，都會有大量的需求近來(Uber Eat用餐時間/阿里巴巴雙11)，但是時間一過，流量又會回復平穩，為了這時間加伺服器好像不一定划算，這時候就可以考慮MQ Server，讓Request可以排隊等待被處理，不會一口氣衝爆系統導致連鎖Crash，有了MQ就可以做到系統解偶和，MQ可以做到Pub/Sub功能，讓服務之間透過MQ溝通不需要直接的連接，而基本原理就是Producer-Consumer典型的異步Pattern。

關鍵字: Message Queue / Producer-Consumer / RabbitMQ / Kafaka