本文主要講述一種系統(tǒng)思路救赐，對于很多公司沒有足夠的技術(shù)人員來搭建一套完整的全鏈路日志系統(tǒng)情況下可以參考袖牙，對于細(xì)節(jié)實(shí)現(xiàn)方面牺蹄，大家可以根據(jù)自己產(chǎn)品的特性來設(shè)計(jì)粮宛，如果還有疑問滞时，可以發(fā)郵件到我的郵箱ufolca@163.com或者加我微信號【the51alien】備注一下“天梭”叁幢，第一次發(fā)文，如有不妥之處坪稽，還請指正
痛點(diǎn)
|任何一項(xiàng)技術(shù)的實(shí)施曼玩，如果不能解決某些或某個(gè)問題，那么它將沒有任何價(jià)值
相信很多移動(dòng)端開發(fā)人員會(huì)遇到一個(gè)問題窒百，客服收到用戶反饋黍判，APP的某個(gè)頁面打不開了，或者某個(gè)按鈕點(diǎn)不了等等非崩潰性質(zhì)的功能異常篙梢，在沒有該用戶全鏈路日志的情況下顷帖，我們一般會(huì)采取以下幾種處理方式
1. 根據(jù)經(jīng)驗(yàn)去代碼中檢查邏輯，看是否有邊界情況沒考慮到
2. 根據(jù)用戶的場景描述渤滞，在測試環(huán)境模擬一份相同的數(shù)據(jù)看能否復(fù)現(xiàn)
3. 獲取用戶授權(quán)贬墩，使用登錄令牌進(jìn)入問題場景看能否復(fù)現(xiàn)（沒有辦法的辦法，大部分用戶都會(huì)拒絕）
如果上述幾步都無法解決妄呕，相信很多人會(huì)是下面表情
那么有沒有一種比較快速直接的方法來幫助勤勞善良的程序猿(媛)來解決這些問題陶舞，答案是有-利用巨人的肩膀
天梭系統(tǒng)流程圖
大家會(huì)發(fā)現(xiàn)里面有三個(gè)巨人來支撐整個(gè)系統(tǒng)
巨人? ? ? ? ? ? ? ? ? ? | 職責(zé)?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | 要求?
云推送平臺(tái)? ? ? ? ?| 對目標(biāo)用戶下發(fā)日志收集指令? ? ? ? | 到達(dá)率高，有聯(lián)合喚醒功能
云資源存儲(chǔ)平臺(tái)? | 存儲(chǔ)出現(xiàn)異常的某天APP鏈路日志 | 容量大绪励，安全性高
熱補(bǔ)丁分發(fā)平臺(tái)? | 下發(fā)補(bǔ)丁? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 成功率高肿孵，實(shí)時(shí)性高，兼容性高
接下來我來一一介紹每個(gè)系統(tǒng)的任務(wù)和機(jī)制
●藍(lán)線部分-客戶端每天將用戶的操作和網(wǎng)絡(luò)日志有序,壓縮,加密,追加的方式寫入本地文件疏魏，可以手動(dòng)埋點(diǎn)或者AOP自動(dòng)化埋點(diǎn)停做，網(wǎng)絡(luò)日志相信很多人都在使用okhttp,可以在攔截器里進(jìn)行日志的寫入，所有操作一定要在子線程里執(zhí)行大莫，文件名以["."+app名+"-"+用戶id+"-"+日期(yyyy-MM-dd)]的隱藏方式,后綴采用jpg來偽裝成破損圖片
●黃線部分-從客戶端開始蛉腌，相信到技術(shù)人員這個(gè)節(jié)點(diǎn)都通俗易懂，最后到推送平臺(tái)我采用的是推送tag，而不是推送id作為參數(shù)眉抬，也是考慮的市面上普遍存在的多客戶端登陸情況贯吓，推送tag-推送id是一種一對多的映射關(guān)系，每個(gè)用戶登錄一臺(tái)設(shè)備都會(huì)手動(dòng)將該設(shè)備的推送id打上tag蜀变，我這里的tag就用的是用戶id
●紅線部分-APP會(huì)收到一條特殊json格式的推送悄谐，例如{"data":{"type":1024,"date":"2018-06-05"}}，客戶端的推送系統(tǒng)捕獲到這條指令后調(diào)用日志系統(tǒng)的上傳方法库北，選擇對應(yīng)日期的日志上傳的云存儲(chǔ)平臺(tái)爬舰，這樣技術(shù)人員能夠拿到這個(gè)日志，通過本地的工具寒瓦，將文件內(nèi)容讀取情屹，解密，解壓縮出來杂腰，將問題相關(guān)的功能數(shù)據(jù)mork到APP里復(fù)現(xiàn)
●黑線部分-如圖所示垃你，相信很多人都會(huì)操作，就不過多闡述了
問題
理想是美好的喂很，現(xiàn)實(shí)是殘酷的
1.推送問題惜颇，相信這是android開發(fā)人員最頭痛的問題，如果技術(shù)人員下發(fā)推送指令后十分鐘內(nèi)沒有看到用戶日志少辣，那么也只能通過客服提醒用戶再次打開APP凌摄，一般好的推送平臺(tái)的離線推送會(huì)再觸發(fā)一次
2.補(bǔ)丁問題，補(bǔ)丁修復(fù)的實(shí)時(shí)性和成功率決定了最后一步漓帅，否則只有發(fā)新版本了
3.日志系統(tǒng)建議只保留最近一周的日志锨亏，防止產(chǎn)生大量垃圾文件
后記
茶余飯后的談資
天梭這個(gè)名字來源，是我腦補(bǔ)出的一個(gè)系統(tǒng)場景忙干，像一個(gè)梭子在 用戶手機(jī)+3個(gè)平臺(tái)服務(wù)器的虛擬天網(wǎng)中來回穿梭
