99精品在线视频观看,久久青草视频,亚洲w码欧洲s码免费

　　背景

　　在看阿凡達的時候，感嘆著他們接口的統(tǒng)一，和獲取知識的便利性。有時候在想，現(xiàn)在很多企業(yè)所做的工作，不就是要提供這類服務嗎。設想一下，我們有一朵公有云，存儲了用戶的數(shù)據(jù)、邏輯關系，提供標準的通訊接口，然后大家各自開發(fā)豐富的展現(xiàn)邏輯，讓云端變的豐富多彩。這次很榮幸能接到這個議題，談談我個人對這朵云的理解。

　　每個人心中都有自己的一朵云，在我設想中，應該存在這么一種公有服務，它能夠幫助用戶隨時隨地的獲取自己的數(shù)據(jù)，與朋友交流，獲取好友最新狀態(tài)。在這服務之上，我們有這么一個平臺，它能夠給用戶提供二次開發(fā)的接口，讓開發(fā)者根據(jù)用戶數(shù)據(jù)開發(fā)豐富的展現(xiàn)層，并且提供這些展現(xiàn)層的運行平臺。

　　我們需要的云端服務

　　為了完成這個功能，我們需要什么準備？

　　云存儲：提供用戶數(shù)據(jù)的存儲功能。讓用戶方便的獲取自己的數(shù)據(jù)。

　　通訊系統(tǒng)：提供以Mail，IM為基礎的通訊方式。

　　通知系統(tǒng)：好友行為推送，能夠把握好友最新動態(tài)，或者告知好友你在干什么。

　　在這三個基本服務之上，用戶可以開發(fā)大量的運用。比如“音樂盒”用于在線播放云存儲的MP3，圖片系統(tǒng)用于管理、分享，美化自己的照片……然而，用戶開發(fā)完邏輯應用之后，需要機器運行這個運用。因此，第四個基本服務運行平臺孕育而生，它提供所有云應用運行的基本資源，包括內(nèi)存、CPU、操作系統(tǒng)等。

　　這四個基本要素構(gòu)建成一個面向終端用戶的操作系統(tǒng)平臺（也就是我們的云），它能夠隨時被訪問，通過瀏覽器或者手機的App。滿足用戶在任意時刻團購，玩三國殺，看視頻，聽音樂等需求。為了方便開發(fā)者開發(fā)更多的應用，我們抽象一種編程模式，提供豐富的SDK，加速應用的開發(fā)。由于云端服務，有很大一部分會被手機等嵌入式設備訪問，于是需要各種平臺的編程框架（Android、ios）。編程框架將更加關心業(yè)務邏輯，屏蔽分布式細節(jié)和運維問題。

　　在滿足這些開發(fā)便利性的前提下，為鼓勵用戶開發(fā)，提高APP質(zhì)量和數(shù)目，需要一套良好的收費系統(tǒng)，幫助開發(fā)者更好的盈利。

　　圍繞這這朵云，一點點的展開，發(fā)現(xiàn)想說的東西太多，今天我們就談談其中的兩個核心架構(gòu)：云端存儲和應用運行平臺（App Engine）。為什么要選這兩個？因為云的核心就是存儲和計算，其它都構(gòu)建在存儲和計算之上的基礎服務和用戶運用。

　　云端存儲架構(gòu)

　　云端存儲主要是為了存儲用戶數(shù)據(jù)，方便用戶訪問。它涉及了三方面的技術(shù)：

底層架構(gòu)。包括：分布式存儲、文件目錄管理、用戶權(quán)限系統(tǒng)。
下載優(yōu)化：各地CDN支持、客戶端下載技術(shù)（P2P）。
數(shù)據(jù)訪問前端優(yōu)化

　　底層架構(gòu)設計的要點

　　首先我們比較一下跟傳統(tǒng)離線存儲的設計指標差異

單個文件體積不大

存儲互聯(lián)網(wǎng)用戶的數(shù)據(jù)，注定文件不會很大。我們只要支持0-100G左右的單文件大小即可。為什么用戶文件會到100G？因為我們要保證用戶能分享高清電影。另外相對于海量的容量，如果單文件過小，那么海量空間也沒啥意義。多媒體是促進磁盤發(fā)展的動力。

文件數(shù)會很多

跟GFS不一樣，云存儲的文件數(shù)是海量的。因為每個人都會存儲他們的文檔、mp3、圖片……這注定了單機保存全部文件的node是不可能的。

我們需要呈現(xiàn)傳統(tǒng)操作系統(tǒng)類似的目錄管理方式。另外根據(jù)云存儲文件數(shù)量多的特點，我們要提供可靠的檢索做文件管理。

讀寫模式特殊性

用戶對文件的訪問模式是一次寫入，多次讀取，讀取支持隨機位置的讀取（比如視頻從中間開始播放）等。另外考慮在用戶帶寬條件下，100M的文件也算是大文件了，我們要需要支持斷點續(xù)傳功能。另外，存在對單文件的高并發(fā)訪問。

檢索和訪問的實時性

用戶上傳的數(shù)據(jù)，在上傳成功之后，就應該能訪問到完整的數(shù)據(jù)。并且在檢索的時候就能夠體現(xiàn)出來。因此不僅要求存儲系統(tǒng)要求實時性，而且檢索系統(tǒng)也有要求實時性。

　　歸納一下，因為文件太小導致文件數(shù)過多，需要專門的目錄存儲；針對文件的訪問模式，我們需要設計一個比較合理的文件格式；提升檢索的實時性。

　　文件格式介紹

　　一個文件需要的存儲數(shù)據(jù)：Meta信息和數(shù)據(jù)塊。Meta信息存儲這個文件的詳細信息，包括文件名、大小、文件類型（doc或者mp3）、MD5、創(chuàng)建者、具體數(shù)據(jù)塊的存放位置、數(shù)據(jù)塊大小，以及該文件格式的版本信息等。數(shù)據(jù)塊是真正存儲的文件數(shù)據(jù)。

　　我們將一個完整的文件，物理切成多塊。比如一個1G的文件，我們按照1M為塊大小，切成1024塊，然后將1024個塊數(shù)據(jù)散列到N臺機器中去。從而保證文件具備高并發(fā)的特點，而且也能夠方便的為整個集群提供擴展能力。然后我們會將這1024個塊的具體位置記錄到文件的meta信息中，方便訪問。

　　因此，我們需要一個邏輯文件的訪問入口（WebServer），和存儲這些數(shù)據(jù)塊與Meta信息的集群Chunk Cluster和Meta Cluster。

　　將一個不大的文件分散到各臺機器上存儲有什么好處？

方便做負載均衡和集群擴容
將熱門文件的流量分散到各臺機器上，使熱門文件的高頻訪問對后端影響降低。

　　這個文件格式的設計，大家可能會覺得文件很大的話，Meta信息因需要存儲的塊位置而導致體積過大。其實這個問題，可以通過二級索引塊來解決。

　　存儲架構(gòu)的工作原理

　　如上圖，WebServer在接收Http請求的時候，會解析參數(shù)，然后根據(jù)Meta Cluster提供的Meta信息，讀取相關塊，返回給請求者。Chunck Cluster和Meta Cluster的設計都是一樣的，就是提供一套NoSQL系統(tǒng)，支持針對Key（字符串） - value（二進制）的增刪改查。但是考慮到訪問頻率的不同，我們需要針對不同的硬件做單機的優(yōu)化，比如廉價的Sata盤存放相對靜止的數(shù)據(jù)，SSD盤存放訪問頻率過高的數(shù)據(jù)。

　　NoSQL集群不是我們這篇文件要簡述的話題，有機會可以詳談。不過即使是分布式系統(tǒng)，我們也應注重模塊的單機性能。因為如果我們的模塊單機性能提高一倍，那么我們的集群規(guī)模就會下降一倍。在上萬臺機器中，節(jié)約的成本是非常可觀的。我們?nèi)绾魏饬窟@個存儲系統(tǒng)的單機引擎性能呢？方法很簡單，如果一個單機模塊，能夠?qū)⒕W(wǎng)卡吞吐跑滿或者磁盤順序讀寫吞吐跑滿，對于存儲模塊本身來說，可以了。

　　目錄管理系統(tǒng)實現(xiàn)

　　海量文件的目錄管理，很難。這里，我們采用一個分布式有序表的方式來解決，分布式有序表也是NoSQL的一種。它對存儲的數(shù)據(jù)，提供基于字典序的游標查詢。比如：我們將所有的用戶文件名放入有序表中，該系統(tǒng)就會產(chǎn)生根據(jù)文件名排序的分布式數(shù)組，如下：

　　[/a.doc; /a/a.doc; /a/b.doc; /a/c.doc; /b.doc; /b/b/b.doc]

　　在執(zhí)行l(wèi)s /a/命令的時候，我們會尋找/a/的游標得到/a/a.doc，接著我們開始遍歷這個游標，直到不是/a/打頭為止。如果該過程中碰到子目錄，程序會會通過二分查找直接跳過子目錄，從而防止遍歷過多。如果數(shù)目過多，我們會展現(xiàn)100條，其它隱藏。目錄管理，主要是給用戶組織自己數(shù)據(jù)的時候用的，理論上，用戶不會在一個目錄下放太多的文件，即使太多，也沒關系，我們就顯示100條，然后提供下一頁的按鈕（因為下一頁的游標位置我們是知道的）。

　　實時檢索系統(tǒng)

　　討論這個議題的時候，需要假設我們已經(jīng)有一個傳統(tǒng)的檢索系統(tǒng)，然后想辦法提高檢索的實時性。我們設計一個內(nèi)存索引，把用戶新增的文件，對文件名切詞后放到內(nèi)存中檢索，檢索的結(jié)果參與最終的合并。每隔五分鐘merge到傳統(tǒng)檢索系統(tǒng)中，然后釋放內(nèi)存。云存儲，不像互聯(lián)網(wǎng)網(wǎng)頁，在5分鐘之內(nèi)，僅文件名的索引，數(shù)據(jù)量不可能太大，所以內(nèi)存不會是瓶頸。進一步的，我們可以對文件的內(nèi)容作檢索，但是文件內(nèi)容沒有必要做到實時。

　　權(quán)限系統(tǒng)

　　用戶權(quán)限系統(tǒng)，對于云存儲來說，也是個用戶文件，所以沒什么特別的，只不過我們需要專門的緩存做訪問優(yōu)化。因為每一次讀寫請求，都要判斷訪問者是否有相關的權(quán)限。

　　CDN技術(shù)

　　P2P技術(shù)和CDN支持，主要是為了減少帶寬成本而做的，在云存儲這種數(shù)據(jù)量巨大的服務中，這兩種技術(shù)，顯的尤為重要。這兩塊是兩個專題，我們在這里不多做介紹。不過這兩個技術(shù)在解決熱點問題效果比較好，但是海量文件并不是所有文件都放CDN的，因此有些工作，數(shù)據(jù)訪問前端不得不做。

　　數(shù)據(jù)訪問與客戶端優(yōu)化考慮

　　客戶端訪問速度差別，是我們要考慮的問題。如果是內(nèi)部的訪問，帶寬可以保證是1000M以上，但是面向互聯(lián)網(wǎng)用戶，各種各樣的帶寬需求都有，比如GPRS、3G、ADSL，從20k-16M不等。這就要求我們的前端技術(shù)，在處理這些請求下要工作的很好。另外我們還要考慮在正常服務下，網(wǎng)絡帶寬最小化，比如一個視頻是100分鐘，我們就應該保證100分鐘內(nèi)傳完，滿足正常播放，不能太快，因為太快，你不能保證用戶有耐心看完，可能他就看10分鐘，然后就關了，于是后面?zhèn)鬏數(shù)膸捜速M了。如果是用戶下載，那么當然是越快越好。這些控制，我們都通過WebServer來實現(xiàn)。

　　WebServer最主要的功能就是高并發(fā)支持，限速。再加上云存儲的數(shù)據(jù)是海量的，傳統(tǒng)的Apache做WebServer肯定不適合，這里我們采用異步的WebSever比如lighttpd或者nginx，然后對客戶端句柄進行速度控制。為了支持大文件的斷點上傳，我們需要有一個專門的客服端，能夠?qū)⑽募謮K上傳。Webserver必須支持根據(jù)md5查詢這個文件哪些塊已經(jīng)上傳了，哪些沒上傳，從而通知客戶端正常工作。

　　云存儲有很多節(jié)約帶寬的優(yōu)化，比如上傳文件的時候，先上傳md5，如果云端已經(jīng)存在，就不需要上傳了，這樣可以做到大文件的秒傳，節(jié)約網(wǎng)絡帶寬。另外它提供對外標準的Http協(xié)議，可以采用迅雷等p2p軟件下載，從而提高訪問速度，減少服務器帶寬沖擊。為了數(shù)據(jù)安全性，我們還得提供https協(xié)議的數(shù)據(jù)訪問。

　　App Engine

　　完成云存儲的設計之后，我們需要一個開發(fā)平臺，這個開發(fā)平臺提供用戶邏輯的運行環(huán)境。這環(huán)境包括

MYSQL集群化管理
離線任務的處理
php的運行環(huán)境

　　MySQL集群化管理

　　因為云存儲沒有提供關系數(shù)據(jù)的存儲功能，為了降低用戶的開發(fā)門檻，我們需要一個MYSQL的集群化來完成類似的功能。MYSQL的集群化，主要是完成MYSQL讀寫分離和主從同步功能。

　　通過這種架構(gòu)，保證了開發(fā)者不需要關心MYSQL的數(shù)據(jù)故障等問題。因為MYSQL Proxy會自動的進行主從切換和讀寫分離。這里我們要開發(fā)的就是解析SQL語句，完成相關的用戶認證，并完成相關的后臺轉(zhuǎn)發(fā)、接收。

　　MYSQL的集群化管理沒有解決分布式的問題，這個地方我們認為不需要解決。因為互聯(lián)網(wǎng)在線業(yè)務類的關系數(shù)據(jù)不會太大，大的數(shù)據(jù)都放到云存儲里面了，數(shù)據(jù)庫只存索引。還有，數(shù)據(jù)庫的分庫分表也相對成熟，索引數(shù)據(jù)也很難快速膨脹。如果用戶有對分布式索引的需求，可以考慮前面我們談到的有序表。

　　離線任務處理

　　離線任務處理主要解決，用戶需要做大量的cpu密集型的工作，包括圖片轉(zhuǎn)化，視頻轉(zhuǎn)化等。我們這里采用了一套消息隊列的方式進行離線處理。用戶將處理請求扔給消息隊列，執(zhí)行機獲取消息隊列的消息之后，會執(zhí)行相關的的用戶代碼。

　　php運行環(huán)境

　　php運行環(huán)境，主要解決php的分布式化問題。云平臺上跑的服務，千奇百怪，可能因為沒有流量，只用到實際機器的千分之一，也可能擁有巨額流量，需要上百臺機器支持。當然大部分服務沒有什么流量。對于傳統(tǒng)的虛擬化來說，1臺機器能虛擬化成32臺，已經(jīng)慢的不行。這樣，一臺物理機只能部署32個app運用，對于基礎架構(gòu)來說是不可接受的。因為互聯(lián)網(wǎng)上的云端運用，會急劇膨脹，所以我們需要一種新的虛擬化架構(gòu)，能將機器的粒度切的更細。

　　這里我們使用php為開發(fā)語言展示一個輕量級的虛擬化技術(shù)。我們通過輕量級虛擬化技術(shù)，為每個用戶分配一組FAST CGI進程資源，通過Web端的調(diào)度，將請求引到各自的FAST CGI進程組中處理。這樣一臺機器能啟動多少個進程，我們就能虛擬化多少份。

　　如果網(wǎng)站流量很大，單機處理不了，該如何解決？我們是通過FAST CGI進程個數(shù)來調(diào)度的，單機資源不夠的情況下，我們會在多臺機器上分配進程，組成一個FAST CGI組，然后通知Web端，這個網(wǎng)站的請求可以分流到哪些FAST CGI中去。我們會有一個總控的Master來觀察各臺機器的負載，從而判斷是否要遷移FAST CGI進程。FAST CGI進程的遷移是簡單的，這臺機器KILL，在另外一臺機器重啟即可。

　　這個是我們php執(zhí)行環(huán)境的架構(gòu)。

　　架構(gòu)依賴于資源定位服務。資源定位通知前端接入，哪些機器負載還行，可以引流，哪些已經(jīng)故障，或者壓力過大，不能引流。當A.baidu.com的流量過來的時候，前端接入會解析域名，并且根據(jù)資源定位獲取的數(shù)據(jù)（本地有緩存），分發(fā)到對應的某臺機器的FAST CGI端口上，執(zhí)行php代碼后返回。因為FAST CGI讀取的用戶代碼存儲在網(wǎng)絡文件系統(tǒng)中，所以前端接入無論選擇哪臺FAST CGI都能夠有效的做處理。在實際過程中，我們發(fā)現(xiàn)網(wǎng)絡文件系統(tǒng)對性能，尤其是HTML的訪問性能影響很大，因此我們對每臺機器做了單機緩存。不過Cache失效是個非常難解決的問題，我們這里采用的方法是一但文件發(fā)生修改，資源定位會通知所有客戶機的該文件緩存失效，而且更新必須走同一的入口。由于我們只存儲代碼，效果還可以。有了分布式的網(wǎng)絡文件系統(tǒng)，用戶代碼更新也變得異常簡單。只要更新完成，通知緩存失效即可。

　　另外一個問題，如果運行平臺跑大量的垃圾網(wǎng)站，比如很多一天只有少量請求的網(wǎng)站。用輕量級虛擬化，即使1臺機器切出2000千份資源，還是很浪費的。對于這種運用，我們采用了FAST CGI復用，即很多小網(wǎng)站的請求都落到1個FAST CGI上，然后FAST CGI根據(jù)目前處理的網(wǎng)站，來獲取相關的配額控制。真正做到資源消耗跟訪問量成正比，沒訪問沒成本。這里可能用CGI更好點，不過為了架構(gòu)統(tǒng)一下，這點優(yōu)化不算麻煩。

　　小結(jié)

　　簡單介紹了App Engine所具有的能力，一個php的輕量級虛擬化，能夠?qū)?臺機器虛擬成萬分之一，也能將萬臺機器合成1個大的虛擬環(huán)境。實現(xiàn)從萬分之一到萬倍計算資源的漸進分配。它成功解決了一個網(wǎng)站，從小到大的計算能力的無限擴展問題。

　　也介紹了云存儲所具備的能力，它支持海量的數(shù)據(jù)存儲，成功解決了一個網(wǎng)站，從小到大的存儲能力無限擴展問題。

　　整個云端運用，就是基于強悍可伸縮的計算能力和存儲能力之下構(gòu)建的網(wǎng)站。我們真正做的就是邏輯開發(fā)，和各個終端下的特殊展現(xiàn)形式。用這套架構(gòu)，實現(xiàn)一個視頻分享網(wǎng)站，電子書閱讀網(wǎng)站是容易的。減少了云端應用的開發(fā)門檻，整個云端產(chǎn)品也將豐富多彩。它們都用統(tǒng)一的架構(gòu)，計算和存儲分離，程序開發(fā)無狀態(tài)化，持久性存儲放在云存儲中。

　　有給力的基礎架構(gòu)，云端運用隨手拈來。目前在百度公司內(nèi)部，這種架構(gòu)已經(jīng)有成型的運用，它極大的提高了應用服務的開發(fā)效率，降低服務運維成本和開發(fā)人員的技術(shù)門檻。百度內(nèi)部云平臺遷移了大量的在線服務，有關百度的最新進展和數(shù)據(jù)，大家可以參考《QCon北京2011全球企業(yè)開發(fā)大會》公布的一些關于BAE的資料。