1.1 大型網站軟體系統的特點
與傳統企業應用系統相比，大型互聯網應用系統有以下的特點，
高并發，大流量
需要面對高并發用戶，大流量訪問，Google日均PV數35億，日均IP訪問3億；騰旭QQ的最大在線用戶數1.4億（2011年）；
高可用
系統 7 * 24 小時不間斷服務，
海量資料
需要存盤，管理海量資料，需要使用大量服務器，
用戶分布廣泛，網路情況復雜
許多大型互聯網都是為全球用戶提供服務的，用戶分布范圍廣，各地網路情況千差萬別，
安全環境惡劣
由于互聯網的開放性，使得互聯網站更容易受到攻擊，大型網站幾乎每天都會被黑客攻擊，
需求快速變更，發布頻繁
和傳統軟體的版本發布頻率不同，互聯網產品為快速適應市場，滿足用戶需求，其產品發布頻率是極高的，一般的大型網站的產品每周都有新版本發布上線，
漸進式發展
與傳統軟體產品或企業應用系統一開始就規劃好全部的功能和非功能的需求不同，幾乎所有的大型互聯網站都是從一個小網站開始的，漸進式發展起來的，Facebook是扎克伯格同學在哈佛大學的宿舍里開發的；Google的第一臺服務器補助在斯坦福大學的實驗室里；阿里巴巴則是在馬云家的客廳里誕生的，
1.2 大型網站架構演化發展歷程
大型網站的技術挑戰主要來自于龐大的用戶，高并發的訪問和海量的資料，任何簡單的業務一旦需要處理數以P計的資料和面對數以億計的用戶，問題就會變得既瘦，大型網站架構主要就是解決這類問題，
1.2.1 初始階段的網站架構
大型網站都是從小網站發展而來的，網站架構也是一樣，是從小型網站架構逐步演化而來，小型網站最開始時根本沒有太多人訪問，只需要一臺服務器就綽綽有余，這是網站架構如圖1.1所示，
圖1.1 初始階段的網站架構
應用程式，資料庫，檔案等所有資源都在一臺服務器上，通常服務器作業系統使用Linux，應用程式使用PHP開發，然后部署在Apache上，資料庫使用MySQL，匯集各種免費開源軟體及一臺廉價服務器就可以開始網站的發展之路了，
1.2.2 應用服務和資料服務分離
隨著網站的業務發展，一臺服務器逐漸不能滿足需求：越來越多的用戶訪問導致性能越來越差，越來越多的資料導致存盤空間不足，這是就需要將應用和資料分離，應用和資料分離后整個網站使用三臺服務器：應用服務器、檔案服務器和資料庫服務器，如圖1.2所示，這三臺服務器對硬體資源的要求各不相同，應用服務器需要處理大量的業務邏輯，因此需要更快更強大的CPU；資料庫服務器需要快速磁盤檢索和資料快取，因此需要更快的因公安和更大的記憶體；檔案服務器需要存盤大量用戶上傳的檔案，因此需要更大的硬碟，
圖1.2 應用服務和資料服務分離
應用和資料分離后，不同特性的服務器承擔不同的服務角色，網站的并發處理能力和資料存盤空間得到了很大改善，支持網站業務進一步發展，但是隨著用戶逐漸增多，網站又一次面臨挑戰：資料庫壓力太大導致訪問延遲，進而影響整個網站的性能，用戶體驗受到影響，這是需要對網站架構進一步優化，
1.2.3 使用快取改善網站性能
網站訪問特點和現實世界的財富分配一樣遵循二八定律：80%的業務訪問集中在20%的資料上，淘寶賣家瀏覽的商品集中在少部分成交數多、評價良好的商品上；百度搜索關鍵詞集中在少部分熱門詞匯上；只有經常登錄的用戶在會發微博、看微博，這部分用戶也只占總用戶數的一小部分，
如果把這一小部分資料快取在記憶體中，是不是就可以減少資料庫的訪問眼里，提高整個網站的資料訪問速度，改善資料庫寫入性能了呢？
網站使用的快取可以分為兩種：快取在應用服務器上的本地快取和快取在專門的分布式快取服務器上的遠程快取，本地快取的訪問速度更快一些，但是受應用服務器記憶體的限制，其快取資料量有限，而且會出現和應用程式征用記憶體的情況，遠程分布式快取可以使用集群的方式，部署大記憶體的服務器作為專門的快取服務器，可以在理論上做到不受記憶體量限制的快取服務，如圖1.3所示
圖1.3網站使用快取
使用快取后，資料訪問壓力得到有效緩解，但是單一應用服務器能夠處理的請求連接有限，在網站訪問高峰期，應用服務器成為整個網站的瓶頸，
1.2.4 使用應用服務器集群改善網站的并發處理能力
使用季軍是網站解決高并發，海量資料問題的常用手段，當一臺服務器的處理能力，存盤空間不足時，不要企圖去換更強大的服務器，對于大型網站而言，不管多么強大的服務器，都滿足不了網站持續增長的業務需求，這種情況下，更恰當的做法是增加一臺服務器分擔原有服務器的訪問及存盤壓力，
對網站架構而言，只要能通過增加一臺服務器的方式改善負載壓力，就可以以同樣的方式持續增加服務器不斷改善系統的性能，從而實作系統的可伸縮性，應用服務器實作集群是網站可伸縮集群架構設計中較為簡單成熟的一種，如圖1.4所示，
圖1.4 應用服務器集群部署
通過負載均衡調度服務器，可將來自用戶瀏覽器的訪問請求分發到應用服務器集群中的任何一臺服務器上，如果有更多的用戶，就在集群中加入更多的應用服務器，使應用服務器的負載壓力不在成為整個網站的瓶頸，
1.2.5 資料庫讀寫分離
網站在使用快取后，使絕大部分資料的讀操作訪問都可以不通過資料庫就能完成，但是仍有一部分讀操作和全部的寫操作需要訪問資料庫，在網站的用戶達到一定規模后，資料庫因為負載壓力過高而成為網站的瓶頸，
目前大部分的主流資料庫都是主從熱備功能，通過配置兩臺資料庫的主從關系，可以將一臺資料庫服務器的資料更新同步到另一臺服務器上，網站利用資料庫的這一功能，實作資料庫讀寫分離，從而改善資料庫負載壓力，如圖1.5所示
圖1.5 資料庫讀寫分離
應用服務器在寫資料的時候，訪問主資料庫，主資料庫通過主從復制機制將資料更新同步到從資料庫，這樣當應用服務器讀資料的時候，就可以通過從資料庫獲得資料，為了便于應用程式訪問讀寫分離后的資料庫，通常在應用服務器端使用專門的資料訪問模塊，使資料庫讀寫分離對應用透明，
1.2.6 使用反向代理和CDN加速網站回應
隨著網站業務不斷發展，用戶規模越來越大，由于中國復雜的網路環境，不同地區的用戶訪問網站時，速度差別也極大，有研究表名，網站訪問延遲和用戶流失率正相關，網站訪問越慢，用戶越容易失去耐心而離開，為了提供更好的用戶體驗，留住用戶，網站需要加速網站訪問速度，主要手段有使用CDN和反向代理，如圖1.6所示，
圖1.6 網站使用反向代理和CDN加速訪問
CDN和反向代理的基本原理都是快取，區別在于CDN部署在網路提供商的機房，使用戶在請求網站服務時，可以從距離自己最近的網路提供商機房獲取資料；而反向代理則部署在網站的中心機房，當用戶請求到達中心機房后，首先訪問的服務器是反向代理服務器，如果反向代理服務器中快取著用戶請求的資源，就將其直接回傳給用戶，
使用CDN和反向代理的目的都是盡早回傳資料給用戶，一方面加快用戶訪問速度，另一方面也減輕后端服務器的負載壓力，
1.2.7 使用分布式檔案系統和分布式資料庫系統
任何強大的單一服務器都滿足不了大型網站持續增長的業務需求，資料庫經過讀寫分離后，從一臺服務器拆分成兩臺服務器，但是隨著網站業務的發展依然不能滿足需求，這時需要使用分布式資料庫，檔案系統也是一樣，需要使用分布式檔案系統，如圖1.7所示，
分布式資料庫是網站資料庫拆分的最后手段，只有在單表資料規模非常龐大的時候才使用，不到萬不得已時，網站更常用的資料庫拆分手段是業務分庫，將不同業務的資料庫部署在不同的物理服務器上，
圖1.7 使用分布式檔案和分布式資料庫系統
1.2.8 使用NoSQL和搜索引擎
隨著網站業務越來越復雜，對資料存盤和檢索的需求也越來越復雜，網站需要采用一些非關系資料庫和技術如NoSQL和非資料庫查詢技術如搜索引擎，如圖1.8所示，
圖1.8 使用NoSQL和搜素引擎
NoSQL和搜索引擎都是源自互聯網的技術手段，對可伸縮的分布式特性具有更好的支持，應用服務器則通過一個統一資料訪問模塊訪問各種資料，減輕應用程式管理諸多資料源的麻煩，
1.2.9 業務拆分
大型網站為了應對日益復雜的業務場景，通過使用分而治之的手段將整個網站業務分成不同的產品線，如大型購物交易網站就會將首頁、商鋪、訂單、賣家、買家等拆分成不同的產品線，分歸不同的業務團隊負責，
具體到技術上，也會根據蟾皮年劃分，將一個網站拆分成許多不同的應用，每個應用獨立部署維護，應用之間可以通過一個超鏈接建立關系，也可以通過訊息佇列進行資料分發，當然最多的還是通過訪問同一個資料存盤系統來構成一個關聯的完整系統，如圖1.9所示，
圖1.9 應用拆分
1.2.10 分布式服務
隨著業務拆分越來越小，存盤系統越來越大，應用系統的整體復雜度呈指數級增加，部署維護越來越困難，由于所有應用要和所有資料庫系統連接，在數萬臺服務器規模的網站中，這些連接的數目是服務器規模的平方，導致資料庫連接資源不足，拒絕服務，
既然每個應用系統都需要執行許多相同的業務操作，比如用戶管理、商品管理等，那么可以將這些共用的業務提取出來獨立部署，由這些可復用的業務連接資料庫，提供共用業務服務，而應用系統只需要管理用戶界面，通過分布式服務呼叫共用業務服務完成具體業務操作，如圖1.10所示，
圖1.10 分布式服務
大型網站的架構演化到這里，基本上大多數的技術問題都得以解決，諸如跨資料中心的實時資料同步和具體網站業務相關的問題也都可以通過組合改進現有技術架構來解決，
但事物發展到一定階段，就會擁有自身的發展沖動，擺脫其初衷，向著使自己更強大的方向發展，既然大型網站架構解決了海量資料的管理和高并發事務的處理，那么就可以把這些解決方案應用到網站自身以外的業務上去，我們看到目前許多大型網站都開始建設云計算平臺，將計算作為一種基礎資源出售，中小網站不需要再關心技術架構問題，只需要按需付費，就可以使網站隨著業務的增長逐漸獲得更大的存盤空間和更多的計算資源，
1.3 大型網站架構演化的價值觀
這個世界沒有哪個網站從誕生起就是大型網站；網站的價值在于它能為用戶提供什么價值，在于網站能做什么，而不在于怎么做的，小型網站最需要做的就是為客戶提供好的服務來創造價值，得到用戶的認可，活下去，野蠻生長，
1.3.1 大型網站架構技術核心價值是隨網站所需靈活應對
大型網站架構技術的核心價值不是從無到有搭建一個大型網站，而是能夠伴隨小型網站業務的逐步發展，慢慢演化成一個大型網站，在漫長的技術演化程序中，不需要放棄什么，不需要推翻什么，不需要劇烈的革命，就那么潤物細無聲的把一個只有一臺服務器，幾百個用戶的小網站演化成一個幾十萬臺服務器，數十億用戶的大網站，
1.3.2 驅動大型網站技術發展的主要力量是網站業務的發展
創新的業務發展模式對網站架構逐步提出更高要求，才使得創建的網站架構得以發展成熟，是業務成就了技術，是事業成就了人，而不是相反，
1.4 網站架構的設計誤區
在大型網站架構發展程序中有如下幾個容易出現的誤區
1.4.1 一味追求大公司的解決方案
由于大公司巨大陳宮的光環效應，再加上從大公司挖來的技術高手的影響，網站在討論架構決策時，最有說服力的一句話就成了“淘寶就是這么搞得”或者“Facebook就是這么搞得”，
大公司的經驗和成功的模式固然重要，值得學習借鑒，但如果因此變得盲從，就失去了堅持自我的勇氣，在架構演化的道路上遲到會迷路，
1.4.2 為了技術而技術
網站技術是為業務而存在的，除此毫無意義，在技術選型和架構設計中，脫離網站業務發展的實際，一味追求時髦的新技術，可能會將網站技術發展引入崎嶇小道，架構之路越走越難，
1.4.3 企圖用技術解決所有問題
最典型的例子就是2012年年初12306故障事件后，軟體開發技術屆的反應，
各路專業和非專業人士眾說紛紜的幫12306技術架構出謀劃策，甚至有人提議幫12306寫個開源的網站，解決其大規模并發訪問的問題，
12306真正的問題其實不在于技術架構，而在于業務架構；后來12306在售票的方式上引入了排隊機制、整點售票調整為分時段售票，其實如果能控制住并發訪問的量，很多技術的技術問題也就不是什么問題了，
1.5 小結
時至今日，大型網站的架構演化方案已經非常成熟，各種技術方案也逐漸產品化，許多小型網站已經慢慢不需要在經歷大型網站經歷過的架構演化之路就可以逐步發展壯大，因為現在越來越多的網站從建立之初就是搭建在大型網站提供的云計算服務基礎之上，所需要的一切技術資源：計算，存盤，網路都可以按需購買，線性伸縮，不需要自己一點一點拼湊各種資源，綜合使用各種技術方案，逐步去完善自己的網站架構了，
所以能親身經歷一個網站從小到大的架構演化程序的網站架構師越來越少，雖然過去有這種經歷的架構師也很少，但是將來可能真就沒有了，
但也正因為網站架構技術演化程序難以重現，所以網站架構師更應該對這個程序深刻了解，理解已成熟的網站架構技術方案的來龍去脈和歷史淵源，在技術選型和架構決策時才能有的放矢，直擊要害，
免責：
只是想將學過的知識用另一種方式輸出，如果侵權請聯系本人刪帖，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/285702.html
標籤：其他