移動互連網系統架構的特點

[文章作者：孫立 連結：http://www.cnblogs.com/sunli/ 更新時間：2011-2-19]  

      今天參加了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 ，訊號好的地方使用。而有些應用很多情況下在訊號差的地方使用，所以使用第三方的監控還不完全可靠。

       （十）需求變更更頻繁

       由於移動業務的特點，需求變更的即時性要求更高。如何快速，高效完成需求的變更，而又不影響系統效能?這給移動開發人員也提出了一些挑戰。難道就只能加班？

      總結

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