相關(guān)文章：人人網(wǎng)移動(dòng)開(kāi)發(fā)架構(gòu)（上）

真的可以統(tǒng)一架構(gòu)嗎？

可以，瀏覽器本身就是一個(gè)非常優(yōu)秀的跨平臺(tái)解決方案，但這個(gè)方案的前期投入非常大，且項(xiàng)目執(zhí)行風(fēng)險(xiǎn)過(guò)高，人人網(wǎng)的業(yè)務(wù)大都是基本動(dòng)態(tài)網(wǎng)頁(yè)實(shí)現(xiàn)，使用了大量的AJAX及Flash技術(shù)，最終我們放棄了瀏覽器方案，我們要的統(tǒng)一架構(gòu)肯定不是這個(gè)。

山窮水盡,柳暗花明

放棄了瀏覽器的方案，我們可謂山窮水盡，難道還有第三個(gè)方案？Facebook的iPhone應(yīng)用給了我們很大靈感，看圖：

圖３

從產(chǎn)品的角度看，這個(gè)圖顯示的布局與我們***次嘗試的設(shè)計(jì)沒(méi)什么區(qū)別，深入一點(diǎn)我們會(huì)發(fā)現(xiàn)，這個(gè)設(shè)計(jì)與之前的設(shè)計(jì)***區(qū)別在于頁(yè)面跳轉(zhuǎn)，每個(gè)標(biāo)簽都有獨(dú) 立的一個(gè)視圖棧，理論上無(wú)限大，通過(guò)當(dāng)前棧頂視圖可以打開(kāi)新的視圖后自動(dòng)壓棧保存，當(dāng)前視圖如果要后退默認(rèn)退回視圖棧里保存的上一個(gè)視圖的內(nèi)容。那如果是 標(biāo)簽１的頁(yè)面需要跳轉(zhuǎn)到標(biāo)簽２對(duì)應(yīng)的頁(yè)面怎么辦呢，是否自動(dòng)切標(biāo)簽？答案是不切，標(biāo)簽只是用于業(yè)務(wù)導(dǎo)航，且有獨(dú)立的視圖棧，視圖棧中的頁(yè)面可以與業(yè)務(wù)無(wú) 關(guān)，打個(gè)很好理解的比方：當(dāng)我們?cè)谑褂肅hrome的瀏覽器時(shí)，我們同時(shí)在多個(gè)標(biāo)簽分別打開(kāi)多個(gè)不同網(wǎng)站或頁(yè)面，也可以打開(kāi)同樣的網(wǎng)站或頁(yè)面，每個(gè)標(biāo)簽都 有一個(gè)獨(dú)立的后退的記錄，這種設(shè)計(jì)非常有規(guī)律，用戶容易理解不容易暈，現(xiàn)在頁(yè)面跳轉(zhuǎn)及后退的問(wè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)一這才 叫本事，也許你沒(méi)錯(cuò)，但是我們不會(huì)輕意再做這樣高風(fēng)險(xiǎn)的嘗試，如今手機(jī)平臺(tái)的差異相當(dāng)?shù)拇螅蛷闹髁髌脚_(tái)的開(kāi)發(fā)語(yǔ)言看就夠你折騰了，JavaME及 Android是使用的Java , iPhone使用的是 Objective-C，Symbian是純C++, 現(xiàn)在諾基亞與微軟聯(lián)姻WP7，可WP7將不再支持C/C++的開(kāi)發(fā)，主推C# + Silverlight，好吧，我們只能再觀察一下了。

在接下來(lái)的一到兩年，移動(dòng)互聯(lián)網(wǎng)將以***的速度發(fā)展，大部分互聯(lián)網(wǎng)公司都開(kāi)始了或已經(jīng)推出了較成熟的移動(dòng)終端的解決方案，創(chuàng)業(yè)公司也會(huì)層出不窮，推出各種優(yōu)秀的移動(dòng)終端應(yīng)用：移動(dòng)支付，LBS，基本通訊簿的即時(shí)通信，手機(jī)音樂(lè)，手機(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èn)接口人人網(wǎng)采用的是自己開(kāi)發(fā)的WEB框架 Rose，該框架基于Spring Framework，類似RoR框架，增強(qiáng)了對(duì)Controller編碼部分的默認(rèn)約定和REST風(fēng)格URL的支持，該項(xiàng)目前已開(kāi)源，下載地址為http://code.google.com/p/paoding-rose/
• 業(yè) 務(wù)層封裝業(yè)務(wù)邏輯，為WEB層提供業(yè)務(wù)接口，操作數(shù)據(jù)訪問(wèn)層提供的數(shù)據(jù)。人人網(wǎng)開(kāi)發(fā)了自己的SOA框架XOA以支持業(yè)務(wù)層抽象，該框架結(jié)合Rose框架， 以REST風(fēng)格對(duì)業(yè)務(wù)進(jìn)行分類、消息格式封裝和路由，如以下URL：xoa://blog.xoa.renren.com/photo/{user- id}/{photo-id}該URL代表某用戶的某個(gè)照片，操作 GET/PUT/POST/DELETE分別對(duì)應(yīng)對(duì)應(yīng)照片資源的讀、修改、新增、刪除。即通過(guò)資源+操作的方式對(duì)外提供Service。 XOA支持遠(yuǎn)程調(diào)用，并可以通過(guò)簡(jiǎn)單添加服務(wù)器的方式進(jìn)行橫向擴(kuò)展。該框架目前準(zhǔn)備開(kāi)源，敬請(qǐng)關(guān)注。
• 數(shù)據(jù)訪問(wèn)層提供對(duì)數(shù)據(jù)庫(kù)訪問(wèn)的封裝人人網(wǎng)使用Java語(yǔ)言開(kāi)發(fā)了自己的Object-Relation Mapping框架JADE（Java Database Engine），并支持?jǐn)?shù)據(jù)庫(kù)的水平橫向切分。該框架和Rose框架一體開(kāi)源，下載地址相同。
• 數(shù) 據(jù)持久層數(shù)據(jù)的持久存儲(chǔ)，主要采用MySQL數(shù)據(jù)庫(kù)，并且開(kāi)發(fā)了自己的海量存儲(chǔ)系統(tǒng)Nuclear。Rose、Jade、XOA作為集成度很高的一整套解 決方案，在人人網(wǎng)大量采用，大大降低了開(kāi)發(fā)成本，并在框架級(jí)解決了服務(wù)于企業(yè)解決方案的JavaEE技術(shù)在互聯(lián)網(wǎng)領(lǐng)域的適用性。

可擴(kuò)展的高性能系統(tǒng)

人人網(wǎng)每天都要承受億級(jí)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ù)庫(kù)做水平拆分以支持橫向擴(kuò)展
• 人人網(wǎng)作為國(guó)內(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)對(duì)系統(tǒng)的運(yùn)行造成影響，不存在單點(diǎn)風(fēng)險(xiǎn)。系統(tǒng)永遠(yuǎn)可寫入。
• 高性能在4個(gè)節(jié)點(diǎn)、一般服務(wù)器配置情況下有測(cè)試數(shù)據(jù)表明單節(jié)點(diǎn)訪問(wèn)可達(dá)15862 req/s, 平均單次請(qǐng)求耗時(shí)僅5ms。

可擴(kuò)展的高性能業(yè)務(wù)服務(wù)系統(tǒng)

人人網(wǎng)的業(yè)務(wù)層是支持分布式、可橫向擴(kuò)展的。

• 人人網(wǎng)主要使用JavaEE架構(gòu)進(jìn)行業(yè)務(wù)開(kāi)發(fā)，其中Spring提供的IoC和AOP功能分別起到了業(yè)務(wù)對(duì)象裝配和橫向關(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ù)是無(wú)狀態(tài)的，具有冪等性，XOA客戶端使用Java NIO、通過(guò)Keep alive保持對(duì)各個(gè)后臺(tái)服務(wù)器的TCP長(zhǎng)連接，可實(shí)時(shí)監(jiān)測(cè)后臺(tái)服務(wù)器的健康狀況，并把用戶請(qǐng)求負(fù)載分散到各個(gè)后臺(tái)服務(wù)器上，在單個(gè)節(jié)點(diǎn)失效的情況下不影 響服務(wù)，如圖5所示：

   

  

  圖5 XOA負(fù)載均衡

   

• 很多關(guān)鍵性的業(yè)務(wù)對(duì)性能要求特別高，也需要借助很多Linux操作系統(tǒng)的特性，這時(shí)Java的優(yōu)化已經(jīng)不能滿足需求，需要使用 C++語(yǔ)言進(jìn)行開(kāi)發(fā)。人人網(wǎng)采用ICE框架， 進(jìn)行這部分業(yè)務(wù)的開(kāi)發(fā)，它解決了Java、C++等多種語(yǔ)言開(kāi)發(fā)的框架和通訊問(wèn)題。人人網(wǎng)目前使用ICE進(jìn)行開(kāi)發(fā)的業(yè)務(wù)層稱之為中間層，主要解決類似搜 索、用戶好友關(guān)系計(jì)算等性能要求苛刻的底層關(guān)鍵性業(yè)務(wù)問(wèn)題。其運(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，使用自行開(kāi)發(fā)的Java WEB MVC框架Rose對(duì)用戶請(qǐng)求請(qǐng)求分發(fā)。負(fù)載均衡方面使用了F5或者nginx。為了減少Session復(fù)制同步的開(kāi)銷，每臺(tái)WEB Server都禁用Servlet Session, 即每臺(tái)服務(wù)器都是無(wú)狀態(tài)的，單個(gè)Web Server失效后，不會(huì)發(fā)生用戶狀態(tài)丟失的問(wèn)題。用戶狀態(tài)的跟蹤由中間層統(tǒng)一處理。

對(duì)移動(dòng)終端的支持

服務(wù)器對(duì)移動(dòng)終端的支持主要是通過(guò)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ù)器通過(guò)gzip壓縮減少流量，節(jié)省用戶資費(fèi)。
• 客戶端構(gòu)建REST風(fēng)格的HTTP請(qǐng)求，WEB服務(wù)器下發(fā)數(shù)據(jù)完成遠(yuǎn)程調(diào)用。

3G的API層直接面向移動(dòng)終端，提供基于HTTP和其他Socket協(xié)議的服務(wù)器訪問(wèn)接口，并在業(yè)務(wù)層抽象出3G部門自己的公共平臺(tái)，如圖4所示： 

圖7 3G API架構(gòu)

除此之外，針對(duì)移動(dòng)終端的特點(diǎn)和中國(guó)特色的移動(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，沒(méi)有使用XML
• 為了減少用戶資費(fèi)，傳輸流量進(jìn)行了控制
  • nginx開(kāi)啟gzip壓縮，減少網(wǎng)絡(luò)傳輸流量。
  • 中國(guó)移動(dòng)的cmwap網(wǎng)關(guān)會(huì)自動(dòng)對(duì)服務(wù)器輸出的gzip流進(jìn)行解壓縮，從而使nginx的zip壓縮失去了意義。這種情況下，api服務(wù)器對(duì)輸出進(jìn)行g(shù)zip壓縮后，作為普通二進(jìn)制流進(jìn)行響應(yīng)輸出。
  • 除了純文本的json之外，api服務(wù)器也支持基于google protocol buffers格式的輸出，從而提供更緊湊的格式輸出。
• 提高客戶端訪問(wèn)速度
  • Api平臺(tái)支持基于邏輯時(shí)序的批處理操作，將多個(gè)api的網(wǎng)絡(luò)接口調(diào)用合并為一個(gè)，減少多次tcp握手造成的巨大時(shí)間損耗，提高客戶端每個(gè)UI界面的響應(yīng)和顯示速度。