人人網工程師談移動Web開發架構
我們曾對人人網黃晶進行過專訪，本文為人人網三位工程師、產品經理對人人網移動開發架構的講解，從移動終端發展和未來移動終端趨勢、移動終端之江山一統、高可靠性和可擴展的服務和對移動終端的支持等方面對整個移動開發架構的認識。
移動終端發展和未來移動終端趨勢
說起手機操作平臺的發展先要說移動終端的發展，因為平臺的發展離不開移動終端，近十年移動終端發展和未來移動終端趨勢大體可分為以下四個階段：
第一個階段：功能終端。滿足用戶基本通信需求，如發短信、打電話，附加些貪食蛇、推箱子小游戲。
第二個階段：智能化的終端。可擴展第三方應用，實現上網瀏覽等互聯網基礎功能，以諾基亞S60手機為代表的。
第三個階段：互聯網和平臺化的終端。手機和互聯網更加緊密，瀏覽器、流媒體更加強大，互聯網應用和手機系統特性結合的更加緊密；手機成為了一個平臺，用戶可以通過下載第三方應用來DIY這款終端，如偏好音樂，可以下載音樂類型的應用。代表為iPhone、Android和Windows Phone 7。
第四個階段（未來趨勢）：物聯網化的智能終端。此階段的特點是現實生活和網絡通過傳感設備結合的更加緊密。
目前我們處于第三個階段，對用戶而言，由于收入不同、興趣愛好不同、需求偏好的不同以及手機私人屬性和隨身性的特點，產生了不同的用戶體驗；對各個廠商而言，由于目標市場的定位不同、商業利益的不同、技術背景不同，造就了不同的手機操作系統。最終形成了手機操作平臺多元化的局面。
目前主流手機操作平臺可分為：Symbian、Android、iOS 、MTK、Windows mobile、Windows Phone 7六種。下面分別簡述下這六個平臺的情況。
Symbian：昔日王者，雖然眼下受到了android和iPhone的強勢狙擊，被其瓜分了部分市場，但是價格低，易用性強，應用程序多，加上諾基亞的品牌、渠道等優勢，在短期內智能機霸主地位很難撼動。中期來看市場中心下移走中低端智能機路線，長期來看，有可能被Windows Phone 7取代。如果它不革自己的命，那么很可能被別人革命。
Android：勢如破竹，據國外媒體報道Android在去年第四季度已超過Symbian成為全球最大智能手機平臺，結束了在Symbian在智能機領域長達10年的統治地位。作為后來者，Android借鑒了iPhone的操作體驗，但是由于Android完全開源，對于手機廠商和運營商來講，很容易定制成自己特色和服務的手機，加上Android強大的互聯網功能，因而獲得二者的青睞。完全開源是把雙刃劍，由于各廠商分別定義了各自的產品，這種不標準和不統一會給第三方軟件適配帶來門檻，會導致在單個某型號的移動終端Android應用偏少，所以Android有可能成為智能手機中的山寨機。
iOS：神話締造者，從熱銷的程度我們可以看出iPhone 4創造的奇跡。超炫的UI設計，良好的交互操作，海量的應用，牢牢占領高端市場。從短期來看，iPhone 4突出的優勢會讓它再火一段時間。但是由于是自有系統，市場占有量取決于蘋果手機終端用戶認可情況，所以長期看，主要取決于蘋果手機發展和競爭對手的變化。
Windows mobile：廉頗老矣，尚能飯否？無論從UI視覺效果，還是從易用性，還是第三方應用，Windows mobile 都完敗Iphone和Android。壯士暮年，該退隱江湖了。
MTK：山寨大王， MTK是一個封閉的環境，不支持可擴展的應用，同時原功能也不完善，總之是個半成品。需要中間廠商來完善。相比較來講，第三方程序少，易用性一般。山寨機的價格和功能形成的性價比優勢，占據低端市場。
Windows Phone 7：救世主，作為微軟和諾基亞的救命稻草是值得期待的，筆者曾經體驗過Windows Phone 7，采用卷軸式UI設計風格，使UI體驗別具一格。系統和互聯網應用的緊密結合，加上諾基亞和微軟的強力支持。這個操作系統是值得期待的，有望在智能機領域形成Windows Phone 7、Android、iPhone三足鼎立的局面。
上述六大平臺分別對應不同的體驗和功能實現。對產品設計人員和開發人員而言，它們通常會參照移動終端的UI設計規范。因為移動終端系統本身定義了一些常用的控件和響應方式。產品保持與終端系統的一致，不但可以降低開發成本，而且易于用戶學習和使用。面對諸多平臺，尤其是各個平臺功能特點不盡相同，操作方式不同，屏幕大小不同，而每個主流平臺又有相當規模的用戶群，擁有眾多不同的UI規范，這對于全平臺的產品而言，無疑是具有災難性的。
本文就人人網移動開發中不同終端平臺的差異和架構統一問題，以及相關服務器架構進行探討。#p#
移動終端之江山一統
歷史歷歷在目
人人網www.renren.com（原名:校內網），從08年下半年開始手機軟件的研發，當時國內一二線的互聯網公司也已經開始了移動互聯網的布局，但已發布并可供參考的產品并不多，尤其是SNS本身也還是一個新的互聯業務，讓我們的用戶可以在手機上方便地訪問SNS，這可一下把我們難住了。為了可以快速推出第一個版本試水，我們先是選擇Java ME平臺來開發第一個人人的手機客戶端。
人人網的主要業務包括新鮮事，個人主頁（狀態，日志，相冊，留言），好友，站內信，聊天，游戲等等，這些業務都互相關聯與襯托，并圍繞好友關系（Social Graph），如果要把這些業務都搬到手機，短時間內根本無法完成，因為客戶端類的軟件與瀏覽器的網頁在展現與交互上有非常大的差異，手機的屏幕大小限制也給設計帶來了很大的困難，無疑是雪上加霜。當時我們挑選了用戶常用的幾個業務，新鮮事，個人主頁（狀態，日志，相冊，留言），好友，站內信，按主站頂部導航的排版方式，設計了一多標簽的導航界面，每個標簽一個業務，頁面跳轉同主站，如下圖：
圖1
看上去這個設計非常簡約明到幾乎完美，代碼也非常好實現，大家激情澎湃，斗志昂揚準備迎接移動互聯網的又一個奇跡，也許你和我以及我們的產品經理一樣，低估了這一切，人人網的業務可不像聊天軟件那樣單純，當我們的工程師各自完成自己的分配到的業務，并開始處理不同業務之間界面的跳轉時，不詳的預感籠罩了整個團隊，當時的輕率導致了嚴重危機，大家知道，在我們通過瀏覽器訪問網頁，頁面中超鏈接可以讓你隨意跳轉到任何一個頁面，且這些頁面并不一定是同一個業務的相關頁面，如我從個人主頁也可以直接跳轉到好友（跨標簽），而且通過瀏覽器的后退按鈕可以返回前面的頁面，客戶端類軟件可不能做成這樣的自由，我們應該怎么處理不同業務界面的跳轉呢？當時大家理解的跳轉，根本沒有考慮到不同業務之間后退的問題，而且瀏覽器的頁面跳轉，瀏覽器本身是不用知道下個界面是哪個業務，而客戶端必須知道，否則根本無法處理事件交互。技術慌了，產品經理也慌了，眼看承諾的交付時間一天天臨近，大家還是沒有想出一個非常好的辦法，多次嘗試失敗，有的方案，頁面的跳轉連我們自己都暈過去了，最后我們的第一個版本的JavaME 客戶端１.０以失敗告終。
首戰不利，大家心里都不是滋味，雖然通過后幾個月的努力，最后我們決定將１.２版本的客戶端以beta 版本的形式發布，并公開提供了下載，除了拍照上傳這個功能讓我們值得高興一下之外，其它功能也許只是讓我們感覺能用而已。JavaME的失利讓我們從自負中清醒，驕兵必敗。經過一段時間的討論與分析，大家一致認為，我們需要一個手機瀏覽器，人人的業務不論在PC端還是手機端，最理想的展現方式還是瀏覽器，于是我們開始手機瀏覽器研發道路，我們花了３-4個月的時間，開發出了我們第一個基于JavaME的瀏覽器引擎，代號：Across（為什么起這個名，后面說）。瀏覽器引擎架構參考Webkit，如下圖：
圖2 Across瀏覽器結構圖
上圖中藍色部分是我們引擎的實現部分，紅色的JS,CSS及Plug-in是未來的計劃，從技術角度看來，這個架構看上去非常的美，模塊功能劃分清晰且擴展性強，我們只要重寫Render Engine可以把一個普通的頁面渲染成我們想要的任何效果，遺憾的是最終我們還是沒有把瀏覽器這個解決方案應用到正式發布的人人客戶端版本，原因很簡單，它還不是很完善。我們預先做了大量的測試用例，在完成開發以后，我們按測試用例逐條進行了測試，最終結論雖然在性能和xhtml標簽支持上達到了我們的預期，但穩定性和包體積卻并沒有達到理想的狀態：運行時內存消耗在xhtml頁面大小的8-10倍左右，如一個30K的xhtml頁面完成解析，渲染必須保證有300K左右的空閑內存，如果渲染多個頁面或頻繁渲染新的頁面，就很容易出現崩潰（后來我們發現代碼中還有存在一些內存泄漏的地方）；另外，打包以后200k的體積對于JavaME手機來說已經大了。09年上半年，Android發布了1.5的SDK,iPhone入華的消息也是傳得到處都是，顯然，在這樣的行業形勢下，公司管理層已經對我們在JavaME上做瀏覽器引擎的計劃失去興趣，我們的工程師被重新安排了新的任務，Across沒有見到用戶就成了歷史，瀏覽器沒有救得了我們。
痛苦中反思
09年上半年是我們最痛苦的一段時間，折騰了大半個年頭，結果我們沒有發布一個值得驕傲的產品，市場卻快速變化著，iPhone，Android帶著閃耀的光芒進入了大家的視野，我們也不得不做出調整，開始分兵投入iPhone及Android的陣營。我們開始反省前面的失敗，我們似乎走了兩個極端，第一次在考慮產品及技術的架構時過于的簡單草率，以致后期面臨強大的心理壓力，第二次卻是一個典型的過度設計案例，雖然從技術角度看這是一個非常有挑戰且非常有意思的項目，當時我們的設想是先完成JavaME平臺的瀏覽器，然后移植Symbian等其它平臺，統一架構。但是移動互聯網市場近幾年的急速變化，不論從人力和時間上都不允許我們再把瀏覽器項目繼續下去。
為什么我們要統一架構？
人人網的業務種類非常多，而且PC端都基于瀏覽器網頁的模式，不論內容還是排版都經常需要優化變更，如果我們通過純客戶端的形式把全部現有業務遷移到到手機端，那么，當我們完成第５個業務的遷移時，可以前兩個業務主站已經發生了變更，或者客戶端剛剛上線之前的某個業務已經需要兼容運行了，在這種情況下，要么我們能快速迭代客戶端版本，趕上主站的業務的迭代速度，要么我們使用瀏覽器或類似瀏覽器的模式，所有業務放在服務器做，這就是我們為什么考慮開發Across，名字意在橫跨所有手機終端平臺。
真的可以統一架構嗎？
可以，瀏覽器本身就是一個非常優秀的跨平臺解決方案，但這個方案的前期投入非常大，且項目執行風險過高，人人網的業務大都是基本動態網頁實現，使用了大量的AJAX及Flash技術，最終我們放棄了瀏覽器方案，我們要的統一架構肯定不是這個。
山窮水盡,柳暗花明
放棄了瀏覽器的方案，我們可謂山窮水盡，難道還有第三個方案？Facebook的iPhone應用給了我們很大靈感，看圖：
圖3
從產品的角度看，這個圖顯示的布局與我們第一次嘗試的設計沒什么區別，深入一點我們會發現，這個設計與之前的設計最大區別在于頁面跳轉，每個標簽都有獨立的一個視圖棧，理論上無限大，通過當前棧頂視圖可以打開新的視圖后自動壓棧保存，當前視圖如果要后退默認退回視圖棧里保存的上一個視圖的內容。那如果是標簽１的頁面需要跳轉到標簽２對應的頁面怎么辦呢，是否自動切標簽？答案是不切，標簽只是用于業務導航，且有獨立的視圖棧，視圖棧中的頁面可以與業務無關，打個很好理解的比方：當我們在使用Chrome的瀏覽器時，我們同時在多個標簽分別打開多個不同網站或頁面，也可以打開同樣的網站或頁面，每個標簽都有一個獨立的后退的記錄，這種設計非常有規律，用戶容易理解不容易暈，現在頁面跳轉及后退的問題很好的解決了。不論JavaME，還是iPhone或者Android的客戶端，我們都使用了同樣的設計。
數風流人物，還看今朝
當我們客戶端都使用了這種標簽+視圖棧的方案以后，我們的各平臺在設計上基本達到了統一，并在現有設計上快速迭代演進。大家可能想了，在代碼層統一這才叫本事，也許你沒錯，但是我們不會輕意再做這樣高風險的嘗試，如今手機平臺的差異相當的大，就從主流平臺的開發語言看就夠你折騰了，JavaME及Android是使用的Java , iPhone使用的是 Objective-C，Symbian是純C++, 現在諾基亞與微軟聯姻Windows Phone 7，可Windows Phone 7將不再支持C/C++的開發，主推C# + Silverlight，好吧，我們只能再觀察一下了。
在接下來的一到兩年，移動互聯網將以前所未有的速度發展，大部分互聯網公司都開始了或已經推出了較成熟的移動終端的解決方案，創業公司也會層出不窮，推出各種優秀的移動終端應用：移動支付，LBS，基本通訊簿的即時通信，手機音樂，手機視頻，手機閱讀等等，iPad點燃平板電腦的硝煙，平板的設計再次給了我們很大的挑戰，數風流人物，還看今朝。#p#
高可靠性和可擴展的服務
現在移動互聯網拼的都是服務，客戶端良好的用戶體驗背后，都有強大的服務器技術支撐，人人網也不外如是。
業務層次模型
人人網采用JavaEE技術作為主要的業務解決方案，基本按照通用的JavaEE模型進行架構設計，如下圖：
圖4 人人網業務層次模型
◆WEB層基于REST風格和MVC設計模式，為用戶提供基于WEB的訪問接口
人人網采用的是自己開發的WEB框架 Rose，該框架基于Spring Framework，類似RoR框架，增強了對Controller編碼部分的默認約定和REST風格URL的支持，該項目前已開源，下載地址為http://code.google.com/p/paoding-rose/
業務層封裝業務邏輯，為WEB層提供業務接口，操作數據訪問層提供的數據。
人人網開發了自己的SOA框架XOA以支持業務層抽象，該框架結合Rose框架，以REST風格對業務進行分類、消息格式封裝和路由，如以下URL：
- xoa://blog.xoa.renren.com/photo/{user-id}/{photo-id}
該URL代表某用戶的某個照片，操作 GET/PUT/POST/DELETE分別對應對應照片資源的讀、修改、新增、刪除。即通過資源+操作的方式對外提供Service。
XOA支持遠程調用，并可以通過簡單添加服務器的方式進行橫向擴展。該框架目前準備開源，敬請關注。
◆數據訪問層提供對數據庫訪問的封裝
人人網使用Java語言開發了自己的Object-Relation Mapping框架JADE（Java Database Engine），并支持數據庫的水平橫向切分。該框架和Rose框架一體開源，下載地址相同。
◆數據持久層數據的持久存儲，主要采用MySQL數據庫，并且開發了自己的海量存儲系統Nuclear。
Rose、Jade、XOA作為集成度很高的一整套解決方案，在人人網大量采用，大大降低了開發成本，并在框架級解決了服務于企業解決方案的JavaEE技術在互聯網領域的適用性。
可擴展的高性能系統
人人網每天都要承受億級PV海量用戶的并發壓力，和其它大型互聯網站點類似，服務器架構方面做了很多工作。
高性能數據存儲系統
在數據存儲方面，人人網做了以下工作：
和其它互聯網大型站點相同，MySQL數據庫做水平拆分以支持橫向擴展
人人網作為國內第一大SNS網站，欲存海量UGC數據，必有海量存儲系統。Nuclear存儲系統在高性能、高可靠、可擴展的海量數據存儲需求下橫空出世。
Nuclear本身的數據存儲基于Key-Value形式，底層可以使用MySQL/Memory, Cassandra, TC, Redis等存儲引擎，提供弱結構化的查詢功能。
◆高擴展性
一個Nuclear集群支持1到n(n<264)個節點(Node)的規模
◆高可靠性
單個節點的crash永遠對系統的運行造成影響，不存在單點風險。系統永遠可寫入。
◆高性能
在4個節點、一般服務器配置情況下有測試數據表明單節點訪問可達15862 req/s, 平均單次請求耗時僅5ms。
本文不欲詳細介紹Nuclear, 有興趣的讀者請參考我們的技術站點。
可擴展的高性能業務服務系統
人人網的業務層是支持分布式、可橫向擴展的。
人人網主要使用JavaEE架構進行業務開發，其中Spring提供的IoC和AOP功能分別起到了業務對象裝配和橫向關注點分離的良好抽象。XOA框架基于Spring和netty，使用google的spdy協議作為網絡傳輸協議，除享受到Spring紅利之外，也提供了基于Java NIO的網絡高性能服務器環境。單個XOA服務是無狀態的，具有冪等性，XOA客戶端使用Java NIO、通過Keep alive保持對各個后臺服務器的TCP長連接，可實時監測后臺服務器的健康狀況，并把用戶請求負載分散到各個后臺服務器上，在單個節點失效的情況下不影響服務，如圖5所示：
圖5 XOA負載均衡
很多關鍵性的業務對性能要求特別高，也需要借助很多Linux操作系統的特性，這時Java的優化已經不能滿足需求，需要使用 C++語言進行開發。人人網采用ICE框架，進行這部分業務的開發，它解決了Java、C++等多種語言開發的框架和通訊問題。人人網目前使用ICE進行開發的業務層稱之為中間層，主要解決類似搜索、用戶好友關系計算等性能要求苛刻的底層關鍵性業務問題。其運維模式和XOA類似。
和其它大型網站一樣，業務層使用Memcached作為業務層的分布式數據緩存，且根據業務將緩存集群劃分為多個池，集中進行管理，如圖6所示：
圖6 Memcached Pool
在WEB層，使用目前性能最高的Servlet容器產品Resin作為HTTP Server，使用自行開發的Java WEB MVC框架Rose對用戶請求請求分發。負載均衡方面使用了F5或者nginx。為了減少Session復制同步的開銷，每臺WEB Server都禁用Servlet Session, 即每臺服務器都是無狀態的，單個Web Server失效后，不會發生用戶狀態丟失的問題。用戶狀態的跟蹤由中間層統一處理。#p#
對移動終端的支持
服務器對移動終端的支持主要是通過HTTP協議提供json數據接口實現的，服務器基本采用了人人網共同的架構：
◆HTTP WEB層做了更多的MVC抽象，除了提供基于html的Page View之外，還生成只提供json或者其他數據格式的Feed View。
◆服務器通過gzip壓縮減少流量，節省用戶資費。
◆客戶端構建REST風格的HTTP請求，WEB服務器下發數據完成遠程調用。
3G的API層直接面向移動終端，提供基于HTTP和其他Socket協議的服務器訪問接口，并在業務層抽象出3G部門自己的公共平臺，如圖7所示：
圖7 3G API架構
除此之外，針對移動終端的特點和中國特色的移動互聯網環境，做了一些特殊的工作：
◆低端機型運算能力和內存資源都有限，API平臺做了相應優化
復雜的運算服務器完成，減少移動終端負載。如圖片的縮放、裁剪運算、圖片質量就是服務器進行的。
客戶端和服務器進行的數據輸入輸出盡量減小，這樣可以節省內存存儲。在表示相同數據的情況下，盡量采用數據量小且易于解析的格式。API平臺使用了JSON，沒有使用XML
◆為了減少用戶資費，傳輸流量進行了控制
nginx開啟gzip壓縮，減少網絡傳輸流量。
中國移動的cmwap網關會自動對服務器輸出的gzip流進行解壓縮，從而使nginx的zip壓縮失去了意義。這種情況下，api服務器對輸出進行gzip壓縮后，作為普通二進制流進行響應輸出。
除了純文本的json之外，api服務器也支持基于google protocol buffers格式的輸出，從而提供更緊湊的格式輸出。
◆提高客戶端訪問速度
Api平臺支持基于邏輯時序的批處理操作，將多個api的網絡接口調用合并為一個，減少多次tcp握手造成的巨大時間損耗，提高客戶端每個UI界面的響應和顯示速度。
作者簡介
閆志東，人人網3G事業部高級技術經理，資深工程師，人人網技術委員會委員，目前負責人人網3G部門服務器架構方面的工作，他在基于C++、Java的服務器技術和架構方面擁有多年經驗。
聞華強，人人網3G事業部高級技術經理，資深工程師，是人人網3G部門客戶端技術負責人，他有長達七年的移動終端開發和管理經驗。
馬小東，人人網3G事業部產品經理，在移動互聯網業界浸淫七年，對很多產品大趨勢的把握和細節設計有非常獨到的看法。
【編輯推薦】
