你好，我是Cone。

最近在讀大型互聯網架構這本書，今天想你一起嘮嗑嘮嗑架構，你可能耳熟能詳的高并發、大流量、海量數據、分布式等等這些詞匯，但是每個詞匯背后其實都是為了解決當前所出現的問題所總結出的一套架構范式，今天一起來扒一扒架構。

讀完本文，能夠讓你理解單一應用到大型應用的架構演進歷程。

文本大綱

單一應用服務階段

所有的大型網站都是由最小型的網站架構演變而來的。回想一下你最開始寫服務端代碼，是不是數據庫MySQL在本地，服務器也是本地，那最初階段也是這樣的，網站的流量也不大，通常就將應用服務、數據服務、文件資源等所有資源都放在一臺服務器上，比如我們學java web的時候，都是利用Tom??等Web容器開始運行應用服務程序，比如JSP，然后需要數據庫的時候用JDBC去連接本地Mysql Server。一圖勝千言：

應用與數據服務分離階段

經過業務發展迭代增加，用戶量、日活的上升，簡單的一臺服務器就搞不定了。比如可能由于用戶產生的數據量過多導致存儲空間不夠，而一臺服務器同時得處理數據服務和用戶的應用web響應，CPU資源有限的情況下，是無法滿足用戶想要快速響應需求的，網站的訪問數據變得越來越慢，而數據服務和應用服務所對計算機資源的需求是不一樣的，比如應用服務器需要更多的CPU資源，給這臺服務器配上多幾核的CPU，數據服務可能需要與磁盤打交道，配備更多的閃存。

這時候就將應用服務和數據服務進行分離。將應用服務器單獨出來，專注于響應web請求，提高用戶的訪問速度，將數據庫單獨放在一臺服務器，專注于處理與應用服務器打過來的數據請求，將文件資源放在一臺服務器上，與應用服務器打交道，為其提供文件服務，一圖勝千言：

利用緩存提高性能階段

隨著用戶的再增加，業務的再次升級。網站有面臨了一個數據庫服務的壓力太大而導致整體的訪問效率下降，再次影響用戶的訪問體驗。

你可以想象，我們日常的微博、抖音那些熱點數據，是幾個每個打開這些應用的人會請求到的。所以二八定律永遠存在，80%的請求在20%的數據上。所以這個時候將這20%的數據進行高校的緩存起來，這樣網站整體的性能又可以提升了。

緩存可以分為兩種：一種的直接緩存在應用服務器上，另外是一種開一臺緩存服務器進行緩存。后者可以進行很好的彈性伸縮，而前者會受到本地容量的限制。我們稱后者服務器為：分布式緩存服務器。

目前筆者寫的后端程序也在這個階段，也在嘗試往后續集群方向演進。一圖勝千言：

應用服務集群階段

當使用緩存后，數據庫的訪問壓力得到有效緩解。再次隨著業務的增加，單一應用服務器能夠并發處理的請求連接有限，在流量的高峰期，應用服務器開始成為整個系統的性能瓶頸。

因此這個時候就開始組件應用服務器集群，不僅應用服務器有集群，緩存服務器等也可以組成集群。那么既然有了服務器集群，那對于這些請求，到底應該有哪臺服務器響應呢。所以負載均衡調度服務器就出現了。

通過負載均衡調度服務器，可將來自瀏覽器的訪問請求分發到應用的集群中的任何一臺服務器上。使用服務器集群也有個好處，Web 應用程序更新可以做到用戶無感知，當有一個節點的服務器宕機之后，也不影響整體的請求。

一圖勝千言：

數據庫讀寫分離階段

雖然增加了數據緩存這一層。比如利用redis緩存，但是隨著用戶量的不斷增加。總有一些是無法通過緩存提高的，比如還可能出現緩存過期、緩存沒有命中等情況。那么這些請求全部會打到數據庫服務器上，這個時候數據庫服務成為了整個系統的瓶頸。所以數據讀寫分離就出現了。

目前大部分的數據庫都提供了一個主從熱備的功能。通過配置主從兩臺服務器，當應用服務器往主服務器寫入詩句時，利用主從復制機制將數據更新同步到從數據庫上。讀寫分離之后，數據庫的性能瓶頸就解決了。一圖勝千言：

反向代理與CDN加速階段

當網站業務再次升級，用戶規模再次擴大，為了滿足不同地區的用戶訪問速度，提高響應速度，CDN和反向代理就出現了，兩者基本原因都是緩存。

CDN就是內容分發網絡，你的請求響應服務器會從距離你最近的一個服務器集群上響應回來，比如你在云南，可能就從云南的機房響應。

而反向代理則部署在中心機房，當請求來到中心機房后，首先訪問的時候反向代理服務器，看看是否名字緩存，如果命中則直接返回。一圖勝千言：

分布式數據庫階段

分布式數據庫是系統數據庫拆分的最后手段，這只有在單表數據規模非常大的時候才會用，一般的數據庫拆分都是對業務拆分后將不同的業務數據部署在不同的服務器上。如下圖：

NoSQL與搜索引擎階段

當成為大型系統的時候，搜索成為了日常需求，這時會采用NoSQL和搜索引擎來提高搜索效率，緩存的時候redis也是NoSQL類型的。如下圖：

業務拆分階段

當業務日漸的增多，可能團隊人員也不利于管理，這個時候大型的系統都會進行業務拆分，比如抖音就拆了很多很多業務線。每條業務線服務不同的服務，每個服務都單獨進行部署，可以通過消息隊列進行數據分發。如下圖：

分布式服務階段

隨著業務拆分越來越小，存儲系統越來越龐大，應用系統的整體復雜度呈指數級增加，部署維護越來越困難。

既然每一個應用系統都需要執行許多相同的業務操作，比如用戶管理、商品管理等，那么可以將這些共用的業務提取出來，獨立部署。由這些可復用的業務連接數據庫，提供共用業務服務，而應用系統只需要管理用戶界面，通過分布式服務調用共用業務服務完成具體業務操作。如下圖：

總結

目前很少有人能經歷上面的系統演進，大部分大型的系統已經成型，而小系統可能又很可能撐不到成為大系統，所以很少有人能經歷這些，不過了解這些，我們對于整個系統架構的理解非常有幫助。

Hello，我是ConeZhang，本科畢業于某不知名雙非末流一本，科班CS專業。本科做了四年iOS開發，寫過無數iOS應用，拿過無數軟件競賽獎，也折騰過安卓開發，整過Spring全家桶，寫過網站，搭過服務器。秋招拿到了微信、抖音等大廠offer，是一段從春招屢戰屢敗到秋招屢戰屢勝的經歷。

如今在字節跳動抖音基礎技術做全棧研發，啥都會點，啥也不會。歡迎大家點個關注長期持有我這只潛力股。