移動互連網系統架構特點及實踐－－手機鳳凰網

    本文整理自：http://www.cnblogs.com/sunli/archive/2011/02/19/mobile_architecture.html

    今天參加了InfoQ組織的百度技術沙龍活動“移動互連網基礎技術解析——無線搜尋與HTML5開發”，在最後的Open Space環節主持了一個話題“移動互連網系統架構的特點”，現在把討論的一些重點給記錄一下。

    （一）並發性
    相對於有線互連網，移動互連網的網速還是窄帶時期，大部分的網路訪問都屬於慢速連線。一個請求佔用的網路連接的時間比有線互連網一個請求佔用網路連接的時間要長。在同等的伺服器端QPS下，並發串連數要比有線互連網模式的要高。雖然web伺服器的並發串連數問題非常容易通過增加機器來進行擴充，但是這個問題需要注意。盡量使用非同步網路IO。
    （二）流量
    相對於有線互連網的包月付費模式，移動互連網使用者基本都是有限的按流量的包月模式，流量費用昂貴。使用者會首選耗用流量低的系統使用，這正是UC瀏覽器成功的原因。
    所以在系統架構的時候，如果用戶端瀏覽器支援gzip，那麼盡量gzip壓縮內容。如果是app的用戶端程式，最好使用壓縮傳輸內容。
    web網頁內容盡量簡潔，url串連盡量壓縮，省略BaseUrl。
    （三）安全
    有線互連網的線上支付目前非常成熟，在支付的時候可以跳到銀行的網站或者用戶端進行支付，讓使用者覺得很安全。而移動互連網可能是服務端通過api支付，使用者也覺得不安全。這樣某些網站也有可能盜用使用者的錢。但是銀行通過簡訊認證即可解決這個問題。
    手機丟失帶來的財產損失問題，由於手機丟失，可能造成被人惡意支付。然後提出掛失的功能。來自飛信的朋友說，飛信可以推出直接進行手機號掛失，圓滿解決這個問題。
    （四）速度最佳化
    由於移動網路的速度慢，速度最佳化就更加要得到重視。比如js，css檔案的合并。
    app與伺服器端的互動是否使用自訂的協議進行提速。
    網路操作的失敗處理。
    （五）相容性
    移動互連網的終端類型，螢幕解析度，瀏覽器類型千變萬化。就算同一個手機的同一個瀏覽器也有適應螢幕模式和縮放模式。如此多的種類給頁面的相容開發帶來了很大的難度。往往公司的移動終端測試機器多達幾十種，雖然有廠商提供這種服務測試服務，但是對於開發人員來講，難度可不低。而有線互連網的網站之需要調試下IE,Firefox,chrome幾個瀏覽器即可。
    （六）與有線互連網統一
    很大部分網站都是以有線互連網為主，同時推出移動互連網版本的。但是往往移動版本的功能有縮減，導致某些功能缺失。所以從產品的角度也應該把功能進行統一。
    所以涉及到有線互連網、移動網站、app 用戶端的功能統一。
    （七）統計分析
    app用戶端軟體的使用者行為分析統計，可以進行定期往伺服器發送。用戶端把使用者的操作行為先收集起來，進行分析後把結果定期壓縮打包發送給伺服器。移動網站可以通過伺服器端記錄日誌，js探針（wap2.0的只能手機可能支援）等綜合的方式統計。
    （八）測試環境類比
     有人說,公司開發一款app用戶端軟體，在公司測試非常完美。等有一天，開發人員在火車上，地鐵上拿出手機使用的時候，發現在網路不穩定的時候頻繁崩潰。那麼這種情境如何進行類比測試？
    （九）使用者真實訪問速度的監控
    雖然目前有廠商進行移動網路對移動互連網進行速度監控和分析。但是他們的點基本都是固定的，可能是訊號較好的地方。那麼我們的應用的真實使用者訪問的速度到底是怎麼樣的，如何統計？
    根據應用的類型，有些應用可能在家，公司等有wifi ，訊號好的地方使用。而有些應用很多情況下在訊號差的地方使用，所以使用第三方的監控還不完全可靠。
    （十）需求變更更頻繁
    由於移動業務的特點，需求變更的即時性要求更高。如何快速，高效完成需求的變更，而又不影響系統效能？這給移動開發人員也提出了一些挑戰。難道就只能加班？

    總結：以上為今天討論的移動互連網架構相對於有線互連網的特點，其中大部分還是跟有線互連網是一樣的，比如資料庫結構描述，儲存的架構等等。

    下面整理自：http://www.cnblogs.com/sunli/archive/2010/12/20/imcp.html

    下面以手機鳳凰網為例來介紹移動互連網系統的架構實踐。

    我相信一個好的系統架構是需要從產品需求出發的，同時我也相信一個系統的效能最佳化也要站在產品需求之上，所以我花了很多時間從產品設計的角度來分析為什麼要設計內容平台，以及如何去設計這樣一個系統，這就是系統架構，最後才在這個系統架構基礎之上提出怎麼進行效能最佳化，滿足非功能性需求。
     作為開發人員，我經曆了固定互連網的一個高速發展時期。曾經，我們會頻繁的開發出不同的網站，比片展示的系統，新聞網站等等以內容為主的系統，為了提高開發效率，摒棄開發網站的複雜性，出現了CMS系統。比如中小型網站比較通用的CMS系統（php168，phpcms等）和門戶型CMS（定製化的大型CMS系統），CMS系統簡化了網站的開發的難度，而且不需要特別的技術，就能構建出高效能，穩定的網站。
     今年開始，移動GPRS資費的下調，3G網路的發展，智能手機的鋪天蓋地的流行，我們手機鳳凰網的流量出現了非常大的增長，據我瞭解，很多公司都出現了大量的流量增長（見PPT第三頁）。
     移動互連網的發展給程式員提出了更高的挑戰：
    1、多電訊廠商（電信，移動，聯通，wifi使用者），互訪速度跟固定互連網的網通電信南北互連一樣
    2、多終端（超級多的手機類型，螢幕，系統，瀏覽器），出現更多的適配問題（不像固定互連網只是IE6，IE7和firefox,chrome的相容）
    3、 需求多變（要求快），由於快速的開發，導致開發的系統過一段就效能低下，經常宕機，程式員的壓力很大，很大，很大。（ps:某某公司的無線技術人員已經死了兩個了）
    4、 訪問量節節飆升 ，需要系統具有更高的效能和可擴充性。
    5、頁面幾乎不能靜態化（適配，按用戶端等客戶資訊輸出不同的內容），固定互連網可以產生靜態html，使用cdn，來提高效能，由於不能靜態化，移動互連網對效能的要求就更高。
    手機鳳凰網的上一版本（WAPCMS）系統的架構使用了普通的JSP+Mysql+Linuxi架構。（PPT的第5,6頁）。通過Mysql的主從複製進行擴充，前端通過一個自行開發的反向 Proxy進行cache（融入了商務邏輯代碼）。由於頻繁的代碼更新，增加很多新的合作網站（jsp），代碼非常的難於維護，效能也非常低下。當時10多台機器才應付1000多萬pv/日，還會出現宕機。你可能會說，這個系統效能還可以最佳化，是的，還可以最佳化，效能非常低，但是由於要疲於應付提出的新的需求，就算最佳化了，沒過多久，就又會出現效能下降。所以我們需要一個系統，像facebook在會上提出的那樣，“如何讓網站一直都很快”，是的，要讓網站一直都很快，效能高，穩定，不管開發人員怎麼折騰，系統總是很快的，效能很高的，所以，我們開發了IMCP系統。
    IMCP（Ifeng Mobile Content Platform）不只是我們的wap網站的系統，還提供了鳳凰移動台，視頻用戶端，鳳凰新聞用戶端，支援活動直播，線上代碼開發，平均單機效能最高達到1800+萬pv/日。開發人員在我們的平台上，無需考慮效能問題，只需要簡單的調用系統提供的sdk的方法就能開發出高效能的網站。
    到ppt第9頁。為了儘可能設計出一個通用的系統平台，我們對網頁進行了拆分。我們認為，網頁都是由可拆分的塊組成的。這些塊包含可編輯的靜態html塊（手工編輯的），自動產生的列表（文章列表）塊，推薦位（由編輯手工選擇的列表），內容文檔塊。一般固定互連網的新聞網站都可以由這些塊組成，我們移動互連網由於是基於動態網頁面，所以我們還加入了邏輯塊，來控制所有的塊的邏輯。
    由於要開發人員要經常為一些合作網站，比如要為諾基亞開發一個跟主站類似的網站，只是某些內容不一樣的網站，一般都要拷貝一份代碼。所以我們又計劃把代碼拆分成邏輯塊進行重用，頁面也儘可能的重用，可以線上的建立網站，不需要營運部門的參與。所以就計劃把我們的代碼是儲存在nosql程式碼程式庫中，由NoSQL管理所有的代碼儲存，通過後台進行線上編輯。前台訪問的時候再去nosql取代碼進行運行。通過NOSQL的主從複製實現跨機器，跨機房的代碼自動部署。
    在這樣的模式下面，開發人員只需要在後台進行線上開發，不需要關心代碼運行在什麼IP的伺服器上，需要去串連什麼IP的儲存，資料庫，一切都是透明的，要取某個文章的內容，就直接getDoc(id)就可以了。
    ppt13-22頁進行了一些後台介面的示範
    ppt後面的內容都基本能看明白了，其中非常有意義的就是我們的前端完全基於nosql資料，這也算是nosql 的一個成功利用的案例吧，由於ppt比較清楚，我就不詳細闡述了。最後一頁的代碼運行效能監控我相信對很多朋友也有參考意義，通過對代碼運行狀態監控，可以即時的看到系統的相信運行效能狀態。
    這次velocity china 2010給我最大的感受就是，各個公司都有底層團隊在致力於協助開發人員簡化開發的複雜度，自動化的提高系統的效能，穩定性（讓開發人員不再關心這些問題）。我們的IMCP系統也是這樣，開發人員無需關心cache，無需關心效能，只要利用我們SDK提供的功能搭建系統，網站總是非常高效，而且開發速度還非常快。