今天去逛書店，本來只想買本SQL的書，拿起來看了看，覺得是本科普的好書，介紹很多我不懂的東西。遂買下，準備好好讀讀。
說實話已經有很久沒有讀完過一本書了，甚至都懷疑自己還能不能從頭到尾讀完一本書。覺得這本書很有趣，適合拿來建立自信。所以要把它讀完。
本章的標題是“大型網站架構演化”。
金句
- 希望軟件工程師們在解決問題之前，能夠認真思考自己面對的真正問題究竟是什麼，有哪些技術方案可以選擇，其基本原理是什麼。
- 真正能解決問題的技術一定是簡單的。
- 是業務成就了技術，是事業成就了人，而不是相反。
- 網站架構師應該對成就自己技術成績的網站事業心存感恩，並努力提高技術回饋業務。
大型網站軟件系統的特點
- 高併發，大流量
- 高可用
- 海量數據
- 用戶分佈廣泛，網絡情況複雜
- 安全環境惡劣
- 需求快速變更，發佈頻繁
- 漸進式發展
大型網站架構演化發展歷程
大型網站的技術挑戰主要來自於龐大的用戶，高併發的訪問和海量的數據，任何簡單的業務一旦需要處理數以P計的數據和麪對數以億計的用戶，問題就會變得很棘手。大型網站架構主要就是解決這類問題。
初始階段的網站架構
小型網站最開始時沒有太多人來訪問，只需要一臺服務器就綽綽有餘。這時的網站架構如下圖所示：
應用程序、數據庫、文件等所有的資源都放在一臺服務器上。通常服務器操作系統使用Linux，應用程序使用PHP開發，然後部署在Apache上，數據庫使用MySQL。
應用服務器和數據服務器分離
隨着網絡業務的發展，一臺服務器逐漸不能滿足需求：越來越多的用戶訪問導致性能越來越差，越來越多的數據導致存儲空間不足。這時就需要將應用和數據分離。分離後整個網站使用三臺服務器：應用服務器、文件服務器和數據庫服務器。如下圖所示。
三臺服務器對硬件資源的要求各不相同，應用服務器需要處理大量的業務邏輯，因此需要更快更強大的CPU，數據庫服務器需要快速磁盤檢索和數據緩存，因此需要更快的硬盤和更大的內存；文件服務器需要存儲大量用戶上傳的文件，因此需要具有更大的硬盤。
現在，網站的併發處理能力和數據存儲空間得到了很大的改善，支持網站業務進一步發展。但是隨着用戶逐漸增多，網站又一次面臨挑戰：數據庫壓力太大導致訪問延遲，進而影響整個網站的性能，用戶體驗受到影響。這是需要對網站架構進一步優化。
使用緩存改善網站性能
網站訪問特點遵循二八定律：80%的業務訪問集中在20%的數據上。淘寶買家瀏覽的商品集中在少部分成交數多、評價良好的商品上；百度搜索關鍵詞集中在少部分熱門詞彙上。
如果把這一小部分數據緩存在內存中，就可以減少數據庫的訪問壓力，提高整個網站的數據訪問速度，改善數據庫的寫入性能。
網站使用的緩存分爲兩種：
- 在應用服務器上的本地緩存。速度快，數據量有限
- 分佈式緩存服務器上的遠程緩存。大內存服務器，理論上不受內存容量限制。
使用緩存後，數據訪問壓力得到有效緩解，但是單一應用服務器能夠處理的請求連接有限，在網站訪問高峯期，應用服務器稱爲整個網站的瓶頸。
使用應用服務器集羣改善網站的併發處理能力
使用集羣是網站解決高併發、海量數據問題的常用手段。不要企圖換更強大的服務器，對大型網站而言，不管多麼強大的服務器，都不能滿足網站持續增長的業務需求。這種情況下，更恰當的做法是增加一臺服務器分擔原有服務器的訪問及存儲壓力。
對網站架構而言，只要能通過增加一臺服務器的方式改善負載壓力，就可以以同樣的方式持續增加服務器不斷改善系統性能，從而實現系統的可伸縮性。應用服務器實現集羣是網站可伸縮架構設計中較爲簡單成熟的一種。
通過負載均衡調度服務器，可將來自用戶的請求分發到不同的應用服務器上。
數據庫讀寫分離
網站在使用緩存後，絕大部分的讀操作都可以在緩存中進行，但還有一些讀操作（緩存訪問不命中，緩存過期）和全部的寫操作需要訪問數據庫，在網站的用戶達到一定規模後，數據庫因爲負載壓力過高而成爲網站的瓶頸。
目前大部分的主流數據庫都提供主從熱備功能，通過配置兩臺數據庫主從關係，可以將一臺數據庫服務器的數據更新同步到另一臺服務器上。網站利用數據庫的這一功能，實現數據庫讀寫分離，從而改善數據庫負載壓力。
應用服務器在寫數據的時候，訪問主數據庫，主數據庫通過主從複製機制將數據更新同步到從數據庫，這樣當應用服務器讀數據的時候，就可以通過從數據庫獲得數據。爲了便於應用程序訪問讀寫分離後的數據庫，通常在應用服務器端使用專門的數據訪問模塊，使數據庫讀寫分離對應用透明。
使用反向代理和CDN加速網站響應
隨着網站業務不斷髮展，用戶規模越來越大，由於中國複雜的網絡環境，不同地區的用戶訪問網站是，速度差別也極大。有研究表明，網站訪問延遲和用戶流失率正相關，網站訪問越慢，用戶越容易失去耐心而離開。爲了提供更好的用戶體驗，留住用戶，網站需要加速訪問速度。主要手段有使用CDN和反向代理。
CDN和反向代理的基本原理都是緩存，區別在於CDN部署在網絡提供商的機房，使用戶在請求網站服務時，可以從距離自己最近的網絡提供商機房獲取數據；而反向代理則部署在網站的中心機房，當用戶請求到達中心機房後，首先訪問的服務器是反向代理服務器，如果反向代理服務器中緩存着用戶請求的資源，就將其直接返回給用戶。
使用CDN和反向代理服務器的目的都是儘早返回數據給用戶，一方面加快用戶訪問速度，另一方面也減輕後端服務器的負載壓力。
使用分佈式文件系統和分佈式數據庫系統
任何強大的單一服務器都滿足不了大型網站持續增長的業務需求。這時需要使用分佈式文件系統和分佈式數據庫系統。
分佈式數據庫是網站數據庫拆分的最後手段，只有在單表數據規模非常龐大的時候才使用。不到不得已時，網站更常用的數據庫拆分手段是業務分庫，將不同業務的數據庫部署在不同的物理服務器上。
使用NoSQL和搜索引擎
隨着網站業務越來越複雜，對數據存儲和檢索的需求也越來越複雜，網站需要採用一些非關係數據庫技術如NoSQL和非數據庫查詢技術如搜索引擎。
NoSQL和搜索引擎都是源自互聯網的技術手段，對可伸縮的分佈式特性具有更好的支持。應用服務器則通過一個統一的數據訪問模塊訪問各種數據，減輕應用程序管理較多數據源的麻煩。
業務拆分
大型網站通常通過使用分而治之的手段將整個網站業務分成不同的產品線，分歸不同的業務團隊負責。
具體到技術上，也會根據產品線劃分，將一個網站拆分成許多不同的應用，每個應用獨立部署維護。應用之間可以通過一個超鏈接建立關係，也可以通過消息隊列進行數據分發，最多的還是通過訪問同一個數據存儲系統來構成一個關聯的完整系統。
分佈式服務
隨着業務拆分越來越小，存儲系統越來越大，應用系統的整體複雜度呈指數級增長，部署維護越來越困難。由於所有應用要和所有數據庫連接，會導致數據庫連接資源不足，拒絕服務。
既然每一個應用系統都需要執行許多相同的業務操作，比如用戶管理、商品管理等，那麼可以將這些共用的業務提取出來，獨立部署。由這些可複用的業務連接數據庫，提供業務服務。
大型網站的架構演化到這裏，基本上大多數的技術問題都得以解決，諸如跨數據中心的實時數據同步和具體業務網站相關的問題也都可以通過組合改進現有技術架構來解決。
我去專門找了跨數據中心的實時數據同步怎麼解決基本沒找到。稍後再找。
既然大型網站架構解決了海量數據的管理和高併發事務的處理，那麼就可以把這些解決方案應用到網站自身以外的業務上去。我們看到很多大型網站都開始建設雲計算平臺，將計算作爲一種基礎資源出售，中小網站不再需要關心技術架構問題，只需要按需付費，就可以使網站隨着業務的增長逐漸獲得更大的存儲空間和更多的計算資源。
大型網站架構演化的價值觀
網站的價值在於它能爲用戶提供什麼價值，在於網站能做什麼，而不在於它是怎樣做的，所以在網站還很小的時候就去追求網站的架構師捨本逐末，得不償失的。小型網站最需要做的就是爲用戶提供好的服務來創造價值，得到用戶的認可，活下去，野蠻生長。
- 大型網站架構技術的核心是隨網站所需靈活應對
- 驅動大型網站技術發展的主要力量是網站的業務發展
網站架構設計誤區
一味追隨大公司的解決方案
大公司的經驗和成功模式固然重要，值得學習借鑑，但如果因此而變得盲從，就失去了堅持自我的勇氣，在架構演化的道路上遲早會迷路。
爲了技術而技術
網站技術是爲業務而存在的，除此毫無意義。在技術選型和架構設計中，脫離網站業務發展的實際，一味追求時髦的新技術，可能會將網站的技術發展引入崎嶇小道，架構之路越走越難。
企圖用技術解決所有問題
12306真正的問題不在於它的技術架構，而在於它的業務架構。後來12306在售票方式上引入了排隊機制、整點售票調整爲分時段售票。其實如果能控制住併發訪問量，很多棘手的技術問題也就不是什麼問題了。
技術是用來解決業務問題的，而業務問題，也可以通過業務的手段去解決。
小結
網站架構技術演化過程難以重現，所以網站架構師更應該對這個過程深刻理解，理解已成熟的網站架構技術方案的來龍去脈和歷史淵源，在技術選型和架構決策時纔能有的放矢，直擊要害。
最後說一點自己的話吧，今天被阿里的面試官問得啞口無言，讓我真的感覺到了基礎的重要性。面試官給我的建議是再系統的學習一下語言、操作系統、設計模式、網絡通信方面的基礎。仔細想想，確實到現在也沒有哪門語言可以說是精通。我覺得是時候好好把基礎梳理一下了。
內功啊內功。
