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

01

背景

1.1 業務背景

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

1.2 技術背景

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

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

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

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

△異常信息反混淆過程

1.3 名詞解釋

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

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

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

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

GEEK TALK

02

系統設計

2.1整體流程

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

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

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

2.2異常上線變更攔截

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

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

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

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

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

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

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

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

⑥ 異常攔截服務：基于存儲中的染色數據，異常攔截服務通過配置監控項來檢測數據是否出現異常。一旦染色數據異常，系統會觸發攔截措施并發出告警。

⑦ 異常止損：在觸發攔截和告警后，系統會通過關聯染色ID和變更上線的關系，攔截繼續放量以及通知業務方針對本次上線的配置回滾。

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

△變圖更攔截數據流設計

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

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

（2) ID生成服務。

ID生成服務

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

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

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

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

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

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

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

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

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

實時指標計算服務

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

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

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

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

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

2.3 問題自動分發

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

△線上問題實時自動分發數據流

問題分發的數據流主要分為四個部分：

（1）映射文件寫入存儲

（2）線上異常反混淆

（3）端組件關系建立

（4）問題分發

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

映射文件寫入存儲

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

線上異常反混淆

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

△狀態服務數據流設計

狀態服務的主要目的是處理雙流亂序的數據，以確保它們能夠被正確關聯。其核心流程如下：

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

（2）同歷史未關聯的數據關聯：若未成功，則查詢狀態服務中之前窗口中尚未被關聯的數據進行關聯，若關聯成功，發往下游，狀態存儲中清除關聯數據。

（3）未關聯數據寫入狀態存儲：若未成功，則將未關聯的數據寫入到狀態存儲中，等待被將來的數據進行關聯。

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

△多級索引查詢

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

△W-TinyLFU算法

相比LRU算法，W-TinyLFU：

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

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

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

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

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

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

端組件關系建立

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

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

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

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

問題分發

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

GEEK TALK

03

總結與展望

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

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

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

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

希望，性能中臺持續不斷優化，為保障APP的質量做出貢獻。