演講實錄——螞蟻金服mPaaS模塊化開發與架構重構深度解析 [復制鏈接]

2019-4-25 10:24
九霄逆鱗 閱讀:252 評論:0 贊:0
Tag:  

本文整理于螞蟻金服無線工程師王磊在 2019 安卓巴士開發者大會現場的分享《螞蟻金服 mPaaS 模塊化開發與架構重構深度解析》,通過“模塊化開發架構設計”作為切入口,聚焦 mPaaS 如何深度應用與實踐模塊化開發架構,以及在架構重構中遇到了哪些挑戰和具體解決思路。

0

內容概要

主要分為以下三個部分:

  1. 支付寶在移動端的架構演進與思考

  2. mPaaS 模塊化架構及能力

  3. 基于 mPaaS 架構的重構思考

1

支付寶在移動端的架構演進與思考

> 支付寶現狀

根據 2019 年移動互聯網最新的數據報告,目前支付寶全球總用戶數已超過 10 億人,月活用戶數超過 6.5 億,成為國內第二大 App。

在研發上面,支付寶的客戶端研發人員超過 300+,整體工程數同樣也是超過 300+,總體代碼超過 200 萬行,提供的服務超過 200+,并且整體的閃退率維持萬分之五以下,那么支付寶是如何保證在如此龐大的研發規模下,保證服務的告訴迭代,以及應用的整體穩定性的呢?

三個階段

支付寶做到今天,主要分為三個階段:

  1. 獨木舟階段

    支付寶剛開始推出的時候,和很多簡單的應用一樣,都是一個單體應用,除了一些簡單的公共組件被作為 lib 模塊,其他大部分業務代碼全部寫到一起。這種單工程的輕量結構,對于當時的支付寶來說,還算是可以滿足需求,但是隨著支付寶業務的迅速成長,問題開始暴露出來了,由于單工程,所有工程師代碼都要合到一起,并行開發變得異常艱難,同時,由于發布時間固定,各團隊匆忙合并代碼,很可能出現代碼覆蓋、污染的情況,從而導致穩定性無法保證。這種開發模式,我們稱之為「串行開發模式」。

  2. 戰列艦階段

    為了解決獨木舟階段我們存在的問題,在 13 年底,支付寶進行了一次徹底的重構,基于 OSGi 模塊化思想,推出了 Quinox 容器化框架。基于這套框架,支付寶完成了從單體應用到平臺型應用的轉變,從單工程「串行開發模式」變為了多工程「并行開發模式」。各工程之間只關注接口,不用在意實現細節,頁面間路由只需一個 id。代碼完全隔離,開發、發版效率有了明顯提升。因為基于框架提供的 pipeline 機制,業務治理變得非常方便,使得整體應用的啟動性能有了明顯的提升。

  3. 航空母艦階段

    時間來到了 15 年,在解決了協作效率、啟動性能等問題后,隨著移動支付的普及,業務的井噴,用戶對應用體驗要求的提高,彈性動態、高可用這兩個變為了這個階段的重點。為了解決這些問題,支付寶引入了 Nebula 容器、小程序、多維發布以及全鏈路的監控等組件,來保障轉型成為超級 App。


> 架構升級技術挑戰及解決方向

通過剛才我們簡要的回溯支付寶近些年的架構升級歷程,我們可以總結出,重構升級成超級 App,需要解決的幾大塊技術點:

  • 協同開發,業務解耦

  • 啟動性能調優,業務治理

  • 復雜業務動態化,多維發布

  • 保證高可用,數據全鏈路采集,多維度修復

1

mPaaS 模塊化架構及能力


帶著上面提出的四個技術問題,我們來先了解下 mPaaS 的整體架構圖。

整個客戶端架構總共分成四層:框架層組件層服務層業務層

  • 框架層:最關鍵的部分,整個模塊化的基礎。提供微應用、微服務、pipeline、切面、監控等服務。整體模塊化協同開發,都是基于框架層提供的能力,來達到「并行開發」的目的。

  • 組件層:這一層提供的是客戶端通用能力,如安全、網絡、多媒體、存儲這些,這些組件都是支付寶多年沉淀下來的經典組件,它們提供穩定的接口給上層使用者,作為客戶端的基石,它們至關重要。

  • 服務層:本層就是和支付寶相關的一些核心服務能力,我們將他們抽取出來,進行服務化,服務 App 本身,也服務各個生態業務。

  • 業務層:業務方和第三方服務提供者,只需專注于業務邏輯與界面的實現,調用整體框架提供的各種能力,最后通過整體應用的動態化能力進行多維發布。

通過 Quinox 框架、微服務、微應用,即可實現上面的架構分層,接下來我們將逐一介紹。

>  Quinox 框架

Quinox 客戶端框架是類 OSGi (like-as) 框架的實現。Quinox 一詞來源于著名的 OSGi 框架的實現 Equinox。

基于 mPaaS 的 App 研發,就像積木搭建(Bundle)一樣輕松,天生具有以下優勢:

  • 靈活性:模塊/組件可插拔,不影響編譯

  • 獨立性:模塊可由團隊或個人獨立維護

  • 復用性:模塊可被任意宿主程序所引用

  • 隔離性:接口和實現分離,微應用路由跳轉

> 微服務

mPaaS 框架提供微服務功能,該服務類似于 Android 原生的 Service,直接通過框架的方法,即可獲得服務的實現。這種設計模式本身核心是控制反轉,依賴注入的這種理念,減少各模塊間的依賴,初始化等復雜的工作,完成解耦。

作為使用者方,無需了解實現細節,只需要提供參數,調用服務提供的接口即可獲得服務。

作為開發者,只需要將服務接口注冊到框架上,框架在初始化后,會自動去生成服務,控制服務的生命周期。

> 微應用

mPaaS 框架提供微應用功能,微應用我們可以理解為 mPaaS 的路由。

作為使用方,通過唯一的 appId,進行不同微應用之間的調用,使用者并不需要引用對方的 activity,也無需關注對方內部的跳轉邏輯。

作為開發者,只需要將 appId 注冊到框架上,當有業務調到該 ID 后,后續的操作完全有開發者掌握,業務之間完全隔離解耦。

微應用的概念不僅適用于原生頁面,同樣也適用于H5和小程序。注冊為H5或者小程序類型的應用 ID,框架會自動將啟動過程delegate給H5或者小程序容器,而使用者完全不必關心應用 ID 對應的應用類型。

綜上所述,微應用和微服務可以使各個業務之間的耦合降到最低,大家都無需關注其他團隊的實現,代碼之間無侵染,這樣整體的協作研發效率也就隨之提升上來了。

> Pipeline 機制及啟動優化

上面的內容主要是講如何高效的進行協同開發,接下來該第二個技術點,也就是 mPaaS 是如何對框架的性能進行治理的。對于性能優化,mPaaS 框架主要從業務和技術兩個方面進行處理:

1. 技術優化:

  • mPaaS 通過黑科技,將啟動時的 JIT 關閉,從而有效降低因即時編譯導致的性能問題

  • 通過關閉啟動時的 GC,從而將啟動速度提升到最快,當啟動完成后,在進行一次較大的 GC。

  • 提供各種切面及監控能力,全方面監控啟動異常

2. 業務優化:

  • mPaaS 框架提供統一的啟動流程、線程池、并發工具類等,可以有效的使業務規范化

  • 并且,mPaaS 提供 pipeline 機制,可以根據業務優先級進行初始化調優,從而達到啟動優化的目的。

> 動態化

解決了上面兩個技術點,mPaaS 框架就已經具備成為戰列艦的能力了,接下來,我們看下如何更近一步,提供航空母艦的能力。

作為超級 App 的核心能力,就是如何構建生態。”快速起飛、降落,承載大量、不同的艦載機“是其要解決的核心問題。解決這個問題的關鍵就是框架的 Hybrid 能力,mPaaS 上面,采用了支付寶多年積累下來的 Hybrid 經驗,使用 Nebula 作為 H5 容器,同時承載 H5 離線包以及小程序。

1. H5 容器及離線包的特點:

  • 全面兼容主流 H5 框架,遷移成本低

  • 使用離線包技術,體驗接近原生,網絡請求走原生,高效安全。

  • 提供統一 UC 內核,性能及穩定性有保障

  • 離線包差量更新,節省流量

  • 提供容錯機制,下載失敗后走線上 fallback

  • 實時觸達客戶,通過推拉結合,下發離線包

H5 離線包作為動態化方案,有點多多,但是,其有一點不足就是無法管控質量,寬泛的前端規范讓服務管控變得異常困難,如果所有服務都是我們內部的業務還好說,如果開放給第三方,就需要有完整的規范來約束。這時,我們就要引入小程序來規范化服務,提供給第三方。

2. 小程序特點:

  • 統一的小程序架構,可在任意基于 mPaaS 架構開發的應用上進行投放

  • 強大的 Web 渲染引擎

  • 提供豐富組件,快速實現業務

  • 整合離線包技術,可以復用 H5 插件

  • 完善的生命周期管理

當我們解決完動態化的技術點后,應用將會有以下四點優化:

  • 包尺寸有效減少,節省流量和存儲。

  • 服務不再受發版所限制,快速發布,快速迭代。

  • 業務開發效率更加優秀,一次開發,多端運行。

  • 應用升級為平臺,提供優質服務并按需加載。

> 多維發布

作為一套完整的動態化方案,光有容器其實是不夠的,我們還需要有多維觸達用戶的手段,將各種服務發布給用戶,接下來,我們就聊聊 mPaaS 多維發布都具備哪些能力。

通過 mPaaS 發布平臺,我們可以輕松地將我們的 App 新版本、H5 離線包、小程序包、熱修復包以及開關配置進行下發。

同時發布平臺提供了正式發布和灰度發布,通過灰度發布,我們可以有效的驗證待發布的內容,檢查是否有潛在的風險,若灰度發布時出了問題,可進行及時回滾,減少覆蓋面,有效的降低了正式發布的風險。

另外發布平臺還提供不同的緯度,包括白名單、機型、城市、系統版本等,這些緯度可以使發布可以更具有針對性。

> 運維體系

上面解決了協同開發、性能優化、動態化等技術點,最后一個技術點就是如何保障高可用,確保應用的穩定性。

mPaaS 提供一套完整的運維體系來保證線上 App 的穩定。

  1. 開發測試

    通過接口實現分離,各模塊充分進行單元測試,集成之后進行聯調測試,聯調測試之后,交給 mPaaS 云測平臺,進行穩定性測試以及功能測試。充分的測試,可以將 80% 問題發現出來,并在發版前及時修復。

  2. 灰度發布

    結合上面提供的灰度能力,進行灰度發布。對于客戶端來說,有些問題,模擬測試環境是很難測出來的,那么這個時候,真實的線上灰度環境就是預防風險的重要手段之一了。通過灰度發布,逐步放量,不斷擴大灰度范圍,直到閃退率、卡死率等指標符合發布標準后,再進行全量的發布。

  3. 實時監控

    全方面監控各種緯度的 App 數據,如閃退、卡死、卡頓、電量、流量等。指定一定的異常規則,有問題及時進行報警。這些診斷數據是會周期性的進行上報,不過當有些特定機型或者特定用戶出現無法復現的問題時,我們還可以通過撈日志的方式,將指定設備的開發日志上報給服務端,進行分析排查。

  4. 動態修復

    最后,當問題發現并解決后,可以通過上面提到的發布平臺,將修復后的配置、離線包、小程序、熱修復 patch 包等,下發到對應設備上,進行容災修復。


2

基于 mPaaS 架構的重構思考

上面介紹完了 mPaaS 的能力,接下來我們聊下基于 mPaaS 的重構思考,本章會從五個維度來考慮重構。

> 架構重構

當我們決定架構重構后,一般會有兩種選擇進行重構,一種是全部推倒重來,還有一種是融合遷移。

這兩種方案,我們可以比喻為一架比較老的飛機,已經不足以滿足現在的飛行任務,第一種方案就是將飛機飛回機場,重新拆掉,結合新的設計架構從新組裝。第二種方案是在執行飛行任務的過程中,我們逐步去替換發動機、替換不滿足架構的地方,直至飛機滿足最新的任務需求。

無論我們采取哪種方式進行重構,首要的工作就是梳理現有業務,將整體結構進行模塊化拆分,同時對我們整體的架構進行合理分層。

  • 基于第一種方案:

    我們首先需要基于 mPaaS 架構搭建一個全新的框架,同時,由于我們是推倒重建,所以我們需要盡量減少在此階段提的新需求。等當整體架構完成后,再增加新需求。框架搭好后,我們需要將各項業務也進行重構,并逐個插到 mPaaS 容器化框架上來。最后當所有業務全部重構完成后,我們再進行全量的回歸測試。

    這種方式的優勢和劣勢都很明顯,優勢就是完全基于新的架構來實現,拋棄原有的包袱以及不合理的地方,但是劣勢就是,完全重構所需要的工作量是巨大的,同時有些企業可能無法接受如此長的時間不能或只能少量的更新需求。

  • 基于第二種方案:

    第一件事情就是將 mPaaS 架構接入進我們原有的工程中,然后再對原有框架進行融合適配:比如開發一個兼容新老框架跳轉的路由,兼容新老 H5 容器的原生插件等等。兼容工作完成后,我們就要對原有業務進行改造升級,我們可以將業務逐漸的拆分出來,跑在新的框架上。每完成一點,我們都可以進行一次迭代發布,測試的壓力也會比較小。

    這種方式的好處就是整個重構過程是一個持續性的過程,每一步都可以有產物輸出,小步快跑,持續迭代。但是劣勢就是,可能最終的版本,會有融合的痕跡存在,一些歷史包袱也可能無法很好地甩掉。

當然,這兩種重構方式沒有誰好誰壞,根據業務自身的需求來選擇自己合適的方式才是最好的。

> 能力重構

上面我們介紹了架構重構以及相應的方式,接下來我們來聊聊能力重構。

所謂能力重構,就是我們希望通過整合整個架構,在基礎層面,將通用的組件下沉,避免重復創造輪子,同時標準化服務接口,為更多的上層業務提供優質、穩定且標準的服務。

那么我們就需要從兩個方面來處理這個事情。

  • 基礎組件

我們在開發過程中可能會存在這樣一個問題,就是兩個團隊協作開發,可能大家有自己的一套存儲邏輯、網絡請求、工具庫或是其他冗余重復的代碼,這時候我們就需要將重復的部分,進行合并,沉淀,通過公共 bundle 的形式,對其他團隊提供能力。

當然,mPaaS 框架自帶了非常優秀的網絡、安全、存儲、多媒體等 App 開發過程中都需要使用的組件,供開發者直接調用。

  • 核心能力服務化

組件沉淀后,對于一些核心的業務能力,我們需要將這部分能力進行服務化,抽象出標準的服務接口,供其他團隊或是第三方生態調用。比如說支付寶的支付服務、芝麻信用服務等,都是依托于服務化,最終良好的為其他業務提供服務的。

> 業務重構

在我們完成框架重構和能力重構之后,整體的骨架和能力就已經具備了,剩下的就是基于這套框架,將我們的業務界面進行重構,在這里,我們建議大家參考以下原則:

  • 核心業務微應用化

針對一些非常核心的業務邏輯,比如支付報的支付,以及一些對性能要求比較高的業務,比如首頁,亦或是一些特殊交互的頁面。通常我們是希望通過使用原生頁面,并將頁面打成微應用的形式進行重構優化。因為這些頁面,通常不會有大改,所以對動態化能力要求不是很嚴格,同時原生又能滿足這些頁面多種多樣定制化的需求。

  • 復雜業務 H5 化

對一些復雜的二級業務,可能業務本身會頻繁的進行迭代,那么對于原生 native 將會是災難般的開發體驗,這時候,我們需將這部分業務剝離出來,通過前端技術將業務打成 H5 離線包,再通過發布服務將離線包發布到應用上。這樣,就滿足了我們業務復雜多變的場景。

  • 三方生態小程序化

我們不僅自身提供各種各樣的服務,也需要引入第三方服務來服務更多的人群,傳統的 H5 頁面由于過于寬泛的前端標準,加上有一定的技術門檻,這里就不如規范、簡單的小程序了。所以,一般第三方的服務,我們希望將其小程序化。

> 發布重構

當一切開發工作都 OK 之后,我們是否能夠說,本次的重構就完成了呢?答案是否定的。重構,不僅僅是針對代碼層面的重構,基于新的架構之后,整體的發布、運維理念也需要進行重構。

如上圖所示,我們重新定義了研發模式與發布流程,“Native 應用、H5 業務、小程序”都可以有自己的發布流程,無需等待其他團隊。各業務團隊進行完全拆分,每個業務獨立演進,獨立發布。

在發布過程中,要遵守以下流程:

  1. 指標線性,定義每次發布的業務和性能指標

  2. 智能灰度,內部灰度、外部灰度、指定灰度

  3. 實時監控,修復循環

  4. 線上運維修復手段技術兜底

> 運維重構

在上面我們也講到了運維理念的重構,在這里,我們要介紹下 mPaaS 架構是如何保障線上應用的質量的呢?

我們引入了多維度運維的概念,如圖所示:

最上面一層是開關。通過開關,將一些我們新開發的,或者是將穩定性不太確定的代碼包起來。這樣,如果真的線上發生故障,我們可以及時通過服務器推送開關,將故障代碼關閉,這種方式是推拉結合的,即時到達率 100%。

第二層緯度就是通過 H5 離線包。如果某些故障是發生在離線包內,那么我們可以定位到問題,直接再發送新的版本即可,這種方式也是推拉結合,但由于離線包需要下發,所以不如開關那么即時,不過在 1 分鐘之內也能覆蓋 99% 以上的用戶

第三個緯度就是小程序。如果故障發生在小程序上,那么同離線包,我們只需要重新修改小程序,重新發布,不過這里可能會涉及到審核問題,效率比離線包要略慢一點。

在下一個緯度第四個緯度是我們的熱修復。不到萬不得已一般不會進行熱修復,這是一個原生 Native 兜底的手段,通過熱修復補丁包的下發,我們來彌補我們的缺陷,一般成功率會在 95% 以上。

最后如果以上手段都無法修復,那么我們會啟動緊急發版流程,發布新的版本來覆蓋故障。

3

重構案例

  • 12306

2017 年底通過 mPaaS 進行了系統的重構,使用了 mPaaS 框架以及多項組件及服務,解決了 12306 移動端開發多年的痛點。比如 12306 的彈性動態化,之前會有在啟動頁面強制更新下載的情況,用戶體驗不太好,通過 mPaaS 優化后,進行了無感知更新,用戶體驗提升了一個臺階;還有就是 12306 使用了 mPaaS 的網關,其服務安全性得到了質的提升,也使得正常用戶的整體購買流程得到了好的體驗優化。


作為開發角度,客戶表示當年是移動端開發、運營最輕松的一年。作為使用者角度,多數用戶也表示使用體驗改善了很多。

  • 廣發銀行

廣發銀行之前采用其他移動端研發平臺,性能一直是瓶頸,尤其啟動時間,在部分低端機型上體驗不太友好,使用 mPaaS 重構后,平均啟動性能有了質的提升。

廣發銀行是“發現精彩”與“手機銀行”兩款 App 先后完成上線,兩個 App 均使用 mPaaS 框架進行重構。其內部有多個模塊的功能是重疊的,通過 mPaaS 模塊化架構拆除可復用的微服務、微應用以及離線包,使得開發后的手機銀行客戶端在研發工時上節省了大齡的研發工時。


我來說兩句
您需要登錄后才可以評論 登錄 | 立即注冊
facelist
所有評論(0)
領先的中文移動開發者社區
18620764416
7*24全天服務
意見反饋:[email protected]

掃一掃關注我們

Powered by Discuz! X3.2© 2001-2019 Comsenz Inc.( 粵ICP備15117877號 )

两码中特期期