大型分佈式網站的思考(一):大型網站發展歷程

前幾天跟一個朋友聊了一些關於網站緩存分佈式的一些東西，發現本身的知識仍是太過貧瘠。理論+協議，這是如今我亟待增強的。這個週末買了兩本關於分佈式網站的書，本着好記性不如爛筆頭，便有了這樣一系列的文章。但願一同分享，也請多指教。

code less, play more!

前言

這個世界上沒有哪一個網站從誕生起就是大型網站；也沒有哪一個網站第一次發佈的時候就擁有龐大的用戶，高併發的訪問，海量的數據；大型網站都是從小型網站發展而來。網站的價值在於它能給用戶提供什麼家宅，在於網站能作什麼，而不在於它是怎麼作的，因此網站在小的時候就去追求網站的架構是捨本逐末，得不償失的。小型網站最須要作的就是爲用戶提供更好的服務來創造價值，獲得用戶承認，活下去，野蠻生長。

大型網站軟件系統的特色

• 高併發，大流量
• 高可用
• 海量數據
• 用戶分佈普遍，網絡狀況複雜
• 安全環境惡劣
• 需求快速變動，發佈平頻繁
• 漸進式發展

大型網站的發展歷程

1. 初始階段的網站架構

   最開始沒有多少人訪問，因此應用程序，數據庫，文件都在同一臺機器上。

2. 應用服務器和數據服務分離

   應用和數據分離以後，通常須要三臺服務器。應用服務器，文件服務器和數據庫服務器，這三種服務器對於硬件要求各不相同。

   • 應用服務器：更強大的CPU
   • 數據庫服務器：更快速的磁盤和更大的內存
   • 文件服務器：容量更大的硬盤

3. 使用緩存改善性能

   網站的訪問也遵循二八定律：80%的業務集中在20%的數據上。所以能夠把這一小部分數據緩存在內存中，減小數據庫的訪問壓力。

   網站的緩存能夠分爲兩種：

   • 本地緩存：緩存在應用服務器上。本地緩存訪問速度快，可是受制於內存限制，緩存數量有限，並且也會出現和應用程序爭搶內存的狀況。
   • 遠程分佈式緩存：以集羣的方式，緩存在大內存的專用緩存服務器。能夠在理論上作到不受內存容量限制。
4. 使用應用服務器集羣提升併發能力

   當一臺服務器的處理能力和存儲空間不足的時候，不要企圖更換更強大的服務器。對於大型網站來講，無論多麼強大的服務器，都知足不了網站持續增加的業務需求。此時就能夠考慮集羣的方式，經過負載均衡調度服務器，能夠未來自用戶的請求分發到應用服務器集羣中的任何一臺服務器上。

5. 數據庫讀寫分離

   使用緩存後，大部分的數據讀操做訪問均可以不經過數據庫完成，可是仍有部分讀操做（如緩存過時，緩存不命中）和所有的寫操做須要訪問數據庫。

   目前大部分數據庫都提供主從熱備的功能，在寫數據的時候，訪問主庫，主庫經過主從複製機制將數據更新同步至從數據庫，在讀的時候就能夠經過從數據庫獲取數據。

6. 使用反向代理和CDN加速網站響應

   在《web性能權威指南》中有講到，網站性能的瓶頸，大部分時間都浪費在TCP的握手和傳輸上。所以能夠經過CDN和反向代理的方式來加快響應。

   CDN和反向代理的本質都是經過緩存，不一樣的主要是：

   • CDN部署在服務器器上的機房，用戶在請求時，從距離本身最近的機房獲取數據。
   • 反向代理是部署在中心機房，用戶請求到達中心機房以後，首先訪問的服務器是反向代理的拂去其，若是反向代理服務器中緩存着用戶請求的額資源，就將其返回給用戶。
7. 使用分佈式文件系統和分佈式數據庫系統

   隨着業務的發展，依舊不能知足的時候，就採用分佈式的文件和分佈式的數據庫系統。

   分佈式數據庫是數據庫拆分的最後手段，只用在單表數據規模特別龐大的時候才使用。更經常使用的拆分手段是業務分庫，將不一樣的業務數據存儲在不一樣的數據庫中。

8. 使用NoSQL和搜索引擎

   對數據檢索和存儲愈來愈複雜的時候，就能夠採用一些非關係型數據庫如HBase和非數據庫查詢技術如ElasticSearch等等

9. 業務拆分

   業務場景複雜的時候，通常講整個網站業務分爲不一樣的產品線，如首頁，訂單，買家，賣家等等。

   技術上也會根據產品線劃分，將一個網站分爲許多不一樣的應用，每一個應用獨立部署維護，應用之間能夠經過一個超連接創建聯繫，也能夠經過消息隊列進行數據分發，固然最多的仍是經過訪問同一個數據存儲系統來構成一個關聯的完整系統。

10. 分佈式服務

    隨着業務越拆越小，存儲愈來愈大，維護愈來愈困難。此時就能夠將相同業務操做的提取出來，獨立部署。應用系統只須要管理用戶界面，經過分佈式服務調用共同的業務服務完成具體的業務操做。也就是最近概念愈來愈火的——微服務。

11. 雲計算

    大型網站架構解決了海量數據庫管理和高併發事務處理，能夠將這些解決方案應用到網站自身之外的業務上。如今像阿里雲，亞馬遜等雲計算平臺，將計算做爲一種基礎資源出售，中小網站不須要關係技術架構等問題，只須要按需付費，就可使網站隨着業務的增加得到更大的存儲和計算資源。

12. 將來

    將來還能變成什麼樣子，我也不清楚，也許之後都不是開發人員來維護了，全部的這些都是AI來完成，程序員要作的就是如何完善AI。也許AI發展到最後，人類都不須要存在了吧。

結語

網站的技術是爲業務而存在的，除此之外毫無心義。在技術選型和架構設計中，脫離業務發展實際，一味的追求新技術，可能會把技術發展引入一個歪路。

技術是用來解決業務的問題，而技術不可能將全部問題都解決掉，涉及業務自身的問題，仍是要經過業務手段去解決。