1. 程式人生 > >攜程移動App架構優化之旅

攜程移動App架構優化之旅

    本文為攜程移動開發總監陳浩然在2015年10月份的ArchSummit全球架構師峰會上的演講總結。由於面向受眾為架構師,因此不會涉及到很多技術細節。通過本文,你可以瞭解攜程通過哪些手段來優化它的App架構的。

    『攜程旅行App』作為攜程超級App產品,是公司全品類旅行產品的核心售賣入口,過去兩年為了更好支撐無線業務的快速發展,攜程移動App在產品和技術架構方面也做了大量的優化。

產品

    產品方面,攜程App從原先的iPhone、iPad、Android Phone、Android Pad和Windows Phone共五個版本精簡為Universial iOS和Universial Android兩個版本,以便於集中研發和市場資源釋出新產品。

無線後端服務架構

    無線後端服務架構方面,原有的無線架構(圖一)是所有無線服務耦合成一個統一的服務模組,囊括了所有提供給客戶端訪問的API。


(圖一)

    在統一服務模組功能較少的時候,這套架構完全符合業務功能需求,但當功能迭代加快,問題不斷出現:

  • 每個API都是DLL動態庫形式(.net)實現,在某些公共邏輯介面發生變化時,不同時期上線的API可能使用了不同版本的邏輯介面定義,會導致執行時出現詭異結果或者程序Crash,影響穩定性;

  • 每次大版本釋出上線,從測試到全面釋出完畢,都需要全量回歸測試過程,開發和測試進度嚴重耦合,影響釋出效率;

  • 新增的低優先順序API可能穩定性不好,出現問題時會影響到整個服務程序的穩定性。

    除了這種完全耦合的弊端之外,還存在其他諸如缺少負載均衡、越少監控、缺少熔斷等影響後端穩定性的問題。於是我們開始嘗試使用一種新的無線架構:Gateway(圖二)。


(圖二)

    攜程基於Netflix的開源專案Zuul開發了無線Gateway(曾在2015年QCon上海會議中分享)。Gateway的職能是負責接收來自無線端的所有API請求,並將他們路由到正確的目標應用伺服器,並且提供限流、隔離、熔斷等功能,保證了無線服務的長期穩定執行,擁有的彈性容錯機制也減少了日常運維工作。同時該Gateway提供了多維度的監控資料,並與報警系統對接,實時監控線上情況,達到運維自動化。

App工程架構

    App工程架構方面,原先的App開發還是單工程單構建的方式,各產品間的程式碼耦合嚴重,於是進行了App工程的解耦(圖三和圖四)。


(圖三)


(圖四)

    解耦後各產品間程式碼完全獨立,相互頁面和功能的跳轉走資料匯流排或者URL匯流排方式來實現,打包時的資源問題可以通過Run Script(iOS)和Gradle(Android)來定製化解決。

在App工程架構解耦後,緊接著是兩個問題:

  • 開發框架是否滿足產品開發需求?

  • 效能和質量是否達到使用者體驗要求?

    為了解決第一個問題,我們梳理了現有的App功能,將通訊、定位、Hybrid框架、資料庫、登入、分享、基礎庫等核心功能實現了SDK化,也提供給公司其他App直接使用;同時將App內部的公共業務元件例如地圖、日曆、城市、圖片、通訊錄等實現了統一。

    要解決第二個問題『App效能和質量』,首先需要了解App效能的現狀,即App端效能的採集。常規做法有兩種:1. 使用第三方效能採集SDK,例如OneAPM、聽雲等第三方工具;2. 自建。攜程為了完整掌握使用者資料採用了自建的方式:App通過日誌SDK採集日誌,上傳至日誌服務端,日誌訊息經Kafka訊息佇列存入HDFS(RCFile格式)分散式檔案儲存系統,後期的資料查詢均基於Hive系統來實現。

    App端的效能資料會在多種緯度(作業系統、App版本、網路狀況、位置)下采集網路(網路服務成功率、平均耗時、耗時分佈等)、定位(經緯度成功率、城市定位成功率等)、啟動時間、記憶體流量等各類指標。其中像網路服務效能是對於使用者體驗至關重要的端到端效能,也是優化的核心依據。

    效能資料採集後需要採用簡單直觀的Portal進行展示,攜程為無線業務開發了Web端和App端效能展示Portal,圖五是網路效能的截圖,資料會每小時進行更新聚合並展示。


(圖五)

    基於完備的效能採集資料,很多App效能便可以依據資料進行迭代優化,例如App網路服務方面,攜程App採用了以下多種優化手段:

  • 使用TCP長連線實現網路服務,減少網路連線時間

  • 根據網路狀況2G/3G/4G/WIFI進行調優引數

  • 根據連線/讀/寫不同階段使用重試機制

  • 使用IP列表避免DNS解析失敗或者劫持,無需進行DNS解析

  • 根據網路延遲選擇服務端IP(使用Ping)

  • 使用ProtocolBuffer+Gzip減少Payload

    經過這些優化手段,攜程App的端到端網路服務成功率從最初很差的95.32%提升至99.87%,使用者體驗得到明顯提升。

    攜程App的Hybrid框架也是經過多個版本的迭代,已經支援強大的外掛功能,已經做到凡是可以用Native的元件通通使用Native元件來優化Hybrid業務的體驗。攜程Hybrid框架在設計之初即採用了離線包功能:Hybrid業務整體打包在App中,節省了使用者開啟頁面時的資源載入時間;同時離線包支援查分增量更新,並通過7z壓縮方式進一步降低了增量更新包的大小,相對zip壓縮減少30%大小。

Native的外掛化和HotFix

    Native的外掛化和HotFix方面,我們在iOS端使用開源的解決方案JSPatch,在Android端採用了自研的解決方案DynamicAPK,可以支援各元件的資源及程式碼的更新。DynamicAPK方案無需做任何activity/fragment/resource的proxy實現,使得原有的業務程式碼無需修改即可支援,遷移程式碼很小,同時可以提升App啟動時間,詳情請參考GitHub。

    其他優化都是針對特定的業務場景展開,例如Android的海外地圖沒有好的解決方案,iOS的地圖控制元件又存在人在國外看國外和人在國外看國內地圖資料精度低的問題,攜程基於Google地圖開發了Hybrid版地圖,用於在特定場景的業務需求;Hybrid網路效能優化,通過Hybrid介面傳送Native網路服務,可以避免DNS劫持並且利用Native端的TCP長連線;海外網路效能優化,通過TCP海外加速產品實現鏈路優化;圖片效能優化方面使用了WebP圖片格式,可以降低30-40%圖片大小,圖片分片上傳等。

    移動端技術發展很快,攜程也在積極嘗試新技術,例如React Native(已在賬戶資訊部分頁面使用),新的網路協議SPDYHTTP/2.0,Apple/Huawei/Samsung Watch App等都做了大量嘗試,以期能夠提升產品品質。

    總之,App架構的技術優化沒有盡頭,我們會繼續以開發效率、效能、質量、新技術幾個緯度不斷推進,希望未來可以有更多內容分享給業內同行。

轉自:移動開發前線