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

01

背景

1.1 業(yè)務背景

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

1.2 技術背景

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

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

直接使用位運算，使用蘋果手機的程序員用戶:（0000000110B & 0000000010B = 0000000010B）

異常反混淆：主要用于問題分發(fā)階段。APP廠商在發(fā)布應用程序包時，通常會對包進行混淆操作，這是為了提高APP應用的安全性和減少反編譯的風險。混淆是將源代碼中的符號、名稱和結構等轉換為難以理解的形式，使得反編譯后的代碼難以還原為原始的源代碼，但是APP上報的異常信息也被混淆了。反混淆操作是將混淆后的異常信息還原為可讀的形式，使開發(fā)人員能夠更準確地分析問題的原因，并迅速采取正確的修復措施。在APP產出應用程序包時，同時也會產生一份用于反混淆異常信息的映射文件（密碼本），通過映射文件 + 解析算法對混淆的異常進行解析，即可得到已讀的異常堆棧。

△異常信息反混淆過程

1.3 名詞解釋

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

移動線上質量平臺:移動線上質量平臺是移動端APP發(fā)包后，用來查看、分析包質量數(shù)據、進行核心指標監(jiān)控/報警、變更異常攔截。

日志中臺：指端日志中臺，包括端日志全生命周期的能力建設。包括打點SDK / 打點server/日志管理平臺等核心組件。

Tekes平臺：App端研發(fā)平臺，提供包組件管理等基礎設施。

GEEK TALK

02

系統(tǒng)設計

2.1整體流程

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

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

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

2.2異常上線變更攔截

異常上線變更攔截的核心思路是：為每次上線變更生成獨特的染色ID，通過對每個染色ID的性能核心數(shù)據進行攔截與監(jiān)控。

△異常上線變更攔截流程設計圖

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

① 變更上線注冊：針對廠內各個配置變更平臺，需要在每次上線配置生效之前，將上線信息在染色通用服務進行注冊。

② 獲取染色ID：染色通用服務通過HTTP接口為每次上線注冊生成通用的染色ID，并將其返回給上線變更平臺。

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

④ 染色日志上報：業(yè)務SDK會判定染色是否生效，如果生效，則在涉及性能核心場景的日志中附加染色ID信息，然后通過UBC-SDK上報。這些日志會通過日志中臺實時轉發(fā)，并寫入消息隊列。

⑤ 實時指標計算：性能中臺會實時訂閱消息隊列中的核心性能數(shù)據，例如崩潰、APP啟動次數(shù)等，然后針對每個染色ID，根據多個維度（如產品線、APP版本、操作系統(tǒng)、地域等）形成性能聚合指標，并將其寫入持久存儲。

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

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

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

△變圖更攔截數(shù)據流設計

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

（1）實時指標計算服務；

（2) ID生成服務。

ID生成服務

ID生成服務主要用于將廠內的CUID生成INT類型的數(shù)字，從而存儲到Bitmap的數(shù)據結構中。整個服務需要滿足以下條件：

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

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

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

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

（1）優(yōu)先查詢自身內存中的緩存的映射關系，若不存在，則查詢redis。

（2）若redis不存在映射關系，則訪問生成新ID服務。

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

（4）最終將映射關系寫入到Redis存儲中。

實時指標計算服務

在數(shù)據處理流程中，端上傳的日志數(shù)據經由日志中臺進行轉發(fā)，進而分發(fā)到性能的各個消息隊列中。實時計算服務訂閱這些消息隊列中的數(shù)據，以多級聚合方式進行維度指標的計算：

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

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

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

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

2.3 問題自動分發(fā)

問題自動分發(fā)的核心思路是：建立端上各個模塊、組件、類方法和研發(fā)測試人員的映射關系，當發(fā)生線上問題時，通過聚類規(guī)則將經過反混淆之后問題直接指向導致問題發(fā)生的組件、模塊以及負責該模塊的研發(fā)測試人員。

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

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

（1）映射文件寫入存儲

（2）線上異常反混淆

（3）端組件關系建立

（4）問題分發(fā)

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

映射文件寫入存儲

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

線上異常反混淆

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

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

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

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

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

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

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

△多級索引查詢

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

△W-TinyLFU算法

相比LRU算法，W-TinyLFU：

1、熱點數(shù)據適應性更強：在高流量的場景中，一些熱點數(shù)據項可能會在短時間內被多次訪問。與LRU只關注最近的訪問，W-TinyLFU通過維護頻繁訪問計數(shù)來更好地捕獲這種熱點數(shù)據的特征，從而更好地適應瞬時的流量變化。

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

3、適應性更強：W-TinyLFU在面對訪問模式的變化時，能夠更快地適應新的訪問模式。它在長時間內持續(xù)觀察訪問模式，并逐漸調整數(shù)據項的權重，以更好地反映最近的訪問模式。

4、寫入操作考慮：LRU通常對寫入操作的適應性較差，因為寫入操作可能導致數(shù)據被立即淘汰。W-TinyLFU考慮了寫入操作，通過維護寫入時的頻繁訪問計數(shù)，可以更好地處理寫入操作。

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

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

端組件關系建立

組件關系變更的數(shù)據來源分為兩個部分：

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

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

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

問題分發(fā)

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

GEEK TALK

03

總結與展望

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

1、提升影響力：對接更多的上線變更平臺以及落地更多的APP。

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

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

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