引言
近段時間以來玻淑，通過接觸有關海量數(shù)據(jù)處理和搜索引擎的諸多技術舰涌，常常見識到不少精妙絕倫的架構圖陵像。除了每每感嘆于每幅圖表面上的繪制的精細之外就珠，更為架構圖背后所隱藏的設計思想所嘆服。個人這兩天一直在搜集各大型網(wǎng)站的架構設計圖醒颖，一為了一飽眼福妻怎，領略各類大型網(wǎng)站架構設計的精彩之外，二來也可供閑時反復琢磨體會泞歉，何樂而不為呢?特此逼侦，總結(jié)整理了諸如國外wikipedia，F(xiàn)acebook腰耙，Yahoo榛丢！，YouTube挺庞，MySpace晰赞，Twitter，國內(nèi)如優(yōu)酷網(wǎng)等大型網(wǎng)站的技術架構（本文重點分析優(yōu)酷網(wǎng)的技術架構）选侨，以饗讀者掖鱼。
本文著重凸顯每一幅圖的精彩之處與其背后含義，而圖的說明性文字則從簡從略援制。ok戏挡，好好享受此番架構盛宴吧。當然隘谣，若有任何建議或問題增拥，歡迎不吝指正啄巧。謝謝。
1掌栅、WikiPedia 技術架構
WikiPedia 技術架構圖Copy @Mark Bergsma
來自wikipedia的數(shù)據(jù)：峰值每秒鐘3萬個 HTTP 請求 每秒鐘 3Gbit 流量, 近乎375MB? ? ? ? ? ? ? ? ? ? ? ? ? ?
350 臺 PC 服務器秩仆。
GeoDNSA ：40-line patch for BIND to add geographical? ? ? ? ? ? ? ? ? ? ? ? ? filters support to the existent views in BIND",? ? ? ? ? ? ? ? ? ? ? ? ? ? 把用戶帶到最近的服務器。GeoDNS 在 WikiPedia 架構中擔當重任當然是由 WikiPedia? ? ? ? ? ? ? ? ? ? ? ? ? ? 的內(nèi)容性質(zhì)決定的--面向各個國家猾封，各個地域澄耍。
負載均衡：LVS，請看下圖：
2晌缘、Facebook 架構
Facebook 搜索功能的架構示意圖
細心的讀者一定能發(fā)現(xiàn)齐莲，上副架構圖之前出現(xiàn)在此文之中：從幾幅架構圖中偷得半點海里數(shù)據(jù)處理經(jīng)驗。本文與前文最大的不同是磷箕，前文只有幾幅选酗，此文系列將有上百幅架構圖，任您盡情觀賞岳枷。
3芒填、Yahoo! Mail 架構
Yahoo! Mail 架構
Yahoo! Mail 架構部署了 Oracle RAC，用來存儲 Mail 服務相關的 Meta 數(shù)據(jù)空繁。
4殿衰、twitter技術架構
twitter的整體架構設計圖
twitter平臺大致由twitter.com、手機以及第三方應用構成盛泡，如下圖所示（其中流量主要以手機和第三方為主要來源）：
緩存在大型web項目中起到了舉足輕重的作用闷祥，畢竟數(shù)據(jù)越靠近CPU存取速度越快。下圖是twitter的緩存架構圖：
關于緩存系統(tǒng)傲诵，還可以看看下幅圖：
5凯砍、Google App Engine技術架構
GAE的架構圖
? 簡單而言，上述GAE的架構分為如圖所示的三個部分：前端掰吕，Datastore和服務群果覆。
前端包括4個模塊：Front End，Static Files殖熟，App Server局待，App Master。
Datastore是基于BigTable技術的分布式數(shù)據(jù)庫菱属，雖然其也可以被理解成為一個服務钳榨，但是由于其是整個App? ? ? ? ? ? ? ? ? ? ? ? ? Engine唯一存儲持久化數(shù)據(jù)的地方胞谈，所以其是App Engine中一個非常核心的模塊吏奸。其具體細節(jié)將在下篇和大家討論。
整個服務群包括很多服務供App Server調(diào)用豺型，比如Memcache赏陵，圖形饼齿，用戶饲漾，URL抓取和任務隊列等。
6缕溉、Amazon技術架構
Amazon的Dynamo Key-Value存儲架構圖
可能有讀者并不熟悉Amazon考传，它現(xiàn)在已經(jīng)是全球商品品種最多的網(wǎng)上零售商和全球第2大互聯(lián)網(wǎng)公司。而之前它僅僅是一個小小的網(wǎng)上書店证鸥。ok僚楞，下面，咱們來見識下它的架構枉层。
Dynamo是亞馬遜的key-value模式的存儲平臺泉褐，可用性和擴展性都很好，性能也不錯：讀寫訪問中99.9%的響應時間都在300ms內(nèi)鸟蜡。按分布式系統(tǒng)常用的哈希算法切分數(shù)據(jù)膜赃，分放在不同的node上。Read操作時矩欠，也是根據(jù)key的哈希值尋找對應的node财剖。Dynamo使用了? ? ? ? ? ? ? ? ? ? ? ? ? ? Consistent Hashing算法悠夯，node對應的不再是一個確定的hash值癌淮，而是一個hash值范圍，key的hash值落在這個范圍內(nèi)沦补，則順時針沿ring找乳蓄，碰到的第一個node即為所需。
Dynamo對Consistent Hashing算法的改進在于：它放在環(huán)上作為一個node的是一組機器（而不是memcached把一臺機器作為node）夕膀，這一組機器是通過同步機制保證數(shù)據(jù)一致的虚倒。
下圖是分布式存儲系統(tǒng)的示意圖，讀者可觀摩之：
Amazon的云架構圖如下：
Amazon的云架構圖
7产舞、優(yōu)酷網(wǎng)的技術架構
從一開始魂奥，優(yōu)酷網(wǎng)就自建了一套CMS來解決前端的頁面顯示，各個模塊之間分離得比較恰當易猫，前端可擴展性很好耻煤，UI的分離，讓開發(fā)與維護變得十分簡單和靈活准颓，下圖是優(yōu)酷前端的模塊調(diào)用關系：
? 這樣哈蝇，就根據(jù)module、method及params來確定調(diào)用相對獨立的模塊攘已，顯得非常簡潔炮赦。下圖是優(yōu)酷的前端局部架構圖：
優(yōu)酷的數(shù)據(jù)庫架構也是經(jīng)歷了許多波折，從一開始的單臺MySQL服務器（Just Running）到簡單的MySQL主從復制样勃、SSD優(yōu)化吠勘、垂直分庫性芬、水平sharding分庫。
1.簡單的MySQL主從復制剧防。
MySQL的主從復制解決了數(shù)據(jù)庫的讀寫分離批旺，并很好的提升了讀的性能，其原來圖如下：
其主從復制的過程如下圖所示：
但是诵姜，主從復制也帶來其他一系列性能瓶頸問題：
寫入無法擴展
寫入無法緩存
復制延時
鎖表率上升
表變大汽煮，緩存率下降
那問題產(chǎn)生總得解決的，這就產(chǎn)生下面的優(yōu)化方案棚唆。
2. MySQL垂直分區(qū)
如果把業(yè)務切割得足夠獨立暇赤，那把不同業(yè)務的數(shù)據(jù)放到不同的數(shù)據(jù)庫服務器將是一個不錯的方案，而且萬一其中一個業(yè)務崩潰了也不會影響其他業(yè)務的正常進行宵凌，并且也起到了負載分流的作用鞋囊，大大提升了數(shù)據(jù)庫的吞吐能力。經(jīng)過垂直分區(qū)后的數(shù)據(jù)庫架構圖如下：
然而瞎惫，盡管業(yè)務之間已經(jīng)足夠獨立了溜腐，但是有些業(yè)務之間或多或少總會有點聯(lián)系，如用戶瓜喇，基本上都會和每個業(yè)務相關聯(lián)挺益，況且這種分區(qū)方式，也不能解決單張表數(shù)據(jù)量暴漲的問題乘寒，因此為何不試試水平sharding呢望众？
3. MySQL水平分片（Sharding）
? 這是一個非常好的思路，將用戶按一定規(guī)則（按id哈希）分組伞辛，并把該組用戶的數(shù)據(jù)存儲到一個數(shù)據(jù)庫分片中烂翰，即一個sharding，這樣隨著用戶數(shù)量的增加蚤氏，只要簡單地配置一臺服務器即可甘耿，原理圖如下：
如何來確定某個用戶所在的shard呢，可以建一張用戶和shard對應的數(shù)據(jù)表竿滨，每次請求先從這張表找用戶的shard? ? ? ? ? ? ? ? ? ? ? ? ? id佳恬，再從對應shard中查詢相關數(shù)據(jù)，如下圖所示：
是如何解決跨shard的查詢呢姐呐，這個是個難點殿怜，據(jù)介紹優(yōu)酷是盡量不跨shard查詢，實在不行通過多維分片索引曙砂、分布式搜索引擎头谜，下策是分布式數(shù)據(jù)庫查詢（這個非常麻煩而且耗性能）。
? 緩存策略
貌似大的系統(tǒng)都對“緩存”情有獨鐘鸠澈，從http緩存到memcached內(nèi)存數(shù)據(jù)緩存柱告，但優(yōu)酷表示沒有用內(nèi)存緩存截驮，理由如下：
避免內(nèi)存拷貝，避免內(nèi)存鎖
如接到老大哥通知要把某個視頻撤下來际度，如果在緩存里是比較麻煩的
而且Squid 的 write() 用戶進程空間有消耗葵袭，Lighttpd 1.5 的 AIO(異步I/O)? ? ? ? ? ? ? ? ? ? ? ? ? ? 讀取文件到用戶內(nèi)存導致效率也比較低下。
但為何我們訪問優(yōu)酷會如此流暢乖菱，與土豆相比優(yōu)酷的視頻加載速度略勝一籌坡锡？這個要歸功于優(yōu)酷建立的比較完善的內(nèi)容分發(fā)網(wǎng)絡（CDN），它通過多種方式保證分布在全國各地的用戶進行就近訪問——用戶點擊視頻請求后窒所，優(yōu)酷網(wǎng)將根據(jù)用戶所處地區(qū)位置鹉勒，將離用戶最近、服務狀況最好的視頻服務器地址傳送給用戶吵取，從而保證用戶可以得到快速的視頻體驗禽额。這就是CDN帶來的優(yōu)勢，就近訪問皮官。
