繼續當搬運工之人人網移動端架構解析

時間 2019-11-09

原文原文鏈接

人人網移動端架構解析

前言

提及手機操做平臺的發展先要說移動終端的發展，由於平臺的發展離不開移動終端，近十年移動終端發展和將來移動終端趨勢大致可分爲如下四個個階段： html

第一個階段：功能終端。知足用戶基本通訊需求，如發短信、打電話，附加些貪食蛇、推箱子小遊戲。 android

第二個階段：智能化的終端。可擴展第三方應用，實現上網瀏覽等互聯網基礎功能，以諾基亞S60手機爲表明的。 nginx

第三個階段：互聯網和平臺化的終端。手機和互聯網更加緊密，瀏覽器、流媒體更增強大，互聯網應用和手機系統特性結合的更加緊密；手機成爲了一個平臺，用戶能夠經過下載第三方應用來DIY這款終端，如偏好音樂，能夠下載音樂類型的應用。表明爲iPhone、Android和Windows Phone 7。數據庫

第四個階段（將來趨勢）：物聯網化的智能終端。此階段的特色是現實生活和網絡經過傳感設備結合的更加緊密。 json

目前咱們處於第三個階段，對用戶而言，因爲收入不一樣、興趣愛好不一樣、需求偏好的不一樣以及手機私人屬性和隨身性的特色，產生了不一樣的用戶體驗；對各個廠商而言，因爲目標市場的定位不一樣、商業利益的不一樣、技術背景不一樣，造就了不一樣的手機操做系統。最終造成了手機操做平臺多元化的局面。設計模式

目前主流手機操做平臺可分爲：Symbian、Android、iPhone OS 、MTK、Windows mobile、Wp7六種。下面分別簡述下這六個平臺的狀況。 api

Symbian：昔日王者，雖然眼下受到了android和iPhone的強勢狙擊，被其瓜分了部分市場，可是價格低，易用性強，應用程序多，加上諾基亞的品牌、渠道等優點，在短時間內智能機霸主地位很難撼動。中期來看市場中心下移走中低端智能機路線，長期來看，有可能被WP7取代。若是它不革本身的命，那麼極可能被別人革命。瀏覽器

Android：勢如破竹，據國外媒體報道Android在去年第四季度已超過Symbian成爲全球最大智能手機平臺，結束了在Symbian在智能機領域長達10年的統治地位。做爲後來者，Android借鑑了iPhone的操做體驗，可是因爲Android徹底開源，對於手機廠商和運營商來說，很容易定製成本身特點和服務的手機，加上Android強大的互聯網功能，於是得到兩者的青睞。徹底開源是把雙刃劍，因爲各廠商分別定義了各自的產品，這種不標準和不統一會給第三方軟件適配帶來門檻，會致使在單個某型號的移動終端Android應用偏少，因此Android有可能成爲智能手機中的山寨機。緩存

iPhone OS：神話締造者，從熱銷的程度咱們能夠看出iPhone 4創造的奇蹟。超炫的UI設計，良好的交互操做，海量的應用，緊緊佔領高端市場。從短時間來看，iPhone 4突出的優點會讓它再火一段時間。可是因爲是自有系統，市場佔有量取決於蘋果手機終端用戶承認狀況，因此長期看，主要取決於蘋果手機發展和競爭對手的變化。服務器

Windows mobile：廉頗老矣，尚能飯否？不管從UI視覺效果，仍是從易用性，仍是第三方應用，Windows mobile 都完敗Iphone和Android。壯士暮年，該退隱江湖了。

MTK：山寨大王， MTK是一個封閉的環境，不支持可擴展的應用，同時原功能也不完善，總之是個半成品。須要中間廠商來完善。相比較來說，第三方程序少，易用性通常。山寨機的價格和功能造成的性價比優點，佔據低端市場。

WP7：救世主，做爲微軟和諾基亞的救命稻草是值得期待的，筆者曾經體驗過WP7，採用卷軸式UI設計風格，使UI體驗別具一格。系統和互聯網應用的緊密結合，加上諾基亞和微軟的強力支持。這個操做系統是值得期待的，有望在智能機領域造成WP七、Android、iPhone三足鼎立的局面。

上述六大平臺分別對應不一樣的體驗和功能實現。對產品設計人員和開發人員而言，它們一般會參照移動終端的UI設計規範。由於移動終端系統自己定義了一些經常使用的控件和響應方式。產品保持與終端系統的一致，不但能夠下降開發成本，並且易於用戶學習和使用。面對諸多平臺，尤爲是各個平臺功能特色不盡相同，操做方式不一樣，屏幕大小不一樣，而每一個主流平臺又有至關規模的用戶羣，擁有衆多不一樣的UI規範，這對於全平臺的產品而言，無疑是具備災難性的。

本文就人人網移動開發中不一樣終端平臺的差別和架構統一問題，以及相關服務器架構進行探討。

移動終端之江山一統歷史歷歷在目

人人網www.renren.com（原名:校內網），從０８年下半年開始手機軟件的研發，當時國內一二線的互聯網公司也已經開始了移動互聯網的佈局，但已發佈並可供參考的產品並很少，尤爲是SNS自己也仍是一個新的互聯業務，讓咱們的用戶能夠在手機上方便地訪問SNS，這可一下把咱們難住了。爲了能夠快速推出第一個版本試水，咱們先是選擇JavaME平臺來開發第一我的人的手機客戶端。

人人網的主要業務包括新鮮事，我的主頁（狀態，日誌，相冊，留言），好友，站內信，聊天，遊戲等等，這些業務都互相關聯與陪襯，並圍繞好友關係（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應用給了咱們很大靈感，看圖：

圖３

從產品的角度看，這個圖顯示的佈局與咱們第一次嘗試的設計沒什麼區別，深刻一點咱們會發現，這個設計與以前的設計最大區別在於頁面跳轉，每一個標籤都有獨立的一個視圖棧，理論上無限大，經過當前棧頂視圖能夠打開新的視圖後自動壓棧保存，當前視圖若是要後退默認退回視圖棧裏保存的上一個視圖的內容。那若是是標籤１的頁面須要跳轉到標籤２對應的頁面怎麼辦呢，是否自動切標籤？答案是不切，標籤只是用於業務導航，且有獨立的視圖棧，視圖棧中的頁面能夠與業務無關，打個很好理解的比方：當咱們在使用Chrome的瀏覽器時，咱們同時在多個標籤分別打開多個不一樣網站或頁面，也能夠打開一樣的網站或頁面，每一個標籤都有一個獨立的後退的記錄，這種設計很是有規律，用戶容易理解不容易暈，如今頁面跳轉及後退的問題很好的解決了。不論JavaME，仍是iPhone或者Android的客戶端，咱們都使用了一樣的設計。

數風流人物，還看今朝

當咱們客戶端都使用了這種標籤+視圖棧的方案之後，咱們的各平臺在設計上基本達到了統一，並在現有設計上快速迭代演進。你們可能想了，在代碼層統一這才叫本事，也許你沒錯，可是咱們不會輕意再作這樣高風險的嘗試，現在手機平臺的差別至關的大，就從主流平臺的開發語言看就夠你折騰了，JavaME及Android是使用的Java , iPhone使用的是 Objective-C，Symbian是純C++, 如今諾基亞與微軟聯姻WP7，可WP7將再也不支持C/C++的開發，主推C# + Silverlight，好吧，咱們只能再觀察一下了。

在接下來的一到兩年，移動互聯網將之前所未有的速度發展，大部分互聯網公司都開始了或已經推出了較成熟的移動終端的解決方案，創業公司也會層出不窮，推出各類優秀的移動終端應用：移動支付，LBS，基本通信簿的即時通訊，手機音樂，手機視頻，手機閱讀等等，iPad點燃平板電腦的硝煙，平板的設計再次給了咱們很大的挑戰，數風流人物，還看今朝。

高可靠性和可擴展的服務

如今移動互聯網拼的都是服務，客戶端良好的用戶體驗背後，都有強大的服務器技術支撐，人人網也不外如是。

業務層次模型

人人網採用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失效後，不會發生用戶狀態丟失的問題。用戶狀態的跟蹤由中間層統一處理。

對移動終端的支持

服務器對移動終端的支持主要是經過HTTP協議提供json數據接口實現的，服務器基本採用了人人網共同的架構：

HTTP WEB層作了更多的MVC抽象，除了提供基於html的Page View以外，還生成只提供json或者其餘數據格式的Feed View。
服務器經過gzip壓縮減小流量，節省用戶資費。
客戶端構建REST風格的HTTP請求，WEB服務器下發數據完成遠程調用。

3G的API層直接面向移動終端，提供基於HTTP和其餘Socket協議的服務器訪問接口，並在業務層抽象出3G部門本身的公共平臺，如圖4所示：

圖7 3G API架構

除此以外，針對移動終端的特色和中國特點的移動互聯網環境，作了一些特殊的工做：

低端機型運算能力和內存資源都有限，API平臺作了相應優化
- 複雜的運算服務器完成，減小移動終端負載。如圖片的縮放、裁剪運算、圖片質量就是服務器進行的。
- 客戶端和服務器進行的數據輸入輸出儘可能減少，這樣能夠節省內存存儲。在表示相同數據的狀況下，儘可能採用數據量小且易於解析的格式。API平臺使用了JSON，沒有使用XML
爲了減小用戶資費，傳輸流量進行了控制
- nginx開啓gzip壓縮，減小網絡傳輸流量。
- 中國移動的cmwap網關會自動對服務器輸出的gzip流進行解壓縮，從而使nginx的zip壓縮失去了意義。這種狀況下，api服務器對輸出進行gzip壓縮後，做爲普通二進制流進行響應輸出。
- 除了純文本的json以外，api服務器也支持基於google protocol buffers格式的輸出，從而提供更緊湊的格式輸出。
提升客戶端訪問速度
- Api平臺支持基於邏輯時序的批處理操做，將多個api的網絡接口調用合併爲一個，減小屢次tcp握手形成的巨大時間損耗，提升客戶端每一個UI界面的響應和顯示速度。