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