大型網站架構的發展
前面介紹了大型網站的業務需求和大致的工作原理，但是不能簡單地理解為只要增加伺服器就能把一個網站變成一個能應對大量用戶的網站。
通過增加伺服器來達到支持更多的用戶是大型網站架構的目的。
本節簡要介紹大型網站架構的發展，並介紹大型網站架構如何有效地增加伺服器。
本節介紹的技術點只要了解即可，後續章節會有更詳細的說明。
大型網站系統的內部是複雜的，一般是多種網站架構的混合（包括靜態網站、動態網站和B/S架構網站等）。
本節介紹的內容會忽略一些細節，另外，除了下面所講的動態網頁以外，其他都是以B/S架構網站作為基礎的。
說明：軟體架構是有關軟體整體結構與組件的抽象描述，是一個軟體的基本思想。簡單地說，架構就是以宏觀的角度思考軟體如何解決問題。
動態網頁時代
在前面動態網站的出現中提到了動態網站的工作原理，伺服器在接到瀏覽器的請求後，應用程式處理網頁資源文件後才返回文件。在這裡進一步說明一下，經過處理後，返回的只是HTML格式的文件，如JSP和PHP文件等。
對於不需要處理的資源文件，如JavaScript腳本文件、CSS樣式文件、圖片文件、視頻文件等，伺服器在接到請求後，會直接返回。當然，動態網站除了可以操作資料庫，同樣也可以調度雲計算服務。動態網站的技術架構如圖1.5所示。
B/S架構網站的崛起
不可避免的是，動態網頁需要在每一次請求網頁時都處理一遍所有的HTML格式的文件（如JSP和PHP文件）。這樣無疑會有不少的資源浪費。如果需要更新網頁中的內容，就必須重新加載整個網頁，使用戶體驗不是那麼友好，特別是在網速不好的情況下。
因此，網站更好的方式應該是類似於C/S架構模式（客戶端-伺服器模式，如桌面軟體等），伺服器只需要處理客戶端關心的數據即可，無須做多餘的處理。出於這樣的考慮，B/S架構模式（瀏覽器-伺服器模式）出現了，伺服器在接受網頁請求的時候，還是像靜態網站一樣不經處理地直接返回HTML文件。瀏覽器需要更新部分網頁數據的時候，只需要通過JavaScript腳本向伺服器請求其關心的數據，然後對網頁的某部分進行更新即可。B/S架構的網站也常常稱為偽靜態網站。大型網站架構雖然內部複雜，可能會包含動態網站和靜態網站，但一般還是以B/S架構網站為主。
隨著B/S架構的應用，瀏覽器運行的網頁和伺服器處理請求的接口也分別被稱為前端和後端。隨著Ajax技術的出現，進一步簡化了前端與後端的請求方式，B/S架構也逐漸崛起。B/S網站技術架構如圖1.6所示。
CDN加速網站響應
雖然說網頁不需要傳統意義上的軟體安裝就可以使用，但其實每次打開網頁時，都需要從伺服器端下載網頁文件（瀏覽器會有部分文件緩存，但大多數情況下都是重新下載）。而這些網頁文件（如HTML超文本文件、JavaScript腳本文件、CSS樣式文件、圖片文件和視頻文件等）大多數都是不需要伺服器處理的。如果每次都從伺服器返回網頁文件，顯然在大量用戶訪問的情況下，伺服器的壓力是很大的。加上複雜的網絡環境，不同地區的用戶訪問網站時速度差別極大。
因此，針對這些伺服器不需要做處理的文件，在面對大量用戶的訪問時，「怎麼能讓用戶迅速打開網站」是一個很重要的問題。
為了解決這個問題，我們可以增加足夠多的伺服器，並且把伺服器根據用戶的地區分布合理分配。這確實是解決問題的思路，但如果完全由網站服務商提供這些伺服器的話，成本是很高的。不過，已經有很多第三方供應商（如阿里雲、騰訊雲等）提供這些伺服器，我們只需要在第三方平台上配置網站域名和緩存策略，就可以解決問題。配置完成後，第三方伺服器會自動緩存網頁文件，用戶便可以從就近的伺服器上獲取網頁文件，而不是每個請求都被積壓到網站伺服器上。這樣的服務被稱為CDN（Content Delivery Network，內容分發網絡）加速，這種網站的技術架構如圖1.7所示。
應用和數據分離
網站伺服器中有應用程式、資源文件、資料庫和雲計算服務，它們對計算機的物理性能要求都不一樣，如資源文件需要更好的硬碟性能，資料庫除了硬碟性能外還要求更好的CPU性能。如果把應用程式、資源文件、資料庫和雲計算服務都放在一台伺服器上的話，是不能有針對性地對網站進行擴展的。
因此我們需要分離應用和數據，把應用程式、資源文件、資料庫和雲計算服務分別部署到專門的伺服器上。當用戶量越來越大時，就可以有針對性地增加存在性能瓶頸的伺服器。應用和數據分離的網站技術架構如圖1.8所示。
非關係型資料庫和關係型資料庫並存
在一定層面上，網站是圍繞數據工作的，網站的業務實際上是對數據的管理，資料庫一般是整個網站系統的核心。因此大型網站架構對資料庫的運用是非常重要的。資料庫一般指的是像MySQL和Oracle等類似於表格的關係型資料庫。當然，僅僅使用關係型資料庫也可以滿足所有的業務需求，但是存在兩個問題：第一，針對查詢而言，很多查詢請求都是相同的，一段時間內查詢的結果都是一樣的，而資料庫則基本上需要每次都重新檢索一次；第二，表格形式的關係型資料庫由於形式的限制，應對某些業務場景是乏力的，非關係型資料庫的出現，就是為了應對大規模數據集合及多種數據類型等挑戰。
針對問題一，雖然關係型資料庫也有自己的緩存機制以達到減少檢索的目的，但是它並不能根據具體業務定製緩存策略。引用Redis等鍵值存儲的非關係型資料庫可以對「預期訪問量很大並且更新概率較小」的數據進行緩存，這樣可以大大減少關係型資料庫的壓力。
針對問題二，應對海量數據時，採用HBase等列存儲非關係型資料庫比較省力；應對大量不限制結構的數據時，採用MongoDB等文檔型非關係型資料庫比較省力；應對社交關係等複雜的數據時，採用Neo4J等圖形非關係型資料庫比較省力，需要注意的是，這裡的圖形不是圖片，是圖形結構的意思。
根據實際情況選擇對應的非關係型資料庫，非關係型資料庫和關係型資料庫並存，無疑是大型網站架構設計中必要的一環。非關係型資料庫和關係型資料庫並存的網站技術架構如圖1.9所示。
集群化
集群化實際上就是我們前面一直提到的增加伺服器個數。但是，單純地增加伺服器最多是從一個網站變成多個網站，而不是讓一個網站變成一個能接納更多用戶訪問的網站。為了更好地增加伺服器，需要增加一些軟體為這些相同功能的伺服器進行協調。
下面根據應用和數據分離中提到的大型網站的四部分（應用程式、資源文件、資料庫和雲計算服務）分別介紹集群化的相關技術。
·應用程式的集群化：應用程式在B/S架構中，一般就是指後端接口。應用程式的集群化需要添加一個負載均衡的服務，讓前端網頁請求後端接口時，均衡地調度這些應用程式伺服器。
·資源文件伺服器的集群化：資源文件伺服器的集群化，主要是為了應對前端的下載請求。雖然CDN加速解決了大部分資源文件伺服器的壓力，但是CDN緩存一段時間後也會重新向資源文件伺服器回源。當用戶地區分布足夠廣的時候，這個壓力也是不容忽視的。資源文件伺服器的集群化同樣需要添加一個負載均衡的服務。
·資料庫伺服器的集群化：一般資料庫都會提供集群化的部署方案，根據該方案部署即可。
·雲計算服務的集群化：如果使用的是第三方雲計算服務，則集群化是第三方平台提供的；如果是自身的雲計算伺服器的話，則需要使用RabbitMQ等消息隊列作為任務調度中心。
集群化的網站技術架構如圖1.10所示。
分布式趨勢
集群化後，大型網站系統能很好地通過增加伺服器有效應對大量用戶訪問的壓力。但是，大型網站系統除了要應對大量的用戶訪問以外，還需要不斷地擴展業務。而不斷擴展業務功能後，應用程式部分會變得非常複雜和混亂。為了緩和這種應用程式部分複雜和混亂的情況，大型網站架構出現了分布式的趨勢。
分布式的大型網站架構，簡單地說就是把龐大的大型網站系統分割成多個獨立的子系統和子模塊，這些系統和模塊通過互相協助的方式完成任務。在物理意義上，分布式的大型網站系統把這些子系統分別部署在不同的伺服器上，並且能讓這些應用程式協同完成任務。
例如，上傳視頻可以贏取積分，分布式網站系統會由視頻管理子系統接收視頻上傳，然後由積分管理子系統增加該用戶的積分。而視頻管理子系統和積分管理子系統部署在不同的伺服器集群中。
分布式的網站系統會越來越流行，雖然其開發成本相對較高，但是獨立的子系統可以獨立發布，發現問題時也可以單獨測試，這為後續的運維提供了保障。另外，獨立的子系統如果通用性足夠的話是可以復用的，即該子系統可以為其他網站服務，縮減新網站系統的開發成本。分布式的網站技術架構如圖1.11所示。
微服務
微服務也是近年來比較熱門的話題。2014年，Martin Fowler與JamesLewis共同提出了微服務的概念，定義了微服務是由單一應用程式構成的小服務，擁有輕量化的處理程序。多個微服務共同提供網站系統所需要的功能。
微服務是分布式網站系統的進一步優化。簡單地說，微服務希望一個大型網站可以通過很多個完全獨立的小服務組成。這樣可以更清晰地運維網站系統，更快速地進行開發，更精準地定位問題。
不過，微服務也是存在爭議的，在筆者經歷過的兩個採用微服務的項目中，最後的結果都不太好。除了微服務框架的中間件增加了網站結構的複雜性以外，更關鍵的是，微服務的顆粒度需要項目自己定義，這個顆粒度的權衡很難拿捏。因此，大多數採用微服務的項目其結果都不太理想，應用程式部分變得十分臃腫，微服務間的調用也十分混亂。
筆者認為，微服務的概念會給大型網站架構帶來新的思考，但目前的狀態下，盲目地使用微服務框架，在大多數情況下只會弄巧成拙。微服務的網站技術架構如圖1.12所示。
大型網站架構的未來
目前大型網站架構的各種技術都是相對成熟的，第三方雲服務平台（如騰訊雲和阿里雲）也提供了各式各樣的基礎服務和雲計算服務。不過，如果要從零開始構造一個大型網站還是很困難的。
這種構造的難度恰恰證明大型網站的架構還沒有完全成熟。
微服務概念的提出，儘管其實際的應用效果不盡人意，但它也確實給原本以為已經成熟的大型網站架構帶來了新的思考。更加成熟的大型網站架構應該是由很多獨立的模塊合併起來的，就好像一個龐大的機械設備是由很多現成的零件組裝成的一樣。
大型網站架構還在發展，更加標準化的架構將會出現。到時候，大型網站架構將變成一個標準化的生態環境，開發大型網站時將不需要考慮這麼多的技術點，網站架構主要考慮組合哪些已有的子系統模塊。
小結
在了解大型網站的業務演變時，需要明白多種網站類型的應用場景；在了解大型網站架構的發展時，需要知道大型網站架構可能遇到的問題。通過了解這些發展歷史，相信讀者能對大型網站架構有大概的了解。
當然，僅僅從宏觀上了解是不夠的，畢竟我們忽略了很多複雜的細節。
不過，我們可以站在巨人的肩膀上，前人發現了很多問題，解決了很多問題，也產生了很多種技術，我們可以學習別人的經驗和前人的技術來解決遇到的問題。有些技術等需要用的時候再仔細學習也不晚。
隨著發展，大型網站架構變得越來越複雜，想要在技術選型和架構決策時直擊要害，確實需要一些經驗。我們在虛心學習前輩經驗的同時，也不要盲目跟風，而需要根據實際項目的情況做清醒的選擇和冷靜的判斷。
本文給大家講解的內容是大型網站架構的發展
- 下篇文章給大家講解的內容是大型網站架構面臨的挑戰：大型網站架構的基本問題
- 覺得文章不錯的朋友可以轉發此文關注小編；
- 感謝大家的支持！