基于異常上線場(chǎng)景的實(shí)時(shí)攔截與問題分發(fā)策略

性能中臺(tái)負(fù)責(zé)MEG端研發(fā)數(shù)據(jù)的接入、傳輸、管理、應(yīng)用等各個(gè)環(huán)節(jié)。為了應(yīng)對(duì)移動(dòng)應(yīng)用領(lǐng)域中端技術(shù)的快速迭代和線上突增問題的挑戰(zhàn)，中臺(tái)提出了實(shí)時(shí)攔截與問題的分發(fā)機(jī)制，旨在在端上線的不同階段及時(shí)發(fā)現(xiàn)并攔截異常上線，最大程度減少線上變更對(duì)用戶體驗(yàn)的不良影響。本文在數(shù)據(jù)建設(shè)的時(shí)效性和準(zhǔn)確性上進(jìn)行深入的探討，包括：變更上線的染色過程、基于染色I(xiàn)D的性能核心數(shù)據(jù)指標(biāo)的監(jiān)控、線上問題實(shí)時(shí)分發(fā)至相關(guān)模塊組件和人員等。

01

背景

1.1 業(yè)務(wù)背景

在快速發(fā)展的移動(dòng)應(yīng)用領(lǐng)域中，持續(xù)的技術(shù)迭代是保持APP競(jìng)爭(zhēng)力的關(guān)鍵因素。然而，對(duì)于規(guī)模龐大、用戶眾多的APP應(yīng)用，每一次的變更上線都存在引入線上問題的風(fēng)險(xiǎn)。APP的各個(gè)組件模塊相互交織，一旦某處出現(xiàn)異常，往往會(huì)像連鎖反應(yīng)一樣影響整個(gè)系統(tǒng)的穩(wěn)定性，導(dǎo)致用戶體驗(yàn)的下降。在以往的經(jīng)驗(yàn)中，即便在開發(fā)和測(cè)試階段充分驗(yàn)證，也難免會(huì)有一些問題在真實(shí)用戶環(huán)境中暴露出來。這些問題可能表現(xiàn)為崩潰、卡頓、功能失效等，嚴(yán)重影響用戶的使用體驗(yàn)。在過去，應(yīng)對(duì)這些問題通常是事后進(jìn)行問題修復(fù)，然而這種方式并不能完全避免線上問題對(duì)用戶體驗(yàn)的不良影響。因此我們希望在業(yè)務(wù)迭代變更上線的過程中，盡可能早的發(fā)現(xiàn)和攔截問題，最大程度的降低問題對(duì)用戶的影響。因此，性能中臺(tái)引入了多級(jí)攔截和問題分發(fā)的機(jī)制，這一機(jī)制旨在在變更上線的不同灰度放量階段，對(duì)每次上線或者放量操作進(jìn)行染色形成唯一染色I(xiàn)D，通過對(duì)每個(gè)染色I(xiàn)D的核心性能數(shù)據(jù)指標(biāo)進(jìn)行監(jiān)控，一旦發(fā)現(xiàn)異常，多級(jí)攔截機(jī)制將會(huì)被觸發(fā)，攔截本次上線以及后續(xù)放量。同時(shí)，問題實(shí)時(shí)分發(fā)機(jī)制能夠直接將問題指向?qū)е略搯栴}發(fā)生的模塊和組件以及開發(fā)和測(cè)試人員。從而準(zhǔn)確定位問題，并迅速修復(fù)，避免問題在更大范圍內(nèi)擴(kuò)散。

1.2 技術(shù)背景

實(shí)時(shí)UV計(jì)算：在處理異常上線的攔截過程中，數(shù)據(jù)的實(shí)時(shí)消費(fèi)以及數(shù)據(jù)的時(shí)效性的要求特別高，必須在分鐘級(jí)別內(nèi)完成。同時(shí)，業(yè)務(wù)方不僅需要獲得異常的PV數(shù)，同時(shí)也需要獲得在各個(gè)維度下異常影響的用戶數(shù)（UV）。但實(shí)時(shí)UV計(jì)算不能簡(jiǎn)單地累加，這涉及到同維度間用戶交集的處理。例如：A版本和B版本異常影響的用戶數(shù)分別是100，但整體用戶數(shù)實(shí)際上可能不足200。但是也不能直接存儲(chǔ)用戶ID，例如通過使用HashSet或者HashMap存儲(chǔ)所有的用戶ID進(jìn)行去重，這面對(duì)大量用戶時(shí)，會(huì)占用大量的計(jì)算節(jié)點(diǎn)內(nèi)存資源。因此，我們采取一種計(jì)算的時(shí)效性和準(zhǔn)確性較高的數(shù)據(jù)結(jié)構(gòu)Bitmap來計(jì)算實(shí)時(shí)UV。

Bitmap 的底層數(shù)據(jù)結(jié)構(gòu)用的是 String 類型的 SDS 數(shù)據(jù)結(jié)構(gòu)來保存位數(shù)組，把每個(gè)字節(jié)數(shù)組的 8 個(gè) bit 位利用起來，每個(gè) bit 位 表示一個(gè)元素的二值狀態(tài)。該數(shù)據(jù)結(jié)構(gòu)能節(jié)約大量的存儲(chǔ)，同時(shí)在用戶群做交集和并集運(yùn)算的時(shí)候也有極大的便利。例如，每個(gè)用戶ID如果存儲(chǔ)在HashSet或者HashMap中，需要占4個(gè)字節(jié)即32bit，而一個(gè)用戶在Bitmap中只占一個(gè)bit。在做交并集運(yùn)算時(shí)，例如，員工1、員工2都是程序員，員工1使用蘋果手機(jī)，那么如何查找使用蘋果手機(jī)的程序員用戶？

直接使用位運(yùn)算，使用蘋果手機(jī)的程序員用戶:（0000000110B & 0000000010B = 0000000010B）

異常反混淆：主要用于問題分發(fā)階段。APP廠商在發(fā)布應(yīng)用程序包時(shí)，通常會(huì)對(duì)包進(jìn)行混淆操作，這是為了提高APP應(yīng)用的安全性和減少反編譯的風(fēng)險(xiǎn)?；煜菍⒃创a中的符號(hào)、名稱和結(jié)構(gòu)等轉(zhuǎn)換為難以理解的形式，使得反編譯后的代碼難以還原為原始的源代碼，但是APP上報(bào)的異常信息也被混淆了。反混淆操作是將混淆后的異常信息還原為可讀的形式，使開發(fā)人員能夠更準(zhǔn)確地分析問題的原因，并迅速采取正確的修復(fù)措施。在APP產(chǎn)出應(yīng)用程序包時(shí)，同時(shí)也會(huì)產(chǎn)生一份用于反混淆異常信息的映射文件（密碼本），通過映射文件 + 解析算法對(duì)混淆的異常進(jìn)行解析，即可得到已讀的異常堆棧。

△異常信息反混淆過程

1.3 名詞解釋

性能中臺(tái)：性能中臺(tái)是APP性能追蹤的一站式解決方案平臺(tái)，為APP提供全面、實(shí)時(shí)的性能分析服務(wù)與工具鏈。

移動(dòng)線上質(zhì)量平臺(tái):移動(dòng)線上質(zhì)量平臺(tái)是移動(dòng)端APP發(fā)包后，用來查看、分析包質(zhì)量數(shù)據(jù)、進(jìn)行核心指標(biāo)監(jiān)控/報(bào)警、變更異常攔截。

日志中臺(tái)：指端日志中臺(tái)，包括端日志全生命周期的能力建設(shè)。包括打點(diǎn)SDK / 打點(diǎn)server/日志管理平臺(tái)等核心組件。

Tekes平臺(tái)：App端研發(fā)平臺(tái)，提供包組件管理等基礎(chǔ)設(shè)施。

GEEK TALK

02

系統(tǒng)設(shè)計(jì)

2.1整體流程

在以往的流程中，針對(duì)客戶端上線變更，我們通常使用大盤性能指標(biāo)來進(jìn)行監(jiān)控，以便進(jìn)行問題定位和止損。然而，在灰度用戶數(shù)量較少的情況下，線上問題往往無法在大盤性能指標(biāo)中產(chǎn)生明顯波動(dòng)。當(dāng)業(yè)務(wù)決定全量上線或擴(kuò)大灰度用戶規(guī)模時(shí)，問題就可能顯現(xiàn)出來了。在問題定位和解決的階段，我們過多地依賴人工干預(yù)和手動(dòng)排查，這導(dǎo)致問題定位和解決的時(shí)間較長(zhǎng)，并可能升級(jí)為事故。因此，在舊流程中，線上問題影響面大小主要取決于灰度用戶的規(guī)模以及問題排查人員對(duì)客戶端各個(gè)模塊和相關(guān)人員的了解程度，這是不合理的。因此，系統(tǒng)設(shè)計(jì)的關(guān)鍵在于解決兩個(gè)核心問題：首先，如何在灰度階段攔截問題，避免其進(jìn)一步擴(kuò)大；其次，一旦線上問題出現(xiàn)，如何能夠迅速進(jìn)行問題召回與解決。

△線上異常實(shí)時(shí)攔截與問題分發(fā)整體流程設(shè)計(jì)圖

因此，在新流程中，引入了兩個(gè)關(guān)鍵模塊："變更攔截模塊"和"問題分發(fā)模塊"。對(duì)于每次平臺(tái)的上線變更，必須先在變更攔截模塊中進(jìn)行注冊(cè)，從而生成一個(gè)唯一的上線染色I(xiàn)D。同時(shí)，將染色I(xiàn)D下發(fā)至本次變更上線的用戶客戶端。此后，該數(shù)據(jù)集的用戶日志將攜帶染色I(xiàn)D進(jìn)行上報(bào)。變更攔截模塊將基于染色I(xiàn)D的粒度進(jìn)行監(jiān)控和攔截，以保證在上線過程中問題的及時(shí)發(fā)現(xiàn)。同時(shí)，問題分發(fā)模塊建立了問題自動(dòng)分發(fā)機(jī)制。當(dāng)一個(gè)上線變更被攔截或者在線上出現(xiàn)問題時(shí)，該模塊將直接將問題指派給涉及問題的模塊、組件，以及相關(guān)的研發(fā)和測(cè)試人員。協(xié)助業(yè)務(wù)方快速準(zhǔn)確的定位問題，人工再介入修復(fù)。

2.2異常上線變更攔截

異常上線變更攔截的核心思路是：為每次上線變更生成獨(dú)特的染色I(xiàn)D，通過對(duì)每個(gè)染色I(xiàn)D的性能核心數(shù)據(jù)進(jìn)行攔截與監(jiān)控。

△異常上線變更攔截流程設(shè)計(jì)圖

變更攔截流程的具體步驟如下：

① 變更上線注冊(cè)：針對(duì)廠內(nèi)各個(gè)配置變更平臺(tái)，需要在每次上線配置生效之前，將上線信息在染色通用服務(wù)進(jìn)行注冊(cè)。

② 獲取染色I(xiàn)D：染色通用服務(wù)通過HTTP接口為每次上線注冊(cè)生成通用的染色I(xiàn)D，并將其返回給上線變更平臺(tái)。

③ 下發(fā)染色配置：在圈定的用戶群范圍內(nèi)，上線變更平臺(tái)將新配置和染色信息同時(shí)下發(fā)到端上的業(yè)務(wù)SDK（如AB-SDK）中。

④ 染色日志上報(bào)：業(yè)務(wù)SDK會(huì)判定染色是否生效，如果生效，則在涉及性能核心場(chǎng)景的日志中附加染色I(xiàn)D信息，然后通過UBC-SDK上報(bào)。這些日志會(huì)通過日志中臺(tái)實(shí)時(shí)轉(zhuǎn)發(fā)，并寫入消息隊(duì)列。

⑤ 實(shí)時(shí)指標(biāo)計(jì)算：性能中臺(tái)會(huì)實(shí)時(shí)訂閱消息隊(duì)列中的核心性能數(shù)據(jù)，例如崩潰、APP啟動(dòng)次數(shù)等，然后針對(duì)每個(gè)染色I(xiàn)D，根據(jù)多個(gè)維度（如產(chǎn)品線、APP版本、操作系統(tǒng)、地域等）形成性能聚合指標(biāo)，并將其寫入持久存儲(chǔ)。

⑥ 異常攔截服務(wù)：基于存儲(chǔ)中的染色數(shù)據(jù)，異常攔截服務(wù)通過配置監(jiān)控項(xiàng)來檢測(cè)數(shù)據(jù)是否出現(xiàn)異常。一旦染色數(shù)據(jù)異常，系統(tǒng)會(huì)觸發(fā)攔截措施并發(fā)出告警。

⑦ 異常止損：在觸發(fā)攔截和告警后，系統(tǒng)會(huì)通過關(guān)聯(lián)染色I(xiàn)D和變更上線的關(guān)系，攔截繼續(xù)放量以及通知業(yè)務(wù)方針對(duì)本次上線的配置回滾。

針對(duì)每次線上配置的變更，都會(huì)有一段觀察期。這個(gè)觀察期的長(zhǎng)短需要適度，以確保數(shù)據(jù)的可靠性。過短的觀察期會(huì)影響數(shù)據(jù)的置信度，而過長(zhǎng)則可能降低研發(fā)效率。一般而言，每次變更后需要等待10分鐘的觀察期，然后再逐步增加線上流量。因此，變更攔截模塊對(duì)數(shù)據(jù)時(shí)效性的要求非常高，要求數(shù)據(jù)的端到端傳輸時(shí)效在3分鐘以內(nèi)，以確保有足夠的數(shù)據(jù)累積時(shí)間，從而提升監(jiān)控指標(biāo)的可信度。同時(shí)，染色I(xiàn)D的數(shù)據(jù)指標(biāo)項(xiàng)不僅涵蓋了基礎(chǔ)的PV指標(biāo)（如崩潰次數(shù)和APP啟動(dòng)用戶數(shù)），還擴(kuò)展至UV級(jí)別的指標(biāo)（如受崩潰影響的用戶數(shù)收斂情況和APP用戶啟動(dòng)數(shù)）。多個(gè)指標(biāo)維度下UV的計(jì)算也給數(shù)據(jù)鏈路的時(shí)效性和準(zhǔn)確性帶來了挑戰(zhàn)。具體的數(shù)據(jù)流設(shè)計(jì)如下所示：

△變圖更攔截?cái)?shù)據(jù)流設(shè)計(jì)

變更攔截的數(shù)據(jù)流主要分為兩個(gè)部分：

（1）實(shí)時(shí)指標(biāo)計(jì)算服務(wù)；

（2) ID生成服務(wù)。

ID生成服務(wù)

ID生成服務(wù)主要用于將廠內(nèi)的CUID生成INT類型的數(shù)字，從而存儲(chǔ)到Bitmap的數(shù)據(jù)結(jié)構(gòu)中。整個(gè)服務(wù)需要滿足以下條件：

（1）CUID-ID的的映射全局唯一，不會(huì)出現(xiàn)重復(fù)的ID，且ID的整體趨勢(shì)遞增。

（2）高并發(fā)低延時(shí)。核心數(shù)據(jù)在計(jì)算節(jié)點(diǎn)內(nèi)存中進(jìn)行產(chǎn)出，減少數(shù)據(jù)庫(kù)壓力。

（3）高可用，服務(wù)基于云上分布式架構(gòu)，即使存儲(chǔ)mysql宕機(jī)，也能容忍一段時(shí)間數(shù)據(jù)庫(kù)不可用。

在實(shí)時(shí)流中，在接收到原始數(shù)據(jù)時(shí)，先根據(jù)CUID進(jìn)行keyby分發(fā)，將相同的CUID分發(fā)到同一個(gè)計(jì)算節(jié)點(diǎn)。對(duì)于每個(gè)計(jì)算節(jié)點(diǎn)：

（1）優(yōu)先查詢自身內(nèi)存中的緩存的映射關(guān)系，若不存在，則查詢r(jià)edis。

（2）若redis不存在映射關(guān)系，則訪問生成新ID服務(wù)。

（3）服務(wù)請(qǐng)求hash到號(hào)段節(jié)點(diǎn)上，每次去DB拿固定長(zhǎng)度的ID List進(jìn)行分發(fā)，然后把最大的ID持久化下來，也就是并非每個(gè)ID都做持久化，僅僅持久化一批ID中最大的那一個(gè)。這個(gè)方式有點(diǎn)像游戲里的定期存檔功能，只不過存檔的是未來某個(gè)時(shí)間下發(fā)給用戶的ID，這樣極大地減輕了DB持久化的壓力。

（4）最終將映射關(guān)系寫入到Redis存儲(chǔ)中。

實(shí)時(shí)指標(biāo)計(jì)算服務(wù)

在數(shù)據(jù)處理流程中，端上傳的日志數(shù)據(jù)經(jīng)由日志中臺(tái)進(jìn)行轉(zhuǎn)發(fā)，進(jìn)而分發(fā)到性能的各個(gè)消息隊(duì)列中。實(shí)時(shí)計(jì)算服務(wù)訂閱這些消息隊(duì)列中的數(shù)據(jù)，以多級(jí)聚合方式進(jìn)行維度指標(biāo)的計(jì)算：

（1）數(shù)據(jù)分發(fā)與映射：首先，從消息隊(duì)列中獲取原始數(shù)據(jù)。根據(jù)CUID進(jìn)行keyby分發(fā)，將相同的CUID分發(fā)到同一個(gè)計(jì)算節(jié)點(diǎn)。防止相同的CUID同時(shí)訪問ID-Mapping服務(wù)，導(dǎo)致CUID-ID的的映射全局不唯一。

（2）本地聚合：對(duì)數(shù)據(jù)進(jìn)行解析獲得指標(biāo)和維度，然后在每個(gè)計(jì)算節(jié)點(diǎn)上進(jìn)行本地窗口聚合操作，將具有相同維度(版本、操作系統(tǒng)、染色I(xiàn)D等)的CUID匯總成Bitmap格式。本地聚合的目的在于減少后續(xù)的keyby shuffle階段的數(shù)據(jù)量。

（3）全局聚合：狀態(tài)服務(wù)維護(hù)實(shí)時(shí)流的運(yùn)行時(shí)狀態(tài)信息和歷史數(shù)據(jù)的Bitmap結(jié)果。將實(shí)時(shí)數(shù)據(jù)與歷史數(shù)據(jù)進(jìn)行全局聚合，從而得到最終的結(jié)果數(shù)據(jù)。同時(shí)，新的Bitmap結(jié)重新寫入狀態(tài)服務(wù)。其中，運(yùn)行時(shí)狀態(tài)信息保證了在實(shí)時(shí)流斷流或重啟時(shí)，能夠恢復(fù)上次運(yùn)行狀態(tài)。加上可重入的數(shù)據(jù)源和冪等的數(shù)據(jù)輸出，確保了數(shù)據(jù)流的不丟不重。

通過上述服務(wù)，當(dāng)新的變更上線導(dǎo)致端上異常數(shù)據(jù)突增時(shí)，變更攔截服務(wù)能夠在分鐘級(jí)內(nèi)對(duì)異常上線進(jìn)行監(jiān)控告警以及攔截。此外，除了向業(yè)務(wù)方披露攔截的數(shù)據(jù)指標(biāo)，我們也希望中臺(tái)能夠直接協(xié)助業(yè)務(wù)方定位排查出問題的根因。

2.3 問題自動(dòng)分發(fā)

問題自動(dòng)分發(fā)的核心思路是：建立端上各個(gè)模塊、組件、類方法和研發(fā)測(cè)試人員的映射關(guān)系，當(dāng)發(fā)生線上問題時(shí)，通過聚類規(guī)則將經(jīng)過反混淆之后問題直接指向?qū)е聠栴}發(fā)生的組件、模塊以及負(fù)責(zé)該模塊的研發(fā)測(cè)試人員。

△線上問題實(shí)時(shí)自動(dòng)分發(fā)數(shù)據(jù)流

問題分發(fā)的數(shù)據(jù)流主要分為四個(gè)部分：

（1）映射文件寫入存儲(chǔ)

（2）線上異常反混淆

（3）端組件關(guān)系建立

（4）問題分發(fā)

其中(1)(2)步驟是為了將線上異常解析為可讀的形式。(3)(4)步驟為將可讀的堆棧進(jìn)行聚類以及分發(fā)。

映射文件寫入存儲(chǔ)

在技術(shù)背景的實(shí)時(shí)反混淆介紹中，為了將經(jīng)過混淆的異常信息恢復(fù)成可讀的形式，關(guān)鍵在于使用映射文件。映射文件分為兩種：一種是針對(duì)每個(gè)APP發(fā)版時(shí)生成的映射文件，用于對(duì)該版本的APP自身的異常信息進(jìn)行反混淆；另一種是操作系統(tǒng)發(fā)版產(chǎn)生的映射文件，用于系統(tǒng)級(jí)別的異常信息的反混淆。當(dāng)APP發(fā)版或操作系統(tǒng)升級(jí)時(shí)，通過配置流水線將相應(yīng)的映射文件寫入映射文件緩存中。 APP的版本又有線上和線下的區(qū)別。針對(duì)線上發(fā)版的APP版本，其版本的特點(diǎn)表現(xiàn)為每個(gè)版本的發(fā)版周期較長(zhǎng)，線上異常數(shù)量較多，同時(shí)對(duì)數(shù)據(jù)解析的實(shí)時(shí)性要求較高。為滿足這些特點(diǎn)，將線上發(fā)版的映射文件存儲(chǔ)于高性能的Redis集群中。對(duì)于廠內(nèi)線下測(cè)試發(fā)版的APP版本，其版本特點(diǎn)體現(xiàn)在研發(fā)測(cè)試人員都能發(fā)版，導(dǎo)致版本數(shù)量相對(duì)較多。然而，與線上環(huán)境不同的是，線下測(cè)試環(huán)境中構(gòu)造的異常較少，而對(duì)數(shù)據(jù)解析的實(shí)時(shí)性要求較低。鑒于這些特點(diǎn)，更適合將線下測(cè)試發(fā)版的映射文件存儲(chǔ)于性能稍弱但更適合存儲(chǔ)大量數(shù)據(jù)的Hbase集群中。

線上異常反混淆

在端發(fā)生線上異常時(shí)，端會(huì)上報(bào)兩條信息流。一條是崩潰的指標(biāo)數(shù)據(jù)流，一條是定位堆棧的文件流。指標(biāo)數(shù)據(jù)流的特點(diǎn)是上傳信息快，包含核心信息以及簡(jiǎn)化版的異常信息，但異常信息量不全。而文件流的特點(diǎn)是，上傳速度偏慢，但是異常信息完整（2M）。結(jié)合這兩種信息流，可以獲得完整的線上異常信息，供業(yè)務(wù)分析使用。但是由于兩條信息流是異步上報(bào)，經(jīng)常面臨數(shù)據(jù)流亂序到達(dá)的問題。因此，為了解決亂序問題，我們?cè)O(shè)計(jì)了狀態(tài)服務(wù)。

△狀態(tài)服務(wù)數(shù)據(jù)流設(shè)計(jì)

狀態(tài)服務(wù)的主要目的是處理雙流亂序的數(shù)據(jù)，以確保它們能夠被正確關(guān)聯(lián)。其核心流程如下：

（1）同時(shí)間窗口數(shù)據(jù)關(guān)聯(lián)：從消息隊(duì)列中訂閱數(shù)據(jù)后，首先會(huì)對(duì)處于計(jì)算節(jié)點(diǎn)同一個(gè)時(shí)間窗口的數(shù)據(jù)進(jìn)行關(guān)聯(lián)，若關(guān)聯(lián)成功，則數(shù)據(jù)直接發(fā)往下游進(jìn)行計(jì)算。

（2）同歷史未關(guān)聯(lián)的數(shù)據(jù)關(guān)聯(lián)：若未成功，則查詢狀態(tài)服務(wù)中之前窗口中尚未被關(guān)聯(lián)的數(shù)據(jù)進(jìn)行關(guān)聯(lián)，若關(guān)聯(lián)成功，發(fā)往下游，狀態(tài)存儲(chǔ)中清除關(guān)聯(lián)數(shù)據(jù)。

（3）未關(guān)聯(lián)數(shù)據(jù)寫入狀態(tài)存儲(chǔ)：若未成功，則將未關(guān)聯(lián)的數(shù)據(jù)寫入到狀態(tài)存儲(chǔ)中，等待被將來的數(shù)據(jù)進(jìn)行關(guān)聯(lián)。

此外，狀態(tài)存儲(chǔ)也不能無限的增長(zhǎng)，需要有過期淘汰的策略，在該場(chǎng)景下，我們?cè)O(shè)置的是30min的TTL，能夠關(guān)聯(lián)到99.9%以上的數(shù)據(jù)。 在成功關(guān)聯(lián)雙流數(shù)據(jù)后，緊接著是對(duì)堆棧進(jìn)行反混淆解析。反混淆的目標(biāo)是將經(jīng)過混淆后的異常信息還原為可讀的形式。在反混淆過程中，各種類型異常的解析算法工具（如騰訊Bugly、谷歌CrashPad）通常能夠在秒級(jí)別（約10秒）內(nèi)完成解析操作。然而，在實(shí)時(shí)數(shù)據(jù)流處理中，僅僅滿足秒級(jí)的解析時(shí)效性是不夠的，需要將解析速度提升至毫秒級(jí)。因此，中臺(tái)實(shí)時(shí)流中對(duì)反混淆解析進(jìn)行了升級(jí)，包含算法升級(jí)適配實(shí)時(shí)流以及多級(jí)緩存在構(gòu)建。 多級(jí)緩存由計(jì)算節(jié)點(diǎn)內(nèi)存，Redis以及Hbase構(gòu)成。其中，根據(jù)不同的緩存命中情況，反混淆解析的性能會(huì)有所不同。如果堆棧對(duì)應(yīng)的映射文件在計(jì)算節(jié)點(diǎn)內(nèi)存中命中，解析可以在<10ms內(nèi)完成。若在Redis或Hbase中命中，則解析時(shí)間會(huì)略有延長(zhǎng)，達(dá)到秒級(jí)別（約10秒），那么最理想的方式是將所有的映射文件都在計(jì)算節(jié)點(diǎn)內(nèi)存中被命中。然而，由于每個(gè)版本都有對(duì)應(yīng)的映射文件，且每個(gè)線上APP都有數(shù)十個(gè)版本，每個(gè)映射文件大小約為300MB，這使得無法將線上流量所需的所有映射文件都加載到算子內(nèi)存中。為了解決這一問題，我們對(duì)解析算法進(jìn)行了多級(jí)索引的優(yōu)化。這種優(yōu)化策略將整個(gè)映射文件進(jìn)行了細(xì)粒度拆分，僅將異常堆棧命中的映射文件行信息加載到內(nèi)存中。因此，解析算法現(xiàn)在不再需要將整個(gè)映射文件完全存入內(nèi)存。相反，它只需存儲(chǔ)一級(jí)索引和二級(jí)索引的關(guān)系，以及命中堆棧后獲得的結(jié)果數(shù)據(jù)。這一方式在顯著提高內(nèi)存利用效率的同時(shí)，也解決了計(jì)算節(jié)點(diǎn)內(nèi)存不足的問題。

△多級(jí)索引查詢

但是，隨著線上任務(wù)長(zhǎng)時(shí)間運(yùn)行時(shí)，我們注意到程序性能逐漸下降，導(dǎo)致實(shí)時(shí)流任務(wù)的數(shù)據(jù)處理經(jīng)常出現(xiàn)延遲。我們發(fā)現(xiàn)問題的根本原因是計(jì)算節(jié)點(diǎn)緩存中的映射文件被頻繁替換，導(dǎo)致緩存命中率低。因此，我們采用了更為適合業(yè)務(wù)場(chǎng)景的緩存替代算法---W-TinyLFU代替常規(guī)的LRU緩存替代策略。

△W-TinyLFU算法

相比LRU算法，W-TinyLFU：

1、熱點(diǎn)數(shù)據(jù)適應(yīng)性更強(qiáng)：在高流量的場(chǎng)景中，一些熱點(diǎn)數(shù)據(jù)項(xiàng)可能會(huì)在短時(shí)間內(nèi)被多次訪問。與LRU只關(guān)注最近的訪問，W-TinyLFU通過維護(hù)頻繁訪問計(jì)數(shù)來更好地捕獲這種熱點(diǎn)數(shù)據(jù)的特征，從而更好地適應(yīng)瞬時(shí)的流量變化。

2、低頻數(shù)據(jù)保護(hù)：LRU在遇到新數(shù)據(jù)時(shí)，會(huì)立即淘汰最近最少使用的數(shù)據(jù)，這可能導(dǎo)致低頻數(shù)據(jù)被頻繁淘汰。W-TinyLFU通過維護(hù)一個(gè)近似的頻率計(jì)數(shù)，可以更好地保護(hù)低頻數(shù)據(jù)，防止它們被過早地淘汰。

3、適應(yīng)性更強(qiáng)：W-TinyLFU在面對(duì)訪問模式的變化時(shí)，能夠更快地適應(yīng)新的訪問模式。它在長(zhǎng)時(shí)間內(nèi)持續(xù)觀察訪問模式，并逐漸調(diào)整數(shù)據(jù)項(xiàng)的權(quán)重，以更好地反映最近的訪問模式。

4、寫入操作考慮：LRU通常對(duì)寫入操作的適應(yīng)性較差，因?yàn)閷懭氩僮骺赡軐?dǎo)致數(shù)據(jù)被立即淘汰。W-TinyLFU考慮了寫入操作，通過維護(hù)寫入時(shí)的頻繁訪問計(jì)數(shù)，可以更好地處理寫入操作。

5、內(nèi)存效率：W-TinyLFU使用了一些壓縮技術(shù)來存儲(chǔ)頻繁訪問計(jì)數(shù)，從而在一定程度上減少了內(nèi)存占用。

經(jīng)過對(duì)線上異常進(jìn)行反混淆處理后，我們獲得了可讀的堆棧信息。接下來，我們可以對(duì)這些可讀的堆棧信息進(jìn)行問題聚類和分發(fā)。

端組件關(guān)系建立

組件關(guān)系變更的數(shù)據(jù)來源分為兩個(gè)部分：

（1）全量數(shù)據(jù)：在APP進(jìn)行發(fā)版時(shí)，通過EasyBox等工具將組件、模塊等關(guān)系從包中解析出來，將該版本的組件信息上傳到組件管理平臺(tái)，觸發(fā)組件管理平臺(tái)的全量同步，將組件信息寫入消息隊(duì)列中。中臺(tái)通過訂閱組件數(shù)據(jù)，建立類方法<->組件、模塊、研發(fā)人員、測(cè)試人員的關(guān)系，寫入到存儲(chǔ)中。

（2）增量數(shù)據(jù)：在組件管理平臺(tái)進(jìn)行人為的修改，例如修改組件類的研發(fā)、測(cè)試負(fù)責(zé)人等，觸發(fā)增量同步，變更的數(shù)據(jù)寫入消息隊(duì)列。

通過上述數(shù)據(jù)同步，建立了類方法<->人的映射。

問題分發(fā)

通過數(shù)據(jù)流的反混淆解析，我們成功地將異常信息從二進(jìn)制地址轉(zhuǎn)換為可讀的信息。接下來，借助聚類規(guī)則算法，我們將不同的異常堆棧逐行遍歷，并優(yōu)先將其聚類到廠內(nèi)維護(hù)的組件和模塊中所包含的類中。在此過程中，我們建立了線上問題<->類之間的關(guān)系。而在端組件關(guān)系建立的流程中，我們成功地構(gòu)建了類方法<->研發(fā)測(cè)試人員之間的映射關(guān)系。將這兩者的關(guān)系結(jié)合起來，我們獲得了問題<->人員之間的關(guān)聯(lián)。因此，當(dāng)線上出現(xiàn)問題時(shí)，無需人工干預(yù)，系統(tǒng)可以直接將該問題指向負(fù)責(zé)該問題模塊的負(fù)責(zé)人。負(fù)責(zé)人隨后可以根據(jù)反混淆后的異常信息，進(jìn)行問題的排查和修復(fù)工作。

GEEK TALK

03

總結(jié)與展望

本文主要介紹了性能中臺(tái)在處理異常上線過程中，針對(duì)變更攔截和問題分發(fā)方面做的一些努力。當(dāng)然，后面我們還會(huì)繼續(xù)更好的服務(wù)業(yè)務(wù)，如：

1、提升影響力：對(duì)接更多的上線變更平臺(tái)以及落地更多的APP。

2、提升場(chǎng)景覆蓋度：覆蓋卡頓、啟動(dòng)速度、網(wǎng)絡(luò)性能、搜索性能等更多的核心業(yè)務(wù)場(chǎng)景。

3、提升問題聚類以及分發(fā)策略的準(zhǔn)確度：將線上問題分發(fā)的更加合理與準(zhǔn)確。

希望，性能中臺(tái)持續(xù)不斷優(yōu)化，為保障APP的質(zhì)量做出貢獻(xiàn)。