文章目錄
本文主要參考自《大型網站技術架構：核心原理與案例分析》一書第一章節和其他網絡文章，如有遺漏或錯誤，還望海涵並指出。謝謝！
這個世界沒有哪個網站從誕生起就是大型網站；也沒有哪個網站第一次發佈就擁有龐大的用戶，高併發的訪問，海量的數據；大型網站都是從小型網站發展而來。網站的價值在於它能爲用戶提供什麼價值，在於網站能做什麼，而不在於它是怎麼做的，所以當網站還很小的時候就去追求網站的架構是逐本舍末，得不償失的。小型網站最需要做的就是去爲用戶提供好的服務來創造價值，得到用戶的認可，活下去，野蠻生長 。
–《大型網站技術架構：核心原理與案例分析》
一.大型網站系統的特點
互聯網發展二十年來，越來越多的網站正在崛起，許多網站從一開始的小流量、小併發的模式發展到現在的巨大流量與高併發模式，期間有着許多的技術架構演進過程，典型的例子有淘寶網、FaceBook、微博等網站和系統，所以研究和學習大型網站技術架構的演進過程是十分有必要的。
以淘寶網爲例，這種大型的網站系統具有一下特點：
1.大流量
淘寶網2018年的年度活躍人數爲5.8億人，每天都有千萬至億級用戶在使用，所有流量巨大。
2.高併發
以雙十一爲例，僅在雙十一開啓的一秒鐘之內就產生了百億的錢款流水，用戶併發請求巨大。
3.高可用
淘寶網每時每刻都會產生大量的訂單，如果不能夠保障24小時的持續服務，那麼會對用戶和淘寶店家等產生重大的影響，此時需要服務器具備高可用性，提供99.9999%（一年中的99.99999%的時間）的可用時間。
4.海量數據
每天的訂單數據或者是用戶數據、店家數據等十分地巨大，以P爲基本單位，需要上萬臺服務器來對數據進行存儲。
5.用戶分佈廣泛
淘寶網具有大量的國內用戶和海外用戶，所以用戶的分佈是十分廣泛的。
6.網絡情況複雜
網絡的情況受地域的影響，例如國內用戶無法訪問國外的某些服務器資源，各個運營商還具有網絡互通的難題。
7.敏捷開發和快速迭代
由於用戶的需求或行業的走向、熱點等都會隨時發生變化，所以大型網站有敏捷開發和快速迭代的需要。
8.安全環境惡劣
因爲樹大招風，越是大的網站和系統，黑客的攻擊也越多，所處的安全環境也越惡劣，所以如何處理安全問題也是一個很重要的點。
二.大型網站架構演進過程
可以簡單地將大型網站架構演進的過程分爲以下幾個"時代"，每個時代都解決了當前急需解決的問題。
1.單機時代
在網站創立的初期，由於用戶量級小、請求少、低併發，所以一般是採取了將應用程序、文件服務（如圖片存儲）和數據庫都放在一臺服務器中，例如現在許多小型的網站都採用了LAMP的技術架構（Liunx + Apache + MySQL + PHP）部署單機系統。這個時候使用這種單機架構是可以支撐得住的，一般的個人網站或企業系統普遍使用了這種技術架構，這是最簡單的一種技術架構。
2.多機時代
隨着網站的發展，一臺服務器中的數據越來越多，導致磁盤IO變得緩慢，所以此時出現了將應用程序和文件存儲系統、數據庫分成多臺服務器來部署的架構，這樣就可以讓不同的服務器各司其職，例如在CPU更好、處理速度更快的服務器上部署應用程序，而在磁盤IO快的服務器上部署數據庫，在磁盤空間大的服務器部署文件系統。
3.緩存時代
當網站發展得越來越好，請求越來越多時，大量的請求使得數據庫處理不過來甚至是阻塞、宕機，延遲越來越大，此時的做法是引入緩存。
首先要明確的是，系統的請求也符合二八定律，即八成的請求會集中在二成的數據集上，例如淘寶網大部分的請求都是瀏覽商品的請求，而小部分的請求爲買家修改資料，所以此時要區分出熱數據和冷數據，將對於熱數據的大部分請求下發到緩存中，而不是直接請求到數據庫上，從而提升了請求響應速度和降低數據庫的訪問壓力。
緩存可以分爲遠程緩存和本地緩存，例如Redis就可以部署在專用的緩存服務器中當作遠程緩存，而ehcache技術可以用來作爲本地緩存，使一部分緩存位於應用服務器上。
4.集羣時代
當緩存問題解決後，數據庫不再承受大的壓力，但是對於應用服務器來說還是需要繼續承受着很大的壓力的，此時出現了應用程序大量併發請求下的瓶頸，也許是因爲服務器自身帶寬不夠或服務器自身能處理的連接請求有限，此時有兩種選擇：
垂直拓展：繼續選擇帶寬更大、處理器更好的服務器來部署應用程序，但是無論配置多好的服務器，終會有配置不夠用的時候，所以可以選擇水平拓展。
水平拓展：既然一臺服務器能夠處理的請求是有限的，那麼爲什麼不可以通過拓展更多的機器來處理更多的請求呢？此時出現了集羣這種解決方案，通過增加服務器，採取負載均衡的方式分發請求到多臺服務器中去處理，那麼就可以處理更多的請求了
5.讀寫分離時代
爲了進一步地降低數據庫或緩存數據庫的讀寫壓力，可以將讀請求和寫請求分發給不同的機器來處理，這樣就產生了讀寫分離的架構，這在MySQL和Redis中經常被使用到，這樣做有兩個好處：
- 將讀和寫分離，請求的負載均衡
- 數據的備份與容災，防止數據的丟失
6.反向代理與內容分發網絡
由於網站發展越來越好，用戶分佈於世界各地，此時如果我們的資源如圖片、文件、CSS等都部署在一臺固定位置的服務器上，那麼距離這臺服務器越遠的用戶，其訪問資源的速度會越慢。
而網站的訪問速度和響應速度與用戶的流失率成反比的關係，這時需要提高不同地域的用戶的訪問速度
內容分發網絡（CDN）實質上是部署與雲服務商服務器中的資源，當用戶請求CDN上的資源時，會優先將請求轉發到距離用戶最近的服務器，這樣就可以提高用戶的訪問速度。
而反向代理服務器的作用是將用戶的請求進行轉發，如果發現已經存在緩存，那麼會將緩存直接返回。
CDN與反向代理在這裏的作用都是爲了能更快地響應用戶所需的資源
7.底層服務集羣化
現在這個網站的架構已經比較完善了，但是我們發現數據庫和緩存服務都只存在兩臺機器：一個提供寫服務器、一個提供讀服務，但是這時會出現一個問題，就是數據庫的一張表中出現了大量的數據或者是緩存服務器的內存被佔據滿了，此時無論如何進行讀寫分離，由於從庫總是同步與主庫，所以從庫也會被佔滿，從而無法對外提供底層服務，或者是響應緩慢，此時的做法和一開始應用服務器的水平擴展一樣，也就是增加更多的底層服務。
水平拓展：通過增加更多的底層服務機器，來將數據庫或緩存的數據與壓力分發下去，讓數據平攤到不同的底層服務機器上就可以解決單體壓力過大的問題。
8.搜索引擎技術與NoSQL
此時網站架構已經十分地完善了，但是在某些服務例如商品的關鍵字搜索、商品數據的存儲等會出現一些問題。
商品的關鍵字搜索服務，如果使用普通的數據庫配合模糊查詢來實現的話，由於模糊查詢不會走索引，當數據量大的時候，這個查詢過程是十分緩慢並且耗費計算資源的，所以出現了搜索引擎技術，如Solr、ES等來解決這個問題，一方面優化了關鍵字檢索的效率，另一方面可以將一部分數據分擔到Solr或ES的數據庫中。
商品的數據存儲，如果使用數據庫來做的話每條數據都會佔據大量的字段和空間，這時可以使用MongoDB等NoSQL數據庫來存儲這些數據，可以大大提高查詢的速度和降低所佔用的空間。
9.服務拆分與微服務化
當網站的業務越來越多，開發者也越來越多，此時出現了一些問題：
- 業務越來越複雜，各個不同的業務之間耦合在一起，修改困難
- 應用代碼越來越龐大，打包時間很長
- 單個業務出現了問題導致整個服務都崩潰，影響了其他業務的正常運轉
所以，有架構師提出了以下的建議：
1. 業務複雜，能否按業務線將來拆分團隊，如將業務線拆分爲支付業務、首頁業務、用戶服務業務等，然後讓不同的團隊去負責開發，當需要服務依賴時通過遠程調用的方式進行調用
2. 將大的應用拆分爲小的應用，分開部署，這樣就不會產生某個應用掛掉了導致其他應用也不能提供服務的問題
所以出現了近幾年來非常火爆的網站架構方式：微服務化
微服務化，即將大應用按業務模塊拆分爲小應用，然後使用RPC使得小應用之間相互配合，從而組成大應用。
