如何設(shè)計一個端計算架構(gòu)？
什么是端計算?如何在不額外占用服務(wù)端資源的情況下，在客戶端解決計算需求?端計算和云計算相比，有哪些優(yōu)勢?本文從設(shè)計一個解決埋點熱修問題的通用化架構(gòu)，及其演變乃至解決其他端計算問題的案例，來說明設(shè)計一個端計算架構(gòu)的一般性方法。
移動端發(fā)展至今，誕生了很多架構(gòu)用于解決各領(lǐng)域的專有問題。比如針對移動端動態(tài)化的Hybrid方案;兼顧動態(tài)化和性能的RN、WEEX乃至界面搭建方案;針對熱修復(fù)的各種Patch方案;還有一些配置、編排等特殊需求的方案。這些方案的核心都是用某種語言描述業(yè)務(wù)的邏輯方法，描述能力越強大，能夠解決的問題越多。腳本語言似乎有著無限的可能性，但是當(dāng)我們嘗試解決某個未知領(lǐng)域的計算問題，對于問題計算的可行性又缺少自信。此外，正確評估各種架構(gòu)的計算性極限對于我們選型、解決具體問題也是十分重要的。因此需要總結(jié)如何設(shè)計、評估端計算架構(gòu)的一般性方法。
一 從解決埋點熱修問題理解何為端計算
因眾所周知的原因，蘋果禁止類似JSPatch的熱修復(fù)方案上線。對于考拉iOS客戶端，大多數(shù)問題需要發(fā)版解決。通過發(fā)版解決數(shù)據(jù)問題，周期長且持續(xù)產(chǎn)生臟數(shù)據(jù)。對于依賴數(shù)據(jù)驅(qū)動產(chǎn)品迭代的開發(fā)方式會產(chǎn)生很大影響。同時，我也在思索是否有一種更敏捷的移動端取數(shù)方案，縮短數(shù)據(jù)試驗周期?；谝陨夏康?，埋點熱修方案的研發(fā)就提上了日程。
雖然我們可以使用JS腳本作為計算載體，但是需要證明埋點熱修是否可通過計算修復(fù)。
如上圖所示，埋點修復(fù)其實就是將一個錯誤的字典計算為一個正確字典的過程。如果滿足下面兩個條件，則可以修正任何錯誤的埋點數(shù)據(jù)：
- 能夠無二義性的識別錯誤數(shù)據(jù)。
- 完備的數(shù)據(jù)，可以計算出正確的數(shù)據(jù)。
要滿足第一個條件，可以根據(jù)字典本身的數(shù)據(jù)特征、交互特征、當(dāng)前頁面等上下文數(shù)據(jù)來識別。埋點數(shù)據(jù)源自服務(wù)端返回數(shù)據(jù)、前端位置及交互和頁面上下文。要滿足第二個條件，只需要補充上述數(shù)據(jù)即可。因此接入的數(shù)據(jù)源是否完備，是決定框架修復(fù)能力上限的一個重要的因素。
上面解決了埋點錯埋和多埋的問題，但是不能解決埋點漏埋的問題。解決埋點漏埋需要在交互的合適時機，計算好埋點字典傳輸給SDK。計算的問題上面已經(jīng)解決。那么只要滿足在合適的時機計算，就可以解決埋點漏埋的問題。
綜上所訴，如果要修復(fù)埋點問題，則需要滿足下面三個條件：
- 能夠無二義性的識別錯誤數(shù)據(jù)。
- 完備的數(shù)據(jù)，可以計算出正確的數(shù)據(jù)。
- 需要在合適的時機進行計算。
其實對于錯埋和多埋的修復(fù)場景，就是在上報SDK前這一時機進行計算。
至此，一個解決埋點熱修問題的計算框架原理基本完成。框架主要圍繞三件事情展開：
- 一，向JSContext補充API提供基礎(chǔ)計算能力。
- 二，補充數(shù)據(jù)源為計算提供物料。
- 三，補充觸發(fā)計算的時機。
計算、數(shù)據(jù)、時機是一個計算框架能力最重要的三個因素。為了進一步說明，下面給出一個修復(fù)加購埋點漏埋問題的案例。
隨著提供的API、數(shù)據(jù)以及時機能力增強，該框架可以解決一些線上功能性問題修復(fù)。比如：
- 修復(fù)視頻多段拍攝存在問題：在進入剪輯編輯器前修改傳入的音軌信息，禁用多段拍攝功能，并調(diào)整頁面相關(guān)控件的顯示狀態(tài)。
- 修復(fù)搜索特定關(guān)鍵詞，導(dǎo)致富文本渲染出現(xiàn)崩潰：修改下發(fā)數(shù)據(jù)字段，回避崩潰問題。
- 修復(fù)因缺少參數(shù)，導(dǎo)致品牌非自營商品搜索請求失?。盒薷慕涌诘恼埱篌w，補充必要數(shù)據(jù)。
- 修復(fù)SKU切換時某區(qū)域數(shù)據(jù)未刷新問題：在SKU切換后，重置該區(qū)域的View的顯示狀態(tài)。
此外，還進行過一些數(shù)據(jù)實驗。比如分析5秒內(nèi)用戶退出APP的原因，UT通道數(shù)據(jù)丟失指標(biāo)建立等。
對計算、數(shù)據(jù)、時機三個維度的補充，框架已經(jīng)從埋點修復(fù)，泛化為一般的端計算框架。通過控制數(shù)據(jù)，去影響APP的功能。從端計算的角度看JSPatch等熱修框架，它的計算、數(shù)據(jù)層面限制較少，但是修復(fù)時機是函數(shù)調(diào)用級別。相比代碼行級別的修復(fù)，框架對修復(fù)方案有一定的限制。
二 從端計算角度改善DinamicX框架
DinamicX的搭建能力非常強，一般情況下，模板主要從單一數(shù)據(jù)源取數(shù)計算。數(shù)據(jù)源通常由網(wǎng)絡(luò)請求下發(fā)。
如果期望做一些接口膠水層聚合，或者定制客戶端ViewModel的邏輯，可以接入FAAS層對DX的數(shù)據(jù)源進行重計算。
但是FAAS只能利用服務(wù)端側(cè)數(shù)據(jù)進行計算，從端計算角度看，無法天然使用客戶端側(cè)數(shù)據(jù)進行計算。這樣并不適應(yīng)需要服務(wù)端側(cè)和客戶端側(cè)數(shù)據(jù)共同計算的需求。比如有些展示坑位有紅點提示，需要點擊后讓紅點消失，或者消失后隔一段時間再次展示。這個需求客戶端側(cè)相對好實現(xiàn)一些，坑位點擊后本地打標(biāo)，也不需要消耗服務(wù)端資源。服務(wù)端也有一些方案，比如點擊后發(fā)起請求由服務(wù)端打標(biāo)，然后FAAS層根據(jù)標(biāo)記計算數(shù)據(jù)源展示?；蛘呖蛻舳舜驑?biāo)，在請求時回傳標(biāo)記給服務(wù)端，然后由FAAS層計算數(shù)據(jù)源展示。兩種服務(wù)端方案，本質(zhì)上類似，都是想辦法讓服務(wù)端側(cè)獲取這個標(biāo)記數(shù)據(jù)。
不想消耗服務(wù)端資源，又想從DX層面實現(xiàn)這個需求，如果看了之前埋點熱修的框架方案，很自然的得出下面的解法。
這個方案是可以解決上面的問題，但也有一些設(shè)計上的問題。比如純動態(tài)化發(fā)版解決有些麻煩，邏輯分散，客戶端會有額外的內(nèi)存、IO操作?；氐絾栴}本身，其實我們是期望在DX引擎渲染計算時能夠利用服務(wù)端側(cè)和客戶端側(cè)數(shù)據(jù)。我通過對DX框架的學(xué)習(xí)，發(fā)現(xiàn)一種更優(yōu)雅解決該問題的方案。
雖然DX渲染接口上只能使用單一數(shù)據(jù)源，但是DX提供了DataParser自定義計算表達式機制。我們可以定制一個DataParser，在模板渲染中使用客戶端側(cè)數(shù)據(jù)。這樣DX模板其實可以支持多種數(shù)據(jù)源進行計算。同時DX提供了一個用戶上下文，用于參與DataParser和EventHandler的計算。我們可以設(shè)計一個DataParser，獲取用戶上下文中的鍵值對數(shù)據(jù);此外可以設(shè)計一個EventHandler用于將鍵值對數(shù)據(jù)設(shè)置到用戶上下文中。用戶上下文提供多種生命周期的存儲方法，實現(xiàn)頁面內(nèi)DX組件間數(shù)據(jù)互通，頁面間DX組件間數(shù)據(jù)互通，以及持久化能力。從時機角度看，其實DX可以在事件觸發(fā)時，執(zhí)行多個EventHandler。這樣可以通過組合執(zhí)行EventHandler代替類似萬能函數(shù)的EventHandler實現(xiàn)。使計算更具有靈活性。最終改造后的方案如下。
新方案通過計算和數(shù)據(jù)兩個角度進行了優(yōu)化。方案不額外占用服務(wù)端資源，在DX模板中實現(xiàn)了全部邏輯，同時支持動態(tài)發(fā)布能力。比較優(yōu)異的解決了該需求。
三 端計算優(yōu)勢以及未來發(fā)展
計算上云目前是趨勢。極端的角度看，期望客戶端越做越輕，將主要的計算能力放到云上解決。我之前做過類似云游戲的方案，3D游戲這種極端依賴客戶端硬件能力的應(yīng)用也可以上云。隨著通訊技術(shù)的進一步發(fā)展，游戲上云、APP上云將來會有商業(yè)化產(chǎn)品出現(xiàn)。雖然趨勢如此，但是端上依然有兩大優(yōu)勢，是云計算無法替代的：一是算力經(jīng)濟性，二是數(shù)據(jù)完備性。
從算力經(jīng)濟性角度看，端設(shè)備硬件的算力逐漸攀升。一般使用場景，算力其實是過剩的。同時頻繁、大數(shù)據(jù)量的通訊，無論對用戶還是運營組織，都是存在成本的。云計算與端計算未來會因經(jīng)濟性和體驗，在適用場景上達到一個平衡。這是整體計算經(jīng)濟性最優(yōu)導(dǎo)致的結(jié)果。
從數(shù)據(jù)完備性角度看，端上采集永遠是第一手數(shù)據(jù)，無論維度還是數(shù)據(jù)量都較大。這些數(shù)據(jù)傳輸，以及在云上還原用戶上下文場景都需要巨大的算力。云端獲得數(shù)據(jù)前，需要端上處理、清洗數(shù)據(jù)。云端數(shù)據(jù)始終存在人為的信息丟失、修改情況?？捎嬎阈砸蕾嚁?shù)據(jù)完備性，另外出于對響應(yīng)、算力的考慮，有些計算場景下放到端上計算更合適。特別是一些需要大量、復(fù)雜用戶上下文數(shù)據(jù)參與的場景。此外，未來隱私合規(guī)升級，數(shù)據(jù)傳輸?shù)皆粕蠒鼮橹斏鳌榱吮ＷC一些服務(wù)的可持續(xù)運行，需要提供端計算的適配方案。
服務(wù)端和客戶端都滿足數(shù)據(jù)完備性的情況下，如果客戶端再提供計算動態(tài)性支持，其實選用哪個方案沒有本質(zhì)性區(qū)別。例如FAAS服務(wù)可以使用云計算實現(xiàn)，也可以使用端計算實現(xiàn)。剩下的是性能、體驗、成本以及穩(wěn)定性等其他方面綜合性考慮。
【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
