大型網站系統架構的演化
前言
一個成熟的大型網站（如淘寶、京東等）的系統架構並不是開始設計就具備完整的高效能、高可用、安全等特性，它總是隨著使用者量的增加，業務功能的擴充套件逐漸演變完善的，在這個過程中，開發模式、技術架構、設計思想也發生了很大的變化，就連技術人員也從幾個人發展到一個部門甚至一條產品線。所以成熟的系統架構是隨業務擴充套件而完善出來的，並不是一蹴而就；不同業務特徵的系統，會有各自的側重點，例如淘寶，要解決海量的商品資訊的搜尋、下單、支付，例如騰訊，要解決數億的使用者實時訊息傳輸，百度它要處理海量的搜尋請求，他們都有各自的業務特性，系統架構也有所不同。儘管如此我們也可以從這些不同的網站背景下，找出其中共用的技術，這些技術和手段可以廣泛執行在大型網站系統的架構中，下面就通過介紹大型網站系統的演化過程，來認識這些技術和手段。
一、最開始的網站架構
最初的架構，應用程式、資料庫、檔案都部署在一臺伺服器上，如圖：
二、應用、資料、檔案分離
隨著業務的擴充套件，一臺伺服器已經不能滿足效能需求，故將應用程式、資料庫、檔案各自部署在獨立的伺服器上，並且根據伺服器的用途配置不同的硬體，達到最佳的效能效果。
三、利用快取改善網站效能
在硬體優化效能的同時，同時也通過軟體進行效能優化，在大部分的網站系統中，都會利用快取技術改善系統的效能，使用快取主要源於熱點資料的存在，大部分網站訪問都遵循28原則（即80%的訪問請求，最終落在20%的資料上），所以我們可以對熱點資料進行快取，減少這些資料的訪問路徑，提高使用者體驗。
快取實現常見的方式是本地快取、分散式快取。當然還有CDN、反向代理等，這個後面再講。本地快取，顧名思義是將資料快取在應用伺服器本地，可以存在記憶體中，也可以存在檔案，OSCache就是常用的本地快取元件。本地快取的特點是速度快，但因為本地空間有限所以快取資料量也有限。分散式快取的特點是，可以快取海量的資料，並且擴充套件非常容易，在門戶類網站中常常被使用，速度按理沒有本地快取快，常用的分散式快取是Memcached、Redis。
四、使用叢集改善應用伺服器效能
應用伺服器作為網站的入口，會承擔大量的請求，我們往往通過應用伺服器叢集來分擔請求數。應用伺服器前面部署負載均衡伺服器排程使用者請求，根據分發策略將請求分發到多個應用伺服器節點。
常用的負載均衡技術硬體的有F5，價格比較貴，軟體的有LVS、Nginx、HAProxy。LVS是四層負載均衡，根據目標地址和埠選擇內部伺服器，Nginx是七層負載均衡和HAProxy支援四層、七層負載均衡，可以根據報文內容選擇內部伺服器，因此LVS分發路徑優於Nginx和HAProxy，效能要高些，而Nginx和HAProxy則更具配置性，如可以用來做動靜分離（根據請求報文特徵，選擇靜態資源伺服器還是應用伺服器）。
五、資料庫讀寫分離和分庫分表
隨著使用者量的增加，資料庫成為最大的瓶頸，改善資料庫效能常用的手段是進行讀寫分離以及分表，讀寫分離顧名思義就是將資料庫分為讀庫和寫庫，通過主備功能實現資料同步。分庫分表則分為水平切分和垂直切分，水平切換則是對一個數據庫特大的表進行拆分，例如使用者表。垂直切分則是根據業務不同來切換，如使用者業務、商品業務相關的表放在不同的資料庫中。
六、使用CDN和反向代理提高網站效能
假如我們的伺服器都部署在成都的機房，對於四川的使用者來說訪問是較快的，而對於北京的使用者訪問是較慢的，這是由於四川和北京分別屬於電信和聯通的不同發達地區，北京使用者訪問需要通過互聯路由器經過較長的路徑才能訪問到成都的伺服器，返回路徑也一樣，所以資料傳輸時間比較長。對於這種情況，常常使用CDN解決，CDN將資料內容快取到運營商的機房，使用者訪問時先從最近的運營商獲取資料，這樣大大減少了網路訪問的路徑。比較專業的CDN運營商有藍汛、網宿。
而反向代理，則是部署在網站的機房，當用戶請求達到時首先訪問反向代理伺服器，反向代理伺服器將快取的資料返回給使用者，如果沒有沒有快取資料才會繼續走應用伺服器獲取，也減少了獲取資料的成本。反向代理有Squid，Nginx。
七、使用分散式檔案系統
使用者一天天增加，業務量越來越大，產生的檔案越來越多，單臺的檔案伺服器已經不能滿足需求。需要分散式的檔案系統支撐。常用的分散式檔案系統有NFS。
八、使用NoSql和搜尋引擎
對於海量資料的查詢，我們使用nosql資料庫加上搜索引擎可以達到更好的效能。並不是所有的資料都要放在關係型資料中。常用的NOSQL有mongodb和redis，搜尋引擎有lucene。
九、將應用伺服器進行業務拆分
隨著業務進一步擴充套件，應用程式變得非常臃腫，這時我們需要將應用程式進行業務拆分，如百度分為新聞、網頁、圖片等業務。每個業務應用負責相對獨立的業務運作。業務之間通過訊息進行通訊或者同享資料庫來實現。
十、搭建分散式服務
這時我們發現各個業務應用都會使用到一些基本的業務服務，例如使用者服務、訂單服務、支付服務、安全服務，這些服務是支撐各業務應用的基本要素。我們將這些服務抽取出來利用分部式服務框架搭建分散式服務。淘寶的Dubbo是一個不錯的選擇。
小結
大型網站的架構是根據業務需求不斷完善的，根據不同的業務特徵會做特定的設計和考慮，本文只是講述一個常規大型網站會涉及的一些技術和手段。
參考資料：
《大型網站技術架構》 ——李智慧
《海量運維運營規劃》 ——唐文
相關推薦
一個成熟的大型網站系統架構演化之路
二、應用、資料、檔案分離 隨著業務的擴充套件，一臺伺服器已經不能滿足效能需求，故將應用程式、資料庫、檔案各自部署在獨立的伺服器上，並且根據伺服器的用途配置不同的硬體，達到最佳的效能效果。 三、利用快取改善網站效能 在硬體優化效能的同時，同時也通過軟體進行效能優化，在大部分的網站系統中，都會利
從程式設計小白到架構總監：大型網站系統架構演化之路
前言 一個成熟的大型網站（如淘寶、京東等）的系統架構並不是開始設計就具備完整的高效能、高可用、安全等特性，它總是隨著使用者量的增加，業務功能的擴充套件逐漸演變完善的，在這個過程中，開發模式、技術架構、設計思想也發生了很大的變化，就連技術人員也從幾個人發展到一個
大型網站系統架構的演化
前言 一個成熟的大型網站（如淘寶、京東等）的系統架構並不是開始設計就具備完整的高效能、高可用、安全等特性，它總是隨著使用者量的增加，業務功能的擴充套件逐漸演變完善的，在這個過程中，開發模式、技術架構、設計思想也發生了很大的變化，就連技術人員也從幾個人發展到一個部門甚至一條產品線。所以成熟的系統架構是
P9架構師講解從單機至億級流量大型網站系統架構的演進過程
獲取域名 哈希算法 相關 方案 nat 可靠的 發布 成了 反向 階段一、單機構建網站 網站的初期，我們經常會在單機上跑我們所有的程序和軟件。此時我們使用一個容器，如tomcat、jetty、jboos，然後直接使用JSP/servlet技術，或者使用一些開源的框架如mav
阿里P9架構師講解從單機至億級流量大型網站系統架構的演進過程
階段一、單機構建網站 網站的初期，我們經常會在單機上跑我們所有的程式和軟體。此時我們使用一個容器，如tomcat、jetty、jboos，然後直接使用JSP/servlet技術，或者使用一些開源的框架如maven+spring+struct+hibernate、maven+
阿里P9架構師簡述從單機至億級流量大型網站系統架構的演進過程
階段一、單機構建網站 網站的初期，我們經常會在單機上跑我們所有的程式和軟體。此時我們使用一個容器，如tomcat、jetty、jboos，然後直接使用JSP/servlet技術，或者使用一些開源的框架如maven+spring+struct+hibernate、maven+
大型網站系統架構分析整理
千萬級的註冊使用者，千萬級的帖子，nTB級的附件，還有巨大的日訪問量，大型網站採用什麼系統架構保證效能和穩定性？ 首先討論一下大型網站需要注意和考慮的問題。 資料庫海量資料處理：負載量不大的情況下select、delete和update是響應很迅速的，最多加幾個索引就可以搞
Java面試題精選，大型網站系統架構你不得不懂的10個問題
百度 spring 運行 出現 網站 性能測試 企業 產品 多個 作者：JavaGuide（公眾號） 下面這些問題都是一線大廠的真實面試問題，不論是對你面試還是說拓寬知識面都很有幫助。之前發過一篇8 張圖讀懂大型網站技術架構 可以作為不太了解大型網站系統技術架構朋友的
大型網站系統的演化過程，必須掌握的幾點技術！
一、前言 一個成熟的大型網站（如淘寶、京東等）的系統架構並不是開始設計就具備完整的高效能、高可用、安全等特性，它總是隨著使用者
《大型網站技術架構：核心原理與案例分析》-- 讀書筆記 (5) ：網購秒殺系統
案例 並發 刷新 隨機 url 對策 -- 技術 動態生成 1. 秒殺活動的技術挑戰及應對策略 1.1 對現有網站業務造成沖擊 秒殺活動具有時間短，並發訪問量大的特點，必然會對現有業務造成沖擊。對策：秒殺系統獨立部署 1.2 高並發下的應用、
《大型網站技術架構》讀書筆記一：大型網站架構演化
硬件 解決方案 更新 獨立 流量 操作 大型網站技術架構 負責 思維導圖 一、大型網站系統特點 （1）高並發、大流量：PV量巨大 （2）高可用：7*24小時不間斷服務 （3）海量數據：文件數目分分鐘xxTB （4）用戶分布廣泛，網絡情況復雜：網絡運營
閱讀《大型網站技術架構：核心原理與案例分析》第五、六、七章，結合《河北省重大技術需求征集系統》，列舉實例分析采用的可用性和可修改性戰術
定時 並不會 表現 做出 span class 硬件 進行 情況 網站的可用性描述網站可有效訪問的特性，網站的頁面能完整呈現在用戶面前，需要經過很多個環節，任何一個環節出了問題，都可能導致網站頁面不可訪問。可用性指標是網站架構設計的重要指標，對外是服務承諾，對內是考核指
《大型網站技術架構：核心原理與案例分析》結合需求征集系統分析
運行 模塊 正常 一致性hash 產品 進行 OS 很多 層次 閱讀《大型網站技術架構：核心原理與案例分析》第五、六、七章，結合《河北省重大技術需求征集系統》，列舉實例分析采用的可用性和可修改性戰術，將上述內容撰寫成一篇1500字左右的博客闡述你的觀點。 閱
網購秒殺系統架構設計案例分析——《大型網站技術架構》筆記
一、核心思想： 網站秒殺時的併發比正常運營時多的多，所以網站的秒殺業務不能使用正常的網站業務流程，也不能和正常的網站交易業務共用伺服器（否則造成巨大浪費），必須設計部署專門的秒殺系統，進行專門應對 二、技術挑戰： 1.對現有網站業務造成衝擊：秒殺活動只是網站營銷的一個附加活動，具有時間短
讀大型網站技術架構---第一篇---第一章---架構演化過程
最近開始讀此書，主要為了增加自己知識的廣度，首要目的是即使自己沒有參與過此類專案，但是也能知道在某些場景或者某些架構處理時應該往哪些方向思考。 大型網站系統特點 1.高併發，大流量 2.高可用 3.海量資料 4.使用者分佈廣泛，網路情況複雜 5.安全環境惡劣 6.需求
架構師---（大型網站技術架構核心原理與案例分析）1大型網站架構演化
參考資料大型網站技術架構核心原理與案例分析（作者李智慧） 感悟：書讀百遍，其意自見 QQ群北京it—推薦–交流：300458205 群專注內推、大資料、雲端計算、Java、Android、UI等技術交流，歡迎你的加入。 1初始階段的網站架構 小型網站起初訪問量不是很高，只
《大型網站技術架構》——第一章 大型網站架構演化
初始階段的網站架構 應用程式、資料庫、檔案等所有等資源都在一臺伺服器上。 應用服務和資料服務分離 三臺伺服器：應用伺服器、檔案伺服器和資料庫伺服器。 三臺伺服器對硬體資源對要求各不相同： 應用伺服器需要處理大量的業務邏輯，因此需要更快更強大的CPU 檔案伺服器需
大型網站技術架構（一）--大型網站架構演化
看完了有一本書，就應該有所收穫，有所總結，最近把《大型網站技術架構》一書給看完了，給人的印象實在深刻，再加上之前也搞過書本上講的反向代理和負載均衡以及session獨立儲存和快取，因此書本看起來還是挺通俗易懂的，而且作者李智慧給人的印象（書本）也挺深刻的，
大型電商網站系統架構演變過程
一個成熟的大型網站（如淘寶、天貓、騰訊等）的系統架構並不是一開始設計時就具備完整的高效能、高可用、高伸縮等特性的，它是隨著使用者量的增加，業務功能的 擴充套件逐漸演變完善的，在這個過程中，開發模式、技術架構、設計思想也發生了很大的變化，就連技術人員也從幾個人發展到一個部門甚