開發與維運

全面提升-SLS移動端SDK2.0發佈

2020-10-27

背景

隨著移動互聯網的高速發展，智能手機得到了快速的普及，《2020全球移動市場報告》中預測，2023年，全球智能手機用戶或將突破40億，而中國用戶將佔到其中的1/4，其中5G智能手機數量佔比將達到43％。這也就意味著未來中國幾乎人手一個智能機，每個人的生活都和智能機上的APP相關。並且隨著5G技術的普及，流量紅利即將全面打開，APP的多媒體豐富性將達到一個新的層次。

這些發展的背後，也將帶來很多挑戰，其中之一就是如何保證逐漸複雜的APP如何被更好的收集和分析。目前數據分析的能力相對都比較成熟，但收集幾乎都需要每個公司自己開發，其中可能會涉及到各種各樣的問題，例如：

  • 應用已有的工具是否可以支持採集海量的數據。
  • 日誌上報不及時，無法實時監控可能出現的問題。
  • 出現問題，依靠零散的日誌，定位問題的成本增加。
  • 想對於某些型號或版本的統計分析耗時耗力，很難構建用戶畫像。
  • 日誌上報需要佔用APP額外的CPU、內存、網絡等資源，低劣的方案可能會對應用性能產生影響。

SLS 數據採集系列

image.png

日誌服務(SLS)作為一個綜合的數據採集、分析、可視化、監控平臺，支持各種類型數據的統一接入，目前端上數據接入主要有：

  • 客戶端Logtail在X86/ARM服務器上有數百萬的部署，服務阿里/螞蟻經濟體、各行業雲上客戶，每天採集數據10PB+
  • 移動端SDK：Android/IOS平臺數據採集，每天已有上億的DAU
  • Web Tracking（JS）：類似百度統計，Google Analytics 輕量級採集方式，無需簽名
  • 嵌入式SDK：支持各類IoT設備數據採集，資源佔用極少，支持各類嵌入式平臺

從1.0到2.0

SLS移動端SDK（Android、IOS）1.0的發佈已經有5-6年，目前已經積累了眾多的用戶，DAU已經上億。然而隨著智能機、4G的普及以及未來5G的發展，移動端SDK的1.0版本已經逐漸暴露出一些問題，例如：

  • 同步數據發送：用戶需要基於SDK再次封裝異步發送邏輯，實現複雜度較高。
  • 不支持日誌上下文：沒辦法追蹤某個設備數據發送的數據上下文信息，問題排查較為複雜。
  • 資源佔用問題：SDK基於很多三方庫來實現，性能較低而且資源佔用率很高。
  • 離線緩存：只有Android SDK支持離線緩存，而且實現效率較低，開啟後會影響應用性能。

藉助於SLS在服務端、嵌入式端等積累的數據採集經驗，我們充分吸取各個端上的優勢開發了移動端SDK2.0版本，在支持眾多高級功能的情況下依然能夠保持高性能與低資源佔用。

多端SDK統一平臺

image.png

2.0架構下SLS的端上SDK基於共同的基座C Core SDK適配，C Core部分代碼使用純C語言編寫，且對性能進行了極端的優化（包括緩存管理、文件管理、PB序列化等），能夠適用於服務端、IOT、移動端等各種場景。同時C Core部分的代碼提供了多種配置方式，可以通過配置決定是否打開某項功能。目前2.0版本的Android IOS SDK均基於C Core提供的統一接口適配實現，具備C Core SDK的各類高級功能，包括：

  • 異步

    • 異步寫入，客戶端線程無阻塞

  • 聚合&壓縮 上傳

    • 支持按超時時間、日誌數、日誌size聚合數據發送
    • 支持lz4壓縮

  • 多實例

    • 可同時創建多個實例分別發送到不同的目標，每個客戶端可獨立配置採集優先級、緩存上限、目的project/logstore、聚合參數等 (多客戶端，斷點續傳文件路徑不能相同)

  • 緩存

    • 支持緩存上限可設置
    • 超過上限後日志寫入失敗

  • 自定義標識

    • 支持設置自定義tag、topic

  • 斷點續傳功能

    • 每次發送前會把日誌保存到本地的binlog文件，只有發送成功才會刪除，保證日誌上傳At Least Once

  • 查看日誌上下文

    • 支持查看某條日誌的上下文呢，可以更好的定位問題

斷點續傳

此次2.0版本的一個巨大提升是完美支持了斷點續傳功能，在移動端，應用的生命週期不可控，因此絕大部分情況下無法實現優雅退出，應用可能在任意時刻、任意階段被強制終止，而這時如果產生的日誌沒有被髮送出去則會丟失掉。針對這種場景，我們設計了一套保證At Least Once的斷點續傳機制：每次發送日誌前會把數據強制刷盤，只有在發送成功後才會把盤上的數據文件清空。為了儘可能減少IO，我們在斷點續傳中使用了WAL+RingFile的磁盤管理方式，每次以Append形式寫入，儘量減少隨機Seek，CheckPoint和數據清理也是聚合執行，以進一步減少IO的負載。

image.png

全球加速

針對以上問題，日誌服務聯合阿里雲CDN推出了一款全球數據上傳自動加速方案：“基於阿里雲CDN硬件資源，全球數據就近接入邊緣節點，通過內部高速通道路由至LogHub，大大降低網絡延遲和抖動 ”。 該方案有如下特點：

  • 全網邊緣節點覆蓋：全球1000+節點，國內700+節點，分佈60多個國家和地區，覆蓋六大洲
  • 智能路由技術：實時探測網絡質量，自動根據運營商、網絡等狀況選擇最近接入
  • 傳輸協議優化：CDN節點之間走私有協議、高效安全
  • 使用便捷：只需1分鐘即可開通加速服務，只需切換到專屬加速域名即可獲得加速效果

image.png

在我們的日誌上傳基準測試中，全球7個區域對比整體延時下降50%，在中東，歐洲、澳洲和新加坡等效果明顯。除了平均延時下降外，整體穩定性也有較大提升（參見最下圖，幾乎沒有任何抖動，而且超時請求基本為0）。確保無論在全球的何時何地，只要訪問這個加速域名，就能夠高效、便捷將數據採集到期望Region內。
關於全球採集加速的更多內容，可參考我們的文章：數據採集新形態-全球加速 。

性能測試

下面是1.0和2.0版本的性能測試結果，可以看到由於採集的是和IoT SDK一致的C語言內核，Android IOS SDK在資源控制上會更加的高效，性能也更高。

image.png

測試環境如下：

  • 每個緩存的日誌包的大小上限，為1Mb
  • 每個緩存的日誌包中包含日誌數量的最大值，為1024
  • 被緩存日誌的發送超時時間，為3秒
  • 單個Producer Client實例可以使用的內存的上限，為64Mb
  • 發送線程數為1
  • 每條數據有10個鍵值對，約700字節

快速接入

Android SDK

詳細接入方式： https://github.com/aliyun/aliyun-log-android-sdk

  • Gradle配置
jcenter()
implementation 'com.aliyun.openservices:aliyun-log-android-sdk:2.3.0'

IOS SDK

詳細接入方式： https://github.com/aliyun/aliyun-log-ios-sdk

  • Podfile
pod 'AliyunLogProducer', '~> 2.1.0'

總結

移動端2.0 SDK使數據可以更便捷、更穩定、更高效地從移動端實時傳輸到SLS中，對於應用開發者來說使用SLS的2.0 SDK會更加簡單，無需關心異步、隊列、重試、可靠性等基礎問題。解決了通道問題後，未來我們會更加聚焦於移動端埋點、移動端數據分析、移動端/服務端全鏈路監控等場景，為大家帶來更加完備的解決方案。

大家在使用SLS過程中，如有任何問題, 可提工單, 或在用戶群中反饋(見下放釘釘二維碼), 也歡迎關注我們的微信公眾號, 會推送實用的使用技巧和最佳實踐哦~

ps: SLS團隊長期招聘人才，歡迎對大數據、監控、可觀察性、前端可視化、移動端開發、機器學習等有興趣的同學前來聯繫我，郵箱 [email protected]，微信 davidzhang-zc。

image.png

Leave a Reply

Your email address will not be published. Required fields are marked *