背景

結(jié)合《螞蟻金服面對(duì)億級(jí)并發(fā)場(chǎng)景的組件體系設(shè)計(jì)》，我們能夠通盤了解支付寶移動(dòng)端基礎(chǔ)組件體系的構(gòu)建之路和背后的思考，本文基于服務(wù)端組建體系的大背景下，著重探討“自動(dòng)化日志手機(jī)與分析”在支付寶 App 內(nèi)的演進(jìn)之路。

支付寶移動(dòng)端技術(shù)服務(wù)框架

這是整個(gè)支付寶移動(dòng)端無(wú)線基礎(chǔ)團(tuán)隊(duì)的技術(shù)架構(gòu)圖，同時(shí)螞蟻金服體系內(nèi)的其他業(yè)務(wù) 口碑、網(wǎng)商銀行、香港支付寶、天弘基金等) 通過移動(dòng)開發(fā)平臺(tái) mPaaS進(jìn)行代碼開發(fā)、打包、灰度發(fā)布、上線、問題修復(fù)、運(yùn)營(yíng)、分析。因此，mPaaS 源自于支付寶移動(dòng)端的核心技術(shù)架構(gòu)，并在 App 全生命周期的每個(gè)環(huán)節(jié)提供特定的能力支持。接下來(lái)，我們將著重分享“日志診斷”和“移動(dòng)分析”兩個(gè)能力背后的架構(gòu)演進(jìn)和選型思考。

支付寶移動(dòng)端技術(shù)服務(wù)框架：數(shù)據(jù)分析框架

如圖所示，即數(shù)據(jù)分析能力的技術(shù)架構(gòu)圖，其中“數(shù)據(jù)同步”、“埋點(diǎn)SDK”、“日志網(wǎng)關(guān)”是移動(dòng)端專屬的能力，其余部分是所有的數(shù)據(jù)分析平臺(tái)都必須具備的數(shù)據(jù)結(jié)構(gòu)。

1. 日志采集

接下來(lái)我們重點(diǎn)分析支付寶移動(dòng)端的日志采集框架，首先第一部分是“日志 SDK”，日志 SDK 會(huì)向業(yè)務(wù)層提供一個(gè)埋點(diǎn)接口，使用起來(lái)就和 Java 里面的 logger.info 的感覺一樣：業(yè)務(wù)層只需要把想記錄的信息傳遞給日志 SDK。日志 SDK 會(huì)在拿到業(yè)務(wù)日志后，去系統(tǒng)內(nèi)部獲取相關(guān)的系統(tǒng)級(jí)別的上下文信息，比如機(jī)型、操作系統(tǒng)版本、App 版本、手機(jī)分辨率、用戶ID (如果用戶登錄了)、設(shè)備ID、上一個(gè)頁(yè)面、當(dāng)前頁(yè)面等，接著把這些信息與業(yè)務(wù)日志內(nèi)容整合成一個(gè)埋點(diǎn)，然后記錄到設(shè)備的硬盤上。對(duì)，只是記錄到硬盤上，并沒有上報(bào)到服務(wù)端。

日志 SDK 會(huì)在合適的時(shí)機(jī)，去和日志網(wǎng)關(guān)交互，判斷獲取什么樣的日志、什么級(jí)別的日志可以上報(bào)。如果可以上報(bào)，是以什么頻率上報(bào)、在什么網(wǎng)絡(luò)條件下上報(bào)。因此通過日志 SDK 與日志網(wǎng)關(guān)的交付，我們可以來(lái)實(shí)現(xiàn)日志的策略式降級(jí)。日志的策略式降級(jí)這點(diǎn)對(duì)于支付寶特別重要，因?yàn)槟壳爸Ц秾毜捏w量，日常的日志上報(bào)量為約 30W 條日志/s；而在大促的時(shí)候，日志量會(huì)是日常的幾十倍！ 所以，如果大促期間不采用任何的日志降級(jí)策略的話，我們的帶寬會(huì)被日志打包，支付寶的正常業(yè)務(wù)功能就不可用了。

由此，我們可以總結(jié)，在大促高并發(fā)場(chǎng)景下，我們需要只保留關(guān)鍵日志的上傳，其余日志統(tǒng)統(tǒng)降級(jí)。即使是日常業(yè)務(wù)處理，我們也只允許日志在 WIFI 條件下上報(bào)，防止發(fā)生流量相關(guān)的投訴。

埋點(diǎn)網(wǎng)關(guān)除了提供日志上報(bào)的策略開關(guān)能力之外，就是接收客戶端的日志。它在接受到客戶端日志之后，會(huì)對(duì)日志內(nèi)容進(jìn)行校驗(yàn)，發(fā)現(xiàn)無(wú)效的日志會(huì)丟棄掉。而對(duì)有效合法的埋點(diǎn)，會(huì)根據(jù)客戶端上報(bào)的公網(wǎng) IP 地址，反解出城市級(jí)別的地址位置信息并添加到埋點(diǎn)中，然后將埋點(diǎn)存放在它自己的硬盤上。

2. 埋點(diǎn)分類

經(jīng)過多年的實(shí)踐，支付寶把日志埋點(diǎn)分為了四類。

（1）行為埋點(diǎn)：用于監(jiān)控業(yè)務(wù)行為，即業(yè)務(wù)層傳遞的日志埋點(diǎn)屬于行為埋點(diǎn)，行為埋點(diǎn)屬于“手動(dòng)埋點(diǎn)”，需要業(yè)務(wù)層開發(fā)同學(xué)自己開發(fā)。不過也不是全部的業(yè)務(wù)行為都需要業(yè)務(wù)方手動(dòng)開發(fā)，有一些具備非常通用性的業(yè)務(wù)事件，支付寶把它們的埋點(diǎn)記錄放到了框架層，如報(bào)活事件、登錄事件。因此，行為埋點(diǎn)也可以叫做 "半自動(dòng)埋點(diǎn)"。

（2）自動(dòng)化埋點(diǎn)：屬于“全自動(dòng)化埋點(diǎn)”，用于記錄一些通用的頁(yè)面級(jí)別、組件級(jí)別的行為，比如頁(yè)面打開、頁(yè)面關(guān)閉、頁(yè)面耗時(shí)、組件點(diǎn)擊等。

（3）性能埋點(diǎn)：屬于“全自動(dòng)化埋點(diǎn)”，用于記錄 App 的電量使用情況、流量使用、內(nèi)存使用、啟動(dòng)速度等。

（4）異常埋點(diǎn)：屬于“全自動(dòng)化埋點(diǎn)”，嚴(yán)格上講，也算是性能埋點(diǎn)的一種。但是它記錄的是最關(guān)鍵的最直接影響用戶的性能指標(biāo)，比如 App 的閃退情況、卡死、卡頓情況等。這類埋點(diǎn)，就屬于即時(shí)大促期間也不能降級(jí)的埋點(diǎn)！

圖中的代碼示例即為一條行為埋點(diǎn)樣例，大家可以看到，埋點(diǎn)實(shí)際上就是一條 CSV 文本。我們可以看到里面有日志網(wǎng)關(guān)添加進(jìn)行的地址位置信息內(nèi)容，也有日志 SDK 給添加的客戶端設(shè)備信息。

3. 日志處理模型

下面我們來(lái)整體了解支付寶內(nèi)部日志處理的通用流程：

（1）日志切分

我們已經(jīng)了解到，埋點(diǎn)實(shí)際上即為一段 CSV 文本。而所謂日志切分呢，即將 CSV 格式的文本轉(zhuǎn)成 KV，通俗點(diǎn)說就是內(nèi)存里面的 HASHMAP。這個(gè)切分的過程，可以直接根據(jù)逗號(hào)進(jìn)行切換，當(dāng)然也還有很多其他的辦法。

（2）日志切換

日志埋點(diǎn)中的內(nèi)容，并不是直接可以拿來(lái)進(jìn)行分析的。比如客戶端啟動(dòng)時(shí)間，相關(guān)數(shù)據(jù)是按照毫秒級(jí)別的顆粒度進(jìn)行上報(bào)，但實(shí)際應(yīng)用上我們只需要把數(shù)據(jù)分析到某個(gè)特定區(qū)間內(nèi)的個(gè)數(shù)，所以在處理之前一般會(huì)做一個(gè)具體啟動(dòng)時(shí)間到截止時(shí)間范圍編碼的映射。除了這種轉(zhuǎn)換之外，還會(huì)有一些白名單、黑名單之類的過濾轉(zhuǎn)換。

（3）維表影射

因?yàn)榭蛻舳瞬⒉荒苣玫綐I(yè)務(wù)方需要分析的所有數(shù)據(jù)維度，如用戶的性別、職業(yè)等內(nèi)容，因此在真實(shí)分析之前，我們可以通過維表映射，將日志埋點(diǎn)中的用戶 ID 映射成業(yè)務(wù)層面的具體屬性來(lái)進(jìn)行后續(xù)的分析。

（4）UID 的濾重

UID 濾重的指標(biāo)有兩種：一種是 PV 指標(biāo)，一種是 UV 指標(biāo)。

UV 指標(biāo)在做具體的計(jì)算之前，要做一步 UID 去重。所謂 UID 去重就是指檢查這個(gè) ID 在一定時(shí)間范圍內(nèi)有沒有出現(xiàn)過，如果出現(xiàn)過，那么這條記錄就必須丟棄了。UV 是有時(shí)間周期的概念的，比如日 UV、小時(shí) UV、分鐘 UV、月 UV 等。

（5）指標(biāo)聚合

在完成了上述的所有過程后，終于要進(jìn)行指標(biāo)的計(jì)算了。計(jì)算的方式包括求和、平均值、最大值、最小值、95 百分位。

（6）結(jié)果寫出

就是指把計(jì)算的指標(biāo)的結(jié)果輸出到各種存儲(chǔ)或者通過接口發(fā)送給 mPaaS 的客戶。目前我們的計(jì)算方式有三大類，實(shí)時(shí)計(jì)算、即時(shí)計(jì)算和離線計(jì)算。下面我會(huì)介紹這三種計(jì)算方式。

• 實(shí)時(shí)計(jì)算

實(shí)時(shí)計(jì)算模式：接收到日志后，模型立即開始進(jìn)行計(jì)算，數(shù)據(jù)結(jié)果將在N分鐘(N<=2)內(nèi)產(chǎn)出，延遲非常的低。

推薦用作實(shí)時(shí)計(jì)算的技術(shù)選型包括：1) Flink 2) Spark 3) Storm (阿里做的 JStorm） 4) akka；其中 akka 適合用作業(yè)務(wù)邏輯較輕的實(shí)時(shí)監(jiān)控和報(bào)警；關(guān)鍵的業(yè)務(wù)大盤、日志翻譯回放這些都用 Flink 做比較好。

簡(jiǎn)單總結(jié)如下：

實(shí)時(shí)計(jì)算的優(yōu)勢(shì)是產(chǎn)出結(jié)果速度快、資源消耗少、靈活度中等；
實(shí)時(shí)計(jì)算的劣勢(shì)是學(xué)習(xí)曲線相對(duì)陡峭、維護(hù)成本較高、配置復(fù)雜度高。

• 離線計(jì)算

離線計(jì)算模式：接收到日志后，直接保存下來(lái)，不做任何處理。待日志量積攢一段時(shí)間后，模型可進(jìn)行一次性處理多日或者多月的日志數(shù)據(jù)。

推薦用作實(shí)時(shí)計(jì)算的技術(shù)選型包括: 1) Flink 2) Spark 3) Hive 4) Hadoop；大家看到了 FLINKSPARK 也出現(xiàn)在了實(shí)時(shí)模型的推薦技術(shù)選擇中。這兩個(gè)技術(shù)呢，分別從不同的起點(diǎn)出發(fā)，達(dá)到了相同的終點(diǎn)。

Flink 一開始是只做實(shí)時(shí)計(jì)算的，后來(lái)他開始提供批量離線計(jì)算能力；Spark 則正好相反。我們目前呢，還是充分利用每個(gè)技術(shù)棧的最大優(yōu)勢(shì)，離線還是選擇 Spark，而不是 Flink。在這里多說兩句，之前有一個(gè)經(jīng)典架構(gòu)是 “Lambda”模型，是指實(shí)時(shí)計(jì)算的結(jié)果要在離線里面再算一遍，這是因?yàn)橹翱倳?huì)出現(xiàn)實(shí)時(shí)計(jì)算丟數(shù)據(jù)、計(jì)算不準(zhǔn)的情況，所以實(shí)時(shí)計(jì)算出來(lái)的結(jié)果只是用來(lái)觀察一個(gè)趨勢(shì)，再等第二天用離線的結(jié)果做補(bǔ)充，從而確保業(yè)務(wù)方能夠看到準(zhǔn)確的數(shù)據(jù)。但是在谷歌的 data-flow 計(jì)算模型的論文出來(lái)之后，目前市面上的實(shí)時(shí)計(jì)算引擎都具備了 "exactly-once" 的計(jì)算能力，換句話說，實(shí)時(shí)計(jì)算不會(huì)再出現(xiàn)丟數(shù)據(jù)以及計(jì)算不準(zhǔn)的問題了。目前雖然還有“Lambda”模型，即數(shù)據(jù)會(huì)流向?qū)崟r(shí)計(jì)算、離線計(jì)算兩個(gè)引擎，但是離線不再是為實(shí)時(shí)計(jì)算做補(bǔ)充，而是為了充分利用它的性能，計(jì)算多日、多月的指標(biāo)。

簡(jiǎn)單總結(jié)如下：

離線計(jì)算的優(yōu)勢(shì)是 計(jì)算性能高、學(xué)習(xí)難度低；
離線計(jì)算的劣勢(shì)是 消耗資源大、延遲高、靈活度偏低。

• 即時(shí)計(jì)算

即時(shí)計(jì)算模式：接收到日志后，只做簡(jiǎn)單的預(yù)處理，比如日志切分，之后就直接入庫(kù)。在需要展示界面的時(shí)候，根據(jù)用戶配置的過濾和聚合規(guī)則即時(shí)進(jìn)行數(shù)據(jù)處理。

推薦用作即時(shí)計(jì)算的的技術(shù)選型包括: Clickhouse (來(lái)自俄羅斯 yandex)、Apache Druid (來(lái)自 MetaMarket)、 Pinot (來(lái)自 ：LinkedIn)。支付寶內(nèi)部將即時(shí)計(jì)算模型應(yīng)用到下鉆分析、漏斗分析這些場(chǎng)景中，有時(shí)候也直接把它當(dāng)做 OLAP 數(shù)據(jù)庫(kù)使用。

簡(jiǎn)單總結(jié)如下：

即時(shí)計(jì)算的優(yōu)勢(shì)是超高靈活度、任務(wù)維度UV聚合、無(wú)限下鉆能力、交付式的查詢延遲(15s內(nèi))、學(xué)習(xí)成本低；
即時(shí)計(jì)算的劣勢(shì)是資源消耗巨大、延遲中等無(wú)法用于做實(shí)時(shí)監(jiān)控與報(bào)警、維度成本高，結(jié)構(gòu)復(fù)雜。

這是目前支付寶內(nèi)部的一個(gè)即時(shí)計(jì)算框架的技術(shù)架構(gòu)圖。從圖中可以看出來(lái)目前即時(shí)計(jì)算的技術(shù)架構(gòu)包括用來(lái)接收數(shù)據(jù)寫入的實(shí)時(shí)日志節(jié)點(diǎn)（Read-time Nodes）、用于存儲(chǔ)歷史數(shù)據(jù)的深度存儲(chǔ)（HDFS、AFS、OSS 等多種類型）、用來(lái)對(duì)歷史數(shù)據(jù)（一天以前的數(shù)據(jù)）提供查詢分析能力的歷史節(jié)點(diǎn)（historical）。這個(gè)計(jì)算框架完全的支持 MySQL 協(xié)議，用戶可以直接用 MySQL 客戶端對(duì)其進(jìn)行操作。還有一個(gè)重要特性是，他可以對(duì)任意的外部數(shù)據(jù)聯(lián)合進(jìn)行分析。

• 日志處理模型

我們?cè)倏偨Y(jié)一下三種計(jì)算模式：

實(shí)時(shí)計(jì)算模型：數(shù)據(jù)攝入后立即按照預(yù)定規(guī)則執(zhí)行計(jì)算，并在N分鐘內(nèi)產(chǎn)出需要的計(jì)算結(jié)果。

適用場(chǎng)景: 實(shí)時(shí)監(jiān)控預(yù)警、鏈路追蹤

優(yōu)勢(shì): 消耗資源少、產(chǎn)出速度快

劣勢(shì): 配置復(fù)雜度高，靈活度低

離線計(jì)算模型：數(shù)據(jù)攝入后積攢N 小時(shí)/天 后按照預(yù)定規(guī)則進(jìn)行批量處理。

適用場(chǎng)景: 用戶分群、數(shù)據(jù)集市

優(yōu)勢(shì):性能高、學(xué)習(xí)成本低

劣勢(shì): 延遲高、靈活度低

即時(shí)計(jì)算模型：數(shù)據(jù)攝入后只做簡(jiǎn)單的預(yù)處理立即入庫(kù)，待查詢時(shí)根據(jù)查詢需求實(shí)時(shí)計(jì)算出指標(biāo)。

適用場(chǎng)景: 下鉆分析、漏斗分析

優(yōu)勢(shì): 靈活度高、學(xué)習(xí)成本低

劣勢(shì): 資源消耗巨大、延遲中

希望大家能夠根據(jù)我們的推薦選擇適合的技術(shù)棧。

• 動(dòng)態(tài)埋點(diǎn)

說完了我們目前的埋點(diǎn)類型、埋點(diǎn)計(jì)算模型，下面來(lái)說一下我們目前在內(nèi)部使用的下一代埋點(diǎn)框架，動(dòng)態(tài)埋點(diǎn)。

我們先針對(duì)以上四個(gè)問題進(jìn)行思路串聯(lián)，每個(gè)問題我也給出了相應(yīng)的思路和解決辦法。那么，這些答案是針對(duì)以上問題的最優(yōu)解或者唯一解嗎？很顯然不是，因?yàn)檫@些解法都會(huì)帶來(lái)開發(fā)量。而對(duì)于客戶端來(lái)說，新的開發(fā)量就要發(fā)布版本，同時(shí)開發(fā)新的埋點(diǎn)，也可能會(huì)導(dǎo)致 App 內(nèi)部的埋點(diǎn)臃腫不堪。

什么是動(dòng)態(tài)埋點(diǎn)呢？有三個(gè)核心概念1) 埋點(diǎn)集、2) 動(dòng)態(tài)埋點(diǎn)上報(bào)規(guī)則、3) 指標(biāo)計(jì)算動(dòng)態(tài)配置。

有了以上三項(xiàng)能力和配置，我們便可以根據(jù)現(xiàn)有的埋點(diǎn)集來(lái)配置某個(gè)鏈路的監(jiān)控埋點(diǎn)，并依據(jù)這個(gè)復(fù)雜埋點(diǎn)來(lái)定義具體的指標(biāo)的計(jì)算規(guī)則，從而做到不用增加開發(fā)量，同樣可以快速監(jiān)控新的指標(biāo)的效果。不僅如此，我們還能夠讓埋點(diǎn)變成一種通用的資源，讓大家更好地去使用它，而不是無(wú)謂地增加埋點(diǎn)，使得代碼變得更臃腫。

讓我們一起看一下動(dòng)態(tài)埋點(diǎn)框架的一些 UI 交付圖。

相應(yīng)的，我們?cè)賹?duì)焦看一下支付寶埋點(diǎn)相關(guān)的應(yīng)用服務(wù)：實(shí)時(shí)日志拉取。其中，它的主要技術(shù)框架包括了 mPaaS 里面的 MPS (消息推送)、MSS(數(shù)據(jù)同步)、以及日志網(wǎng)關(guān)。這是因?yàn)槲浵佅?App 會(huì)與 MPS (安卓系統(tǒng))、MSS (蘋果系統(tǒng)) 保持長(zhǎng)連接，在需要實(shí)時(shí)拉取日志的時(shí)候，用戶可以在 mPaaS 的控制臺(tái)上面通過這兩個(gè)渠道下發(fā)指令，然后客戶端就會(huì)把加密的明細(xì)日志全部上報(bào)到日志網(wǎng)關(guān)。

這是實(shí)時(shí)日志拉取的界面操作展示圖。

針對(duì)于非常重要的性能指標(biāo): 閃退、卡頓、卡死， mPaaS 根據(jù)多年經(jīng)驗(yàn)準(zhǔn)備了對(duì)應(yīng)的大盤。如圖所示，上半部分是每分鐘的閃退數(shù)，下面是我們根據(jù)閃退分類算法梳理出來(lái)的各個(gè)閃退分類情況，針對(duì)每個(gè)分類大盤里我們還能看到具體的設(shè)備分布情況。

最后，讓我們從邏輯結(jié)構(gòu)上再梳理一下 mPaaS 的服務(wù)端結(jié)構(gòu)。mPaaS 包含五個(gè)核心組件:

1)?MGS（網(wǎng)關(guān)服務(wù)）：將客戶端的請(qǐng)求轉(zhuǎn)發(fā)到業(yè)務(wù)服務(wù)器.

2)?MDS（發(fā)布服務(wù)）：為客戶端提供多種資源的多種灰度策略發(fā)布能力。

3)?MPS & MSS（消息推送和數(shù)據(jù)同步服務(wù)）：以長(zhǎng)連接為基礎(chǔ)，來(lái)提供數(shù)據(jù)下發(fā)能力。

4)?MAS,（分析服務(wù)）：也是今天講解的重點(diǎn)，以日志埋點(diǎn)為基礎(chǔ)的分析能力。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的自动化日志收集及分析在支付宝 App 内的演进的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。