引言

埋點對于移動應(yīng)用來說至關(guān)重要，無論是賦能業(yè)務(wù)增長，還是優(yōu)化技術(shù)實現(xiàn)，埋點數(shù)據(jù)和技術(shù)日志都為決策和優(yōu)化提供了關(guān)鍵依據(jù)。轉(zhuǎn)轉(zhuǎn)App也有著一套自研的日志采集系統(tǒng)（Lego），從2015年轉(zhuǎn)轉(zhuǎn)App上線第一個版本到現(xiàn)在，Lego逐步從一個單一功能架構(gòu)演變?yōu)橹С肿詣踊杉崟r上報、業(yè)務(wù)與技術(shù)日志隔離的復(fù)合架構(gòu)。xZn28資訊網(wǎng)——每日最新資訊28at.com

Lego演進歷程xZn28資訊網(wǎng)——每日最新資訊28at.com

總結(jié)起來，可以分為四個階段：xZn28資訊網(wǎng)——每日最新資訊28at.com

1. 從零到一建設(shè)能力；
2. 業(yè)務(wù)埋點與技術(shù)日志拆分；
3. 提高核心埋點實時性；
4. 架構(gòu)升級性能提升。

本文將為大家介紹客戶端在Lego升級的四個階段中的設(shè)計思路和解決方案。xZn28資訊網(wǎng)——每日最新資訊28at.com

Lego：從零到一

背景

1. 移動開發(fā)早期（2015 年）階段，移動設(shè)備資源（CPU，內(nèi)存，電量）有限，網(wǎng)絡(luò)環(huán)境不穩(wěn)定（網(wǎng)速慢，連接質(zhì)量差）；
2. 業(yè)界技術(shù)實現(xiàn)普遍注重低功耗，低開銷實現(xiàn)數(shù)據(jù)的采集上報；
3. 埋點相對較少，業(yè)務(wù)規(guī)模相對較小；

架構(gòu)設(shè)計

在上面的背景下，首先面對不穩(wěn)定的網(wǎng)絡(luò)環(huán)境，采用合并多個埋點的數(shù)據(jù)，將數(shù)據(jù)寫入本地文件的方式，盡量減少接口請求的頻次，防止網(wǎng)絡(luò)傳輸不穩(wěn)定導(dǎo)致數(shù)據(jù)丟失，較低的上報頻次，同時也減輕服務(wù)端的壓力；并且將埋點數(shù)據(jù)文件壓縮處理后再上報以節(jié)省網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)流量開銷。其次由于應(yīng)用主進程運行內(nèi)存有限，又涉及數(shù)據(jù)格式化，文件寫入，文件壓縮，網(wǎng)絡(luò)接口上報等操作，采用獨立子進程的方式處理可以避免擠占主進程的資源，同時隔離影響，由此有了下面的架構(gòu)設(shè)計：xZn28資訊網(wǎng)——每日最新資訊28at.com

Lego初始架構(gòu)xZn28資訊網(wǎng)——每日最新資訊28at.com

圖中可見，應(yīng)用主進程通過啟動Service(后臺服務(wù)）實現(xiàn)與子進程數(shù)據(jù)通信，發(fā)送配置更新，寫日志和上傳日志的指令和數(shù)據(jù)到 Lego 子進程。然后在子進程中進行初始化配置，將日志數(shù)據(jù)格式化寫入文件，在動態(tài)配置的時間間隔（默認(rèn)兩分鐘）或者接收到主動觸發(fā)的上傳指令時，將日志文件壓縮后通過接口上傳，成功后則刪除壓縮文件，否則在下次發(fā)送時機觸發(fā)時，再次嘗試上傳。xZn28資訊網(wǎng)——每日最新資訊28at.com

架構(gòu)特點

1. 獨立內(nèi)存空間：采用子進程做日志處理上報，子進程擁有獨立的內(nèi)存空間，避免擠占應(yīng)用主進程的內(nèi)存等資源；
2. 進程隔離，穩(wěn)定性高：子進程獨立與主進程運行，如果子進程在執(zhí)行日志寫入或上傳時崩潰，不會影響App主進程的正常運行。這樣大大提高應(yīng)用的穩(wěn)定性與用戶體驗；
3. 性能開銷低：子進程中將日志數(shù)據(jù)寫入文件，每兩分鐘合并發(fā)送一次，可以減少頻繁的接口請求，減輕服務(wù)端壓力的同時減少應(yīng)用的性能開銷。
4. 節(jié)省流量：客戶端經(jīng)過格式化數(shù)據(jù)，寫入本地文件后，每兩分鐘將日志文件壓縮后上傳到數(shù)據(jù)服務(wù)端，服務(wù)端接收數(shù)據(jù)后再進行文件解壓縮，落盤，清洗，落表。

Lego4APM：業(yè)務(wù)埋點與技術(shù)日志拆分

背景

1. 用戶規(guī)模增長，精細(xì)化和自動化決策運營的內(nèi)在需求，迫切需要強實時性的數(shù)據(jù)采集，上報，處理；
2. 業(yè)務(wù)埋點與APM 日志混合上報，未做區(qū)分，給大數(shù)據(jù)部門的數(shù)據(jù)處理造成時效性壓力；
3. 客戶端本身也需要將性能相關(guān)的埋點統(tǒng)一化，規(guī)范化，需要有新的聚合維度；

實現(xiàn)方案

上報的實現(xiàn)還是采用 Lego 的原有架構(gòu)，復(fù)制了新的組件 Lego4APM，將上報的數(shù)據(jù)服務(wù)接口換成技術(shù)埋點的專用接口，將技術(shù)日志與業(yè)務(wù)埋點分流。按照日志級別劃分，聚合原有的性能日志埋點，再將原有的日志采集接口的底層上報邏輯直接遷移到新組件。xZn28資訊網(wǎng)——每日最新資訊28at.com

拆分后結(jié)構(gòu)圖xZn28資訊網(wǎng)——每日最新資訊28at.com

Lego業(yè)務(wù)與技術(shù)埋點拆分結(jié)構(gòu)圖xZn28資訊網(wǎng)——每日最新資訊28at.com

圖中ZPM為基于轉(zhuǎn)轉(zhuǎn)位置模型自研的自動化埋點采集框架，采集完的數(shù)據(jù)通過 Lego 上報，APM則是性能監(jiān)控框架采集技術(shù)日志，通過Lego4APM組件上報，其中 Lego 與 Lego4APM 是相同實現(xiàn)的兩套獨立的組件。xZn28資訊網(wǎng)——每日最新資訊28at.com

LegoRealtime：提高實時性

背景

將用戶行為埋點與 APM 日志通過 Lego 和 Lego4Apm 分流后，做到數(shù)據(jù)隔離，但是Lego 原有設(shè)計是多埋點合并上報，每2 分鐘壓縮文件后上報一次，為實現(xiàn)自動化運營的整體方案，客戶端要盡可能保證在 200ms 時延內(nèi)完成核心用戶行為的采集上報，提高實時性。xZn28資訊網(wǎng)——每日最新資訊28at.com

方案設(shè)計

方案設(shè)計階段我們也調(diào)研前端的方案，是直接采用的接口上報，但是作為移動端，需要發(fā)揮移動端的特性，下面是實時版本設(shè)計思路。xZn28資訊網(wǎng)——每日最新資訊28at.com

LegoRealtime 架構(gòu)圖xZn28資訊網(wǎng)——每日最新資訊28at.com

方案實現(xiàn)關(guān)鍵

1. 數(shù)據(jù)備份容災(zāi)：考慮移動端的環(huán)境多樣問題，容易出現(xiàn)了異常，弱網(wǎng)，斷網(wǎng)的情況，數(shù)據(jù)備份很必要，同時也要區(qū)分日志是實時的，還是異常備份數(shù)據(jù)，涉及日志記錄的狀態(tài)修改，數(shù)據(jù)庫備份比文件備份更合適。
2. 異常數(shù)據(jù)重傳機制：在網(wǎng)絡(luò)連接恢復(fù)，應(yīng)用重新啟動，以及固定時間間隔，對異常數(shù)據(jù)進行批量重傳；
3. 簡單格式化，高效處理：實時上傳只利用了https本身支持的內(nèi)容壓縮，未做額外的壓縮等處理，直接以json格式上傳數(shù)據(jù)，數(shù)據(jù)服務(wù)端在處理數(shù)據(jù)時相比壓縮格式上報，不需要額外的解壓縮處理，更高效。
4. 穩(wěn)定可控：方案設(shè)計之初就考慮上線后如何控制穩(wěn)定遷移以及數(shù)據(jù)驗證的問題，增加了灰度控制開關(guān)和數(shù)據(jù)驗證接口。

遷移方案

1. 無侵入遷移：為了避免大量更改原有業(yè)務(wù)埋點的接入代碼，我們選擇通過攔截原有 Lego 上報的接口，通過白名單控制核心埋點走實時上報，對原有接入業(yè)務(wù)無侵入，降低影響范圍。
2. 上線穩(wěn)定控制：配置 ABTest灰度開關(guān)，方案驗證階段，先按照10%的灰度比例切換到實時上報，觀察數(shù)據(jù)完整性，后端服務(wù)的穩(wěn)定性，驗證通過后逐步增大比例到 50%，穩(wěn)定運行一周后全量切換。
3. 數(shù)據(jù)質(zhì)量驗證：

• 時效性方面，通過 APM 后臺的監(jiān)控數(shù)據(jù)，確認(rèn)Lego 實時上報接口的往返時延是否達到低時延設(shè)計目標(biāo)。
• 完整性方面，采用了實時埋點通過實時方式和文件壓縮合并方式同時上報的方案來驗證數(shù)據(jù)完整性，其中文件壓縮合并方式使用的是Lego4APM，因為技術(shù)日志落盤數(shù)據(jù)與業(yè)務(wù)數(shù)據(jù)是隔離的，將這部分?jǐn)?shù)據(jù)上報到技術(shù)埋點不會污染業(yè)務(wù)數(shù)據(jù)，用以驗證完整性非常合適。

驗證結(jié)論

1. 性能平臺監(jiān)控到，實時上報接口的平均往返時延為 160ms,發(fā)送時延按一半估算為80ms,遠遠低于設(shè)計目標(biāo)的200ms，為大數(shù)據(jù)端數(shù)據(jù)處理預(yù)留了操作空間；
2. 由于實現(xiàn)的機制不同，Lego實時上報的數(shù)據(jù)比 Lego4APM 上報的數(shù)據(jù)多 1%，在合理范圍內(nèi)；

Lego 新架構(gòu)：性能提升

背景

1. 業(yè)務(wù)方面：

• 某些場景存在后臺啟動服務(wù)，存在隱私合規(guī)問題；
• 數(shù)據(jù)組反饋數(shù)據(jù)重復(fù)上報問題，以及埋點缺失問題；

2. 技術(shù)方面：

• 應(yīng)用市場反饋 Lego 相關(guān)的卡頓問題(當(dāng)埋點量較多時，頻繁從主進程發(fā)送埋點數(shù)據(jù)和配置到子進程，每次數(shù)據(jù)交互都是 IPC,這會擠占系統(tǒng)的 binder 通信的資源，Android系統(tǒng)的各種服務(wù)包括頁面的創(chuàng)建，點擊事件的交互等都是使用 binder 通信實現(xiàn)，容易引發(fā)卡頓問題)
• 多進程配置管理復(fù)雜，相同的配置主進程配置后需要再同步至子進程，這給組件的升級維護帶來了額外的成本。
• Lego 和 Lego4APM相同功能的多套代碼，修改出現(xiàn)分叉，維護成本增高；
• Lego 項目由來已久，實現(xiàn)方案不符合于移動端內(nèi)存相對充足，性能過剩的現(xiàn)狀；

新方案架構(gòu)設(shè)計

基于業(yè)務(wù)和技術(shù)多方面因素考慮，我們對 Lego進行了重新設(shè)計，新架構(gòu)如下圖：xZn28資訊網(wǎng)——每日最新資訊28at.com

Lego 新架構(gòu)設(shè)計xZn28資訊網(wǎng)——每日最新資訊28at.com

圖中可以看到，新架構(gòu)采用的是子線程方案，在主進程創(chuàng)建Lego 實例，通過實例進行配置管理，寫日志和上傳觸發(fā)， 同時實例通過創(chuàng)建HandlerThread 子線程，在子線程中進行日志文件寫入和壓縮上傳。xZn28資訊網(wǎng)——每日最新資訊28at.com

新方案優(yōu)點

1. 無需IPC，開銷低：老架構(gòu)的子進程方案需要頻繁的 IPC,且更改配置時，主進程和子進程都要維護，而新架構(gòu)在同一進程中，線程間內(nèi)存共享，無需要 IPC的額外性能消耗，卡頓問題自然解決，配置只需要保證線程安全即可。
2. 無隱私合規(guī)問題：老架構(gòu)某些場景觸發(fā)后臺啟動服務(wù)實現(xiàn)IPC，而上報數(shù)據(jù)包含位置信息，用戶設(shè)備 id等隱私數(shù)據(jù)，引發(fā)隱私不合規(guī)問題，新架構(gòu)中無需IPC，也就不需要從后臺啟動服務(wù)了。
3. 支持多實例，易維護：非核心用戶行為埋點和 APM 埋點的上報實現(xiàn)基本一致，老架構(gòu)需要多份復(fù)制，額外占用系統(tǒng)進程，同時維護成本大，新架構(gòu)支持多個實例后，兩種上報只需要兩個實例，兩套配置即可，性能和維護成本上沒有額外的消耗。
4. 上報穩(wěn)定：老架構(gòu)存在重復(fù)上報，埋點缺失的問題，新架構(gòu)中通過 HandlerThread 的事件循環(huán)隊列實現(xiàn)寫日志與上傳日志串行執(zhí)行。防止邊上傳邊寫入容易造成重復(fù)上報和缺失的問題。

版本遷移方案

Lego、Lego4APM作為客戶端的基礎(chǔ)能力，承載著客戶端所有業(yè)務(wù)及技術(shù)埋點，一旦出現(xiàn)問題，對于客戶端來說將是災(zāi)難。對如此重要的組件進行重構(gòu)，面臨巨大的風(fēng)險，需要制定一個穩(wěn)妥的、漸進的、對上層業(yè)務(wù)無感知的遷移方案。計劃將版本遷移拆分為兩個階段：xZn28資訊網(wǎng)——每日最新資訊28at.com

• 階段一：對照驗證，通過選定指定埋點，對比新老版本埋點數(shù)量及參數(shù)是否在合理范圍內(nèi)，驗證時間全量后兩天，驗證通過進入第二階段，驗證不通過則停止版本遷移，定位問題后下個版本繼續(xù)進入階段一。
• 階段二：版本切換，按用戶比例逐步切換到新版Lego，用戶比分為三個階梯：10%、50%、100%，每個階梯灰度一周時間，期間觀察核心業(yè)務(wù)埋點指標(biāo)（如登錄PV/UV、詳情頁PV/UV、訂單PV/UV）是否正常。

遷移后埋點數(shù)據(jù)對比結(jié)果xZn28資訊網(wǎng)——每日最新資訊28at.com

驗證結(jié)論：新版本埋點數(shù)據(jù)的內(nèi)容完整沒有缺失，并且比舊版本的數(shù)據(jù)量多1%xZn28資訊網(wǎng)——每日最新資訊28at.com

總結(jié)與展望

Lego系統(tǒng)結(jié)構(gòu)xZn28資訊網(wǎng)——每日最新資訊28at.com

上圖是目前轉(zhuǎn)轉(zhuǎn)客戶端的Lego日志系統(tǒng)結(jié)構(gòu)圖，其中包含了數(shù)據(jù)采集和數(shù)據(jù)上報兩個部分。業(yè)務(wù)核心埋點數(shù)據(jù)由ZPM（轉(zhuǎn)轉(zhuǎn)位置模型自動化采集框架）采集，通過LegoRealtime組件實時上報；業(yè)務(wù)其他埋點則是手動埋點采集，通過基于Lego新架構(gòu)的Lego4Buz實例上報；技術(shù)日志用APM日志框架（性能監(jiān)控)采集，由基于Lego新架構(gòu)的Lego4APM實例上報。xZn28資訊網(wǎng)——每日最新資訊28at.com

通過這些優(yōu)化和升級，不僅增加數(shù)據(jù)上報的可靠性和實時性，還顯著提升了穩(wěn)定性，降低了維護成本。在這個過程中也收獲了寶貴的經(jīng)驗，在實現(xiàn)日志上報功能時，我們不僅需要考慮如何減少不必要的性能開銷，發(fā)揮客戶端的優(yōu)勢，合并上報以減輕服務(wù)器的壓力，同時我們還需要確保新舊版本的平滑過渡和安全遷移，制定周全的遷移方案，以便在出現(xiàn)問題時能夠?qū)崟r回退，做到安全可控。xZn28資訊網(wǎng)——每日最新資訊28at.com

關(guān)于埋點上報的優(yōu)化，我們還有其他的演進方向，如LegoRealtime實時上報，頻繁的https接口請求，可以替換成其他低功耗傳輸方式；而Lego新架構(gòu)的異常處理方面，在服務(wù)異常時會頻繁重試，可能會讓系統(tǒng)異常問題雪上加霜。此外，大日志文件上傳的策略優(yōu)化等方面，還有演進升級的空間，如采取拋棄策略，避免影響整體運行，或者拆分成小文件縮短上報時間，提高成功率。xZn28資訊網(wǎng)——每日最新資訊28at.com

總之，升級之路是不斷優(yōu)化和改進現(xiàn)有方案的過程，我們將繼續(xù)尋求更加高效、穩(wěn)定和安全的實現(xiàn)方式，推動Lego系統(tǒng)的不斷演進和升級。xZn28資訊網(wǎng)——每日最新資訊28at.com

本文鏈接：http://m.www897cc.com/showinfo-26-98197-0.html解密Lego：客戶端日志系統(tǒng)的演進

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇： 智能個性化推薦系統(tǒng)設(shè)計與實踐，你學(xué)會了嗎？

下一篇： 一文搞懂Nginx配置：輕松駕馭多域名管理的實戰(zhàn)攻略