人人網(wǎng)移動(dòng)開發(fā)架構(gòu)(下)
相關(guān)文章:人人網(wǎng)移動(dòng)開發(fā)架構(gòu)(上)
真的可以統(tǒng)一架構(gòu)嗎?
可以,瀏覽器本身就是一個(gè)非常優(yōu)秀的跨平臺(tái)解決方案,但這個(gè)方案的前期投入非常大,且項(xiàng)目執(zhí)行風(fēng)險(xiǎn)過高,人人網(wǎng)的業(yè)務(wù)大都是基本動(dòng)態(tài)網(wǎng)頁實(shí)現(xiàn),使用了大量的AJAX及Flash技術(shù),最終我們放棄了瀏覽器方案,我們要的統(tǒng)一架構(gòu)肯定不是這個(gè)。
山窮水盡,柳暗花明
放棄了瀏覽器的方案,我們可謂山窮水盡,難道還有第三個(gè)方案?Facebook的iPhone應(yīng)用給了我們很大靈感,看圖:
圖3
從產(chǎn)品的角度看,這個(gè)圖顯示的布局與我們***次嘗試的設(shè)計(jì)沒什么區(qū)別,深入一點(diǎn)我們會(huì)發(fā)現(xiàn),這個(gè)設(shè)計(jì)與之前的設(shè)計(jì)***區(qū)別在于頁面跳轉(zhuǎn),每個(gè)標(biāo)簽都有獨(dú) 立的一個(gè)視圖棧,理論上無限大,通過當(dāng)前棧頂視圖可以打開新的視圖后自動(dòng)壓棧保存,當(dāng)前視圖如果要后退默認(rèn)退回視圖棧里保存的上一個(gè)視圖的內(nèi)容。那如果是 標(biāo)簽1的頁面需要跳轉(zhuǎn)到標(biāo)簽2對應(yīng)的頁面怎么辦呢,是否自動(dòng)切標(biāo)簽?答案是不切,標(biāo)簽只是用于業(yè)務(wù)導(dǎo)航,且有獨(dú)立的視圖棧,視圖棧中的頁面可以與業(yè)務(wù)無 關(guān),打個(gè)很好理解的比方:當(dāng)我們在使用Chrome的瀏覽器時(shí),我們同時(shí)在多個(gè)標(biāo)簽分別打開多個(gè)不同網(wǎng)站或頁面,也可以打開同樣的網(wǎng)站或頁面,每個(gè)標(biāo)簽都 有一個(gè)獨(dú)立的后退的記錄,這種設(shè)計(jì)非常有規(guī)律,用戶容易理解不容易暈,現(xiàn)在頁面跳轉(zhuǎn)及后退的問題很好的解決了。不論JavaME,還是iPhone或者 Android的客戶端,我們都使用了同樣的設(shè)計(jì)。
數(shù)風(fēng)流人物,還看今朝
當(dāng)我們客戶端都使用了這種標(biāo)簽+視圖棧的方案以后,我們的各平臺(tái)在設(shè)計(jì)上基本達(dá)到了統(tǒng)一,并在現(xiàn)有設(shè)計(jì)上快速迭代演進(jìn)。大家可能想了,在代碼層統(tǒng)一這才 叫本事,也許你沒錯(cuò),但是我們不會(huì)輕意再做這樣高風(fēng)險(xiǎn)的嘗試,如今手機(jī)平臺(tái)的差異相當(dāng)?shù)拇?,就從主流平臺(tái)的開發(fā)語言看就夠你折騰了,JavaME及 Android是使用的Java , iPhone使用的是 Objective-C,Symbian是純C++, 現(xiàn)在諾基亞與微軟聯(lián)姻WP7,可WP7將不再支持C/C++的開發(fā),主推C# + Silverlight,好吧,我們只能再觀察一下了。
在接下來的一到兩年,移動(dòng)互聯(lián)網(wǎng)將以***的速度發(fā)展,大部分互聯(lián)網(wǎng)公司都開始了或已經(jīng)推出了較成熟的移動(dòng)終端的解決方案,創(chuàng)業(yè)公司也會(huì)層出不窮,推出各種優(yōu)秀的移動(dòng)終端應(yīng)用:移動(dòng)支付,LBS,基本通訊簿的即時(shí)通信,手機(jī)音樂,手機(jī)視頻,手機(jī)閱讀等等,iPad點(diǎn)燃平板電腦的硝煙,平板的設(shè)計(jì)再次給了我們很大的挑戰(zhàn),數(shù)風(fēng)流人物,還看今朝。
高可靠性和可擴(kuò)展的服務(wù)
現(xiàn)在移動(dòng)互聯(lián)網(wǎng)拼的都是服務(wù),客戶端良好的用戶體驗(yàn)背后,都有強(qiáng)大的服務(wù)器技術(shù)支撐,人人網(wǎng)也不外如是。
業(yè)務(wù)層次模型
人人網(wǎng)采用JavaEE技術(shù)作為主要的業(yè)務(wù)解決方案,基本按照通用的JavaEE模型進(jìn)行架構(gòu)設(shè)計(jì),如下圖:
圖4 人人網(wǎng)業(yè)務(wù)層次模型
- WEB層基于REST風(fēng)格和MVC設(shè)計(jì)模式,為用戶提供基于WEB的訪問接口人人網(wǎng)采用的是自己開發(fā)的WEB框架 Rose,該框架基于Spring Framework,類似RoR框架,增強(qiáng)了對Controller編碼部分的默認(rèn)約定和REST風(fēng)格URL的支持,該項(xiàng)目前已開源,下載地址為http://code.google.com/p/paoding-rose/
- 業(yè) 務(wù)層封裝業(yè)務(wù)邏輯,為WEB層提供業(yè)務(wù)接口,操作數(shù)據(jù)訪問層提供的數(shù)據(jù)。人人網(wǎng)開發(fā)了自己的SOA框架XOA以支持業(yè)務(wù)層抽象,該框架結(jié)合Rose框架, 以REST風(fēng)格對業(yè)務(wù)進(jìn)行分類、消息格式封裝和路由,如以下URL:xoa://blog.xoa.renren.com/photo/{user- id}/{photo-id}該URL代表某用戶的某個(gè)照片,操作 GET/PUT/POST/DELETE分別對應(yīng)對應(yīng)照片資源的讀、修改、新增、刪除。即通過資源+操作的方式對外提供Service。 XOA支持遠(yuǎn)程調(diào)用,并可以通過簡單添加服務(wù)器的方式進(jìn)行橫向擴(kuò)展。該框架目前準(zhǔn)備開源,敬請關(guān)注。
- 數(shù)據(jù)訪問層提供對數(shù)據(jù)庫訪問的封裝人人網(wǎng)使用Java語言開發(fā)了自己的Object-Relation Mapping框架JADE(Java Database Engine),并支持?jǐn)?shù)據(jù)庫的水平橫向切分。該框架和Rose框架一體開源,下載地址相同。
- 數(shù) 據(jù)持久層數(shù)據(jù)的持久存儲(chǔ),主要采用MySQL數(shù)據(jù)庫,并且開發(fā)了自己的海量存儲(chǔ)系統(tǒng)Nuclear。Rose、Jade、XOA作為集成度很高的一整套解 決方案,在人人網(wǎng)大量采用,大大降低了開發(fā)成本,并在框架級解決了服務(wù)于企業(yè)解決方案的JavaEE技術(shù)在互聯(lián)網(wǎng)領(lǐng)域的適用性。
可擴(kuò)展的高性能系統(tǒng)
人人網(wǎng)每天都要承受億級PV海量用戶的并發(fā)壓力,和其它大型互聯(lián)網(wǎng)站點(diǎn)類似,服務(wù)器架構(gòu)方面做了很多工作。
高性能數(shù)據(jù)存儲(chǔ)系統(tǒng)
在數(shù)據(jù)存儲(chǔ)方面,人人網(wǎng)做了以下工作:
- 和其它互聯(lián)網(wǎng)大型站點(diǎn)相同,MySQL數(shù)據(jù)庫做水平拆分以支持橫向擴(kuò)展
- 人人網(wǎng)作為國內(nèi)***大SNS網(wǎng)站,欲存海量UGC數(shù)據(jù),必有海量存儲(chǔ)系統(tǒng)。Nuclear存儲(chǔ)系統(tǒng)在高性能、高可靠、可擴(kuò)展的海量數(shù)據(jù)存儲(chǔ)需求下橫空出世。
Nuclear本身的數(shù)據(jù)存儲(chǔ)基于Key-Value形式,底層可以使用MySQL/Memory, Cassandra, TC, Redis等存儲(chǔ)引擎,提供弱結(jié)構(gòu)化的查詢功能。
- 高擴(kuò)展性一個(gè)Nuclear集群支持1到n(n<264)個(gè)節(jié)點(diǎn)(Node)的規(guī)模
- 高可靠性單個(gè)節(jié)點(diǎn)的crash永遠(yuǎn)對系統(tǒng)的運(yùn)行造成影響,不存在單點(diǎn)風(fēng)險(xiǎn)。系統(tǒng)永遠(yuǎn)可寫入。
- 高性能在4個(gè)節(jié)點(diǎn)、一般服務(wù)器配置情況下有測試數(shù)據(jù)表明單節(jié)點(diǎn)訪問可達(dá)15862 req/s, 平均單次請求耗時(shí)僅5ms。
可擴(kuò)展的高性能業(yè)務(wù)服務(wù)系統(tǒng)
人人網(wǎng)的業(yè)務(wù)層是支持分布式、可橫向擴(kuò)展的。
- 人人網(wǎng)主要使用JavaEE架構(gòu)進(jìn)行業(yè)務(wù)開發(fā),其中Spring提供的IoC和AOP功能分別起到了業(yè)務(wù)對象裝配和橫向關(guān)注點(diǎn)分離的良好 抽象。XOA框架基于Spring和netty,使用google的spdy協(xié)議作為網(wǎng)絡(luò)傳輸協(xié)議,除享受到Spring紅利之外,也提供了基于Java NIO的網(wǎng)絡(luò)高性能服務(wù)器環(huán)境。單個(gè)XOA服務(wù)是無狀態(tài)的,具有冪等性,XOA客戶端使用Java NIO、通過Keep alive保持對各個(gè)后臺(tái)服務(wù)器的TCP長連接,可實(shí)時(shí)監(jiān)測后臺(tái)服務(wù)器的健康狀況,并把用戶請求負(fù)載分散到各個(gè)后臺(tái)服務(wù)器上,在單個(gè)節(jié)點(diǎn)失效的情況下不影 響服務(wù),如圖5所示:
圖5 XOA負(fù)載均衡 - 很多關(guān)鍵性的業(yè)務(wù)對性能要求特別高,也需要借助很多Linux操作系統(tǒng)的特性,這時(shí)Java的優(yōu)化已經(jīng)不能滿足需求,需要使用 C++語言進(jìn)行開發(fā)。人人網(wǎng)采用ICE框架, 進(jìn)行這部分業(yè)務(wù)的開發(fā),它解決了Java、C++等多種語言開發(fā)的框架和通訊問題。人人網(wǎng)目前使用ICE進(jìn)行開發(fā)的業(yè)務(wù)層稱之為中間層,主要解決類似搜 索、用戶好友關(guān)系計(jì)算等性能要求苛刻的底層關(guān)鍵性業(yè)務(wù)問題。其運(yùn)維模式和XOA類似。和其它大型網(wǎng)站一樣,業(yè)務(wù)層使用Memcached作為業(yè)務(wù)層的分布 式數(shù)據(jù)緩存,且根據(jù)業(yè)務(wù)將緩存集群劃分為多個(gè)池,集中進(jìn)行管理,如圖6所示:
-
圖6 Memcached Pool
- 在WEB層,使用目前性能***的Servlet容器產(chǎn)品Resin作為HTTP Server,使用自行開發(fā)的Java WEB MVC框架Rose對用戶請求請求分發(fā)。負(fù)載均衡方面使用了F5或者nginx。為了減少Session復(fù)制同步的開銷,每臺(tái)WEB Server都禁用Servlet Session, 即每臺(tái)服務(wù)器都是無狀態(tài)的,單個(gè)Web Server失效后,不會(huì)發(fā)生用戶狀態(tài)丟失的問題。用戶狀態(tài)的跟蹤由中間層統(tǒng)一處理。
對移動(dòng)終端的支持
服務(wù)器對移動(dòng)終端的支持主要是通過HTTP協(xié)議提供json數(shù)據(jù)接口實(shí)現(xiàn)的,服務(wù)器基本采用了人人網(wǎng)共同的架構(gòu):
- HTTP WEB層做了更多的MVC抽象,除了提供基于html的Page View之外,還生成只提供json或者其他數(shù)據(jù)格式的Feed View。
- 服務(wù)器通過gzip壓縮減少流量,節(jié)省用戶資費(fèi)。
- 客戶端構(gòu)建REST風(fēng)格的HTTP請求,WEB服務(wù)器下發(fā)數(shù)據(jù)完成遠(yuǎn)程調(diào)用。
3G的API層直接面向移動(dòng)終端,提供基于HTTP和其他Socket協(xié)議的服務(wù)器訪問接口,并在業(yè)務(wù)層抽象出3G部門自己的公共平臺(tái),如圖4所示:
圖7 3G API架構(gòu)
除此之外,針對移動(dòng)終端的特點(diǎn)和中國特色的移動(dòng)互聯(lián)網(wǎng)環(huán)境,做了一些特殊的工作:
- 低端機(jī)型運(yùn)算能力和內(nèi)存資源都有限,API平臺(tái)做了相應(yīng)優(yōu)化
- 復(fù)雜的運(yùn)算服務(wù)器完成,減少移動(dòng)終端負(fù)載。如圖片的縮放、裁剪運(yùn)算、圖片質(zhì)量就是服務(wù)器進(jìn)行的。
- 客戶端和服務(wù)器進(jìn)行的數(shù)據(jù)輸入輸出盡量減小,這樣可以節(jié)省內(nèi)存存儲(chǔ)。在表示相同數(shù)據(jù)的情況下,盡量采用數(shù)據(jù)量小且易于解析的格式。API平臺(tái)使用了JSON,沒有使用XML
- 為了減少用戶資費(fèi),傳輸流量進(jìn)行了控制
- nginx開啟gzip壓縮,減少網(wǎng)絡(luò)傳輸流量。
- 中國移動(dòng)的cmwap網(wǎng)關(guān)會(huì)自動(dòng)對服務(wù)器輸出的gzip流進(jìn)行解壓縮,從而使nginx的zip壓縮失去了意義。這種情況下,api服務(wù)器對輸出進(jìn)行g(shù)zip壓縮后,作為普通二進(jìn)制流進(jìn)行響應(yīng)輸出。
- 除了純文本的json之外,api服務(wù)器也支持基于google protocol buffers格式的輸出,從而提供更緊湊的格式輸出。
- 提高客戶端訪問速度
- Api平臺(tái)支持基于邏輯時(shí)序的批處理操作,將多個(gè)api的網(wǎng)絡(luò)接口調(diào)用合并為一個(gè),減少多次tcp握手造成的巨大時(shí)間損耗,提高客戶端每個(gè)UI界面的響應(yīng)和顯示速度。