本文着重凸顯每一幅圖的精彩之處與其背後含義,而圖的說明性文字則從簡從略。ok,好好享受此番架構盛宴吧。當然,若有任何建議或問題,歡迎不吝指正。謝謝。
- 1、WikiPedia 技術架構
WikiPedia 技術架構圖Copy @Mark Bergsma
- 來自wikipedia的數據:峯值每秒鐘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 的內容性質決定的--面向各個國家,各個地域。
- 負載均衡:LVS,請看下圖:
。
- 2、Facebook 架構
細心的讀者一定能發現,上副架構圖之前出現在此文之中:從幾幅架構圖中偷得半點海里數據處理經驗。本文與前文最大的不同是,前文只有幾幅,此文系列將有上百幅架構圖,任您盡情觀賞。
Facebook 搜索功能的架構示意圖
- 3、Yahoo! Mail 架構
Yahoo! Mail 架構部署了 Oracle RAC,用來存儲 Mail 服務相關的 Meta 數據。
Yahoo! Mail 架構
- 4、twitter技術架構
twitter平臺大致由twitter.com、手機以及第三方應用構成,如下圖所示(其中流量主要以手機和第三方爲主要來源):
twitter的整體架構設計圖
緩存在大型web項目中起到了舉足輕重的作用,畢竟數據越靠近CPU存取速度越快。下圖是twitter的緩存架構圖:
關於緩存系統,還可以看看下幅圖:
- 5、Google App Engine技術架構
簡單而言,上述GAE的架構分爲如圖所示的三個部分:前端,Datastore和服務羣。
GAE的架構圖
- 前端包括4個模塊:Front End,Static Files,App Server,App Master。
- Datastore是基於BigTable技術的分佈式數據庫,雖然其也可以被理解成爲一個服務,但是由於其是整個App Engine唯一存儲持久化數據的地方,所以其是App Engine中一個非常核心的模塊。其具體細節將在下篇和大家討論。
- 整個服務羣包括很多服務供App Server調用,比如Memcache,圖形,用戶,URL抓取和任務隊列等。
- 6、Amazon技術架構
可能有讀者並不熟悉Amazon,它現在已經是全球商品品種最多的網上零售商和全球第2大互聯網公司。而之前它僅僅是一個小小的網上書店。ok,下面,咱們來見識下它的架構。
Amazon的Dynamo Key-Value存儲架構圖
Dynamo是亞馬遜的key-value模式的存儲平臺,可用性和擴展性都很好,性能也不錯:讀寫訪問中99.9%的響應時間都在300ms內。按分佈式系統常用的哈希算法切分數據,分放在不同的node上。Read操作時,也是根據key的哈希值尋找對應的node。Dynamo使用了 Consistent Hashing算法,node對應的不再是一個確定的hash值,而是一個hash值範圍,key的hash值落在這個範圍內,則順時針沿ring找,碰到的第一個node即爲所需。
Dynamo對Consistent Hashing算法的改進在於:它放在環上作爲一個node的是一組機器(而不是memcached把一臺機器作爲node),這一組機器是通過同步機制保證數據一致的。
下圖是分佈式存儲系統的示意圖,讀者可觀摩之:
Amazon的雲架構圖如下:
Amazon的雲架構圖
- 7、優酷網的技術架構
這樣,就根據module、method及params來確定調用相對獨立的模塊,顯得非常簡潔。下圖是優酷的前端局部架構圖:
優酷的數據庫架構也是經歷了許多波折,從一開始的單臺MySQL服務器(Just Running)到簡單的MySQL主從複製、SSD優化、垂直分庫、水平sharding分庫。
- 簡單的MySQL主從複製。
MySQL的主從複製解決了數據庫的讀寫分離,並很好的提升了讀的性能,其原來圖如下:
其主從複製的過程如下圖所示:
但是,主從複製也帶來其他一系列性能瓶頸問題:- 寫入無法擴展
- 寫入無法緩存
- 複製延時
- 鎖表率上升
- 表變大,緩存率下降
- MySQL垂直分區
如果把業務切割得足夠獨立,那把不同業務的數據放到不同的數據庫服務器將是一個不錯的方案,而且萬一其中一個業務崩潰了也不會影響其他業務的正常進行,並且也起到了負載分流的作用,大大提升了數據庫的吞吐能力。經過垂直分區後的數據庫架構圖如下:
然而,儘管業務之間已經足夠獨立了,但是有些業務之間或多或少總會有點聯繫,如用戶,基本上都會和每個業務相關聯,況且這種分區方式,也不能解決單張表數據量暴漲的問題,因此爲何不試試水平sharding呢? - MySQL水平分片(Sharding)
這是一個非常好的思路,將用戶按一定規則(按id哈希)分組,並把該組用戶的數據存儲到一個數據庫分片中,即一個sharding,這樣隨着用戶數量的增加,只要簡單地配置一臺服務器即可,原理圖如下:http://write.blog.csdn.net/postedit?ref=toolbar
如何來確定某個用戶所在的shard呢,可以建一張用戶和shard對應的數據表,每次請求先從這張表找用戶的shard id,再從對應shard中查詢相關數據,如下圖所示: 但是,優酷是如何解決跨shard的查詢呢,這個是個難點,據介紹優酷是儘量不跨shard查詢,實在不行通過多維分片索引、分佈式搜索引擎,下策是分佈式數據庫查詢(這個非常麻煩而且耗性能)。 - 緩存策略
貌似大的系統都對“緩存”情有獨鍾,從http緩存到memcached內存數據緩存,但優酷表示沒有用內存緩存,理由如下:- 避免內存拷貝,避免內存鎖
- 如接到老大哥通知要把某個視頻撤下來,如果在緩存裏是比較麻煩的
但爲何我們訪問優酷會如此流暢,與土豆相比優酷的視頻加載速度略勝一籌?這個要歸功於優酷建立的比較完善的內容分發網絡(CDN),它通過多種方式保證分佈在全國各地的用戶進行就近訪問——用戶點擊視頻請求後,優酷網將根據用戶所處地區位置,將離用戶最近、服務狀況最好的視頻服務器地址傳送給用戶,從而保證用戶可以得到快速的視頻體驗。這就是CDN帶來的優勢,就近訪問。