首先，我們了解一下移動端全鏈路 Trace 的背景：

從移動端的視角來看，一個 App 產(chǎn)品從概念產(chǎn)生，到最終的成熟穩(wěn)定，產(chǎn)品研發(fā)過程中涉及到的研發(fā)人員、工程中的代碼行數(shù)、工程架構(gòu)規(guī)模、產(chǎn)品發(fā)布頻率、線上業(yè)務(wù)問題修復(fù)時間等等都會發(fā)生比較大的變化。這些變化，給我們在排查問題方面帶來不小的困難和挑戰(zhàn)，業(yè)務(wù)問題會往往難以復(fù)現(xiàn)和排查定位。

比如，在產(chǎn)品初期的時候，工程規(guī)模往往比較小，業(yè)務(wù)流程也比較簡單，線上問題往往能很快定位。而等到工程規(guī)模比較大的時候，業(yè)務(wù)流程往往涉及到的模塊會比較多，這個時候有些線上問題就會比較難以復(fù)現(xiàn)和定位排查。

本文匯集了筆者在 2022 D2 終端技術(shù)大會上的相關(guān)技術(shù)分享，希望能給大家?guī)硪恍┧伎己蛦l(fā)。

端側(cè)問題為什么很難復(fù)現(xiàn)和定位？

線上業(yè)務(wù)問題為什么很難復(fù)現(xiàn)和排查定位？經(jīng)過我們的分析，主要是由 4 個原因?qū)е拢?/p>

移動端 & 服務(wù)端日志采集不統(tǒng)一，沒有統(tǒng)一的標準規(guī)范來約束數(shù)據(jù)的采集和處理。

端側(cè)往往涉及的模塊非常多，研發(fā)框架也各不相同，代碼相互隔離，設(shè)備碎片化，網(wǎng)絡(luò)環(huán)境復(fù)雜，會導(dǎo)致端側(cè)數(shù)據(jù)采集比較難。

從端視角出發(fā)，不同框架、系統(tǒng)之間的數(shù)據(jù)在分析問題時往往獲取比較難，而且數(shù)據(jù)之間缺少上下文關(guān)聯(lián)信息，數(shù)據(jù)關(guān)聯(lián)分析不容易。

業(yè)務(wù)鏈路涉及到的業(yè)務(wù)域往往也會比較多，從端的視角去復(fù)現(xiàn)和排查問題，往往需要對應(yīng)域的同學(xué)參與排查，人肉運維成本比較高。

這些問題如何來解決？ 我們的思路是四步走：

建立統(tǒng)一標準，使用 標準協(xié)議 來約束數(shù)據(jù)的采集和處理。

針對不同的平臺和框架，統(tǒng)一數(shù)據(jù)采集能力。

對多系統(tǒng)、多模塊產(chǎn)生的數(shù)據(jù)進行自動上下文關(guān)聯(lián)分析和處理。

我們也基于機器學(xué)習(xí)，在自動化經(jīng)驗分析方面做了一些探索。

統(tǒng)一數(shù)據(jù)采集標準

如何統(tǒng)一標準？ 目前行業(yè)內(nèi)也有各種各樣的解決方案，但存在的問題也很明顯：

不同方案之間，協(xié)議/數(shù)據(jù)類型不統(tǒng)一；

不同方案之間，也比較難以兼容/互通。

標準這里，我們選擇了 OTel，OTel 是 OpenTelemetry 的簡稱，主要原因有兩點：

OTel 是由云原生計算基金會（CNCF）主導(dǎo)，它是由 OpenTracing 和 OpenCensus 合并而來，是目前可觀測性領(lǐng)域的準標準協(xié)議；

OTel 對不同語言和數(shù)據(jù)模型進行了統(tǒng)一，可以同時兼容 OpenTracing 和 OpenCensus，它還提供了一個廠商無關(guān)的 Collectors，用于接收、處理和導(dǎo)出可觀測數(shù)據(jù)。

在我們的解決方案中，所有端的數(shù)據(jù)采集規(guī)范都基于 OTel，數(shù)據(jù)存儲、處理、分析是基于 SLS 提供的 LogHub 能力進行構(gòu)建。

端側(cè)數(shù)據(jù)采集的難點

只統(tǒng)一數(shù)據(jù)協(xié)議還不夠，還要解決端側(cè)在數(shù)據(jù)采集方面存在的一些問題。總的來說，端側(cè)采集當(dāng)前面臨 3 個主要的難點：

數(shù)據(jù)串聯(lián)難

性能保障難

不丟數(shù)據(jù)難

端側(cè)研發(fā)過程中涉及到的框架、模塊往往比較多，業(yè)務(wù)也有一定的復(fù)雜性，存在線程、協(xié)程多種異步調(diào)用 API，在數(shù)據(jù)采集過程中，如何解決數(shù)據(jù)之間的自動串聯(lián)問題？移動端設(shè)備碎片化嚴重，系統(tǒng)版本分布比較散，機型眾多，如何保障多端一致的采集性能？App 使用場景的不確定性也比較大，如何確保采集到的數(shù)據(jù)不會丟失？

端側(cè)數(shù)據(jù)串聯(lián)的難點

我們先來分析一下端側(cè)數(shù)據(jù)自動串聯(lián)所面臨的主要問題。

在端側(cè)數(shù)據(jù)采集過程中，不僅會采集業(yè)務(wù)鏈路數(shù)據(jù)，還會采集各種性能&穩(wěn)定性監(jiān)控數(shù)據(jù)，可觀測數(shù)據(jù)源比較多；

如果用到其他的研發(fā)框架，如 OkHttp、Fresco 等，可能還會采集三方框架的關(guān)鍵數(shù)據(jù)用于網(wǎng)絡(luò)請求，圖片加載等問題的分析和定位。對于業(yè)務(wù)研發(fā)同學(xué)來說，我們往往不會過多的關(guān)注這類三方框架技術(shù)能力，涉及到這類框架問題的排查時，過程往往比較困難；

除此之外，端側(cè)幾乎完全異步調(diào)用，而且異步調(diào)用 API 比較多，如線程、協(xié)程等，鏈路打通也存在一定的挑戰(zhàn)。

這里會有幾個共性問題：

三方框架的數(shù)據(jù)如何采集？如何串聯(lián)？

不同可觀測數(shù)據(jù)源之間如何串聯(lián)？

分布在不同線程、協(xié)程之間的數(shù)據(jù)如何自動串聯(lián)？

端側(cè)數(shù)據(jù)自動串聯(lián)方案

我們先看下端側(cè)數(shù)據(jù)自動串聯(lián)的方案。

在 OTel 協(xié)議標準中，是通過 trace 協(xié)議來約束不同數(shù)據(jù)之間的串聯(lián)關(guān)系。OTel 定義了 trace 數(shù)據(jù)鏈路中每條數(shù)據(jù)必須要包含的必要字段，我們需要確保同一條鏈路中數(shù)據(jù)的一致性。比如，同一條 trace 鏈路中，trace_id 需要相同；其次，如果數(shù)據(jù)之間有父子關(guān)系，子數(shù)據(jù)的 parent_id 也需要與父數(shù)據(jù)的 span_id 相同。

我們知道，不管是 Android 平臺，還是 iOS 平臺，線程都是操作系統(tǒng)能夠調(diào)度的最小單元。也就是說，我們所有的代碼，最終都會在線程中被執(zhí)行。在代碼被執(zhí)行過程中，如果我們能把上下文信息和當(dāng)前線程進行關(guān)聯(lián)，在代碼執(zhí)行時，就能自動獲取當(dāng)前上下文信息，這樣就可以解決同一個線程內(nèi)的 trace 數(shù)據(jù)自動關(guān)聯(lián)問題。

在 Android 中，可以基于線程變量 ThreadLocal 來存儲當(dāng)前線程棧的上下文信息，這樣可以確保在同一線程中采集到的業(yè)務(wù)數(shù)據(jù)進行自動關(guān)聯(lián)。如果是在協(xié)程中使用，基于線程變量的方案就會存在問題。因為在協(xié)程中，協(xié)程真實運行的線程是不確定的，可能會在協(xié)程執(zhí)行的生命周期內(nèi)進行線程切換，我們需要利用協(xié)程調(diào)度器和協(xié)程 Context 來保持當(dāng)前上下文的正確性。在協(xié)程恢復(fù)時，讓關(guān)聯(lián)的上下文信息在當(dāng)前線程生效，在協(xié)程掛起時，再讓上下文信息在當(dāng)前線程失效。

在 iOS 中，主要基于 activity tracing 機制來保持上下文信息的有效性。通過 activity tracing 機制，在一個業(yè)務(wù)鏈路開始時，會自動創(chuàng)建一個 activity，我們把上下文信息與 activity 進行關(guān)聯(lián)。在當(dāng)前 activity 作用域范圍內(nèi)，所有產(chǎn)生的數(shù)據(jù)都會與當(dāng)前上下文自動關(guān)聯(lián)。

基于這兩種方案，在產(chǎn)生 Trace 數(shù)據(jù)時，SDK 會按照 OTel 協(xié)議的標準，自動把上下文信息關(guān)聯(lián)到當(dāng)前數(shù)據(jù)中。最終產(chǎn)生的數(shù)據(jù)，會以一棵樹的形式進行邏輯關(guān)聯(lián)，樹的根節(jié)點就是 Trace 鏈路的起點。這種方式，不僅支持協(xié)程/線程內(nèi)的數(shù)據(jù)自動關(guān)聯(lián)，還支持多層級嵌套。

三方框架的數(shù)據(jù)采集和串聯(lián)

針對三方框架的數(shù)據(jù)采集，我們先看看業(yè)內(nèi)通行的做法，目前主要有兩類：

如果三方庫支持攔截器或代理的配置，一般會通過在對應(yīng)攔截器增加埋點代碼的方式來實現(xiàn)；

如果三方庫對外暴露的接口比較少，一般會通過 Hook 或其他方式增加埋點代碼，或者不支持對應(yīng)框架的埋點。

這種做法會存在兩個主要的問題：

埋點不完全，拿 OkHttp 來舉例說明，三方 SDK 內(nèi)部也可能存在對 OkHttp 的依賴，通過攔截器的方式，可能只支持當(dāng)前業(yè)務(wù)代碼的埋點采集，三方 SDK 的網(wǎng)絡(luò)請求信息無法被采集到，會導(dǎo)致埋點信息不完全；

可能需要侵入業(yè)務(wù)代碼，為了實現(xiàn)對應(yīng)框架的埋點，需要有一個切入時機，這個切入時機往往需要在對應(yīng)框架初始化時增加代碼配置項來實現(xiàn)。

如何解這兩個問題？

我們使用的方案是實現(xiàn)一個 Gradle Plugin，在 Plugin 中對字節(jié)碼進行插樁處理。我們知道，Android App 在打包的過程中，有個流程會把 .class 文件轉(zhuǎn)為 .dex 文件，在這個過程中，可以通過 transform api 對 class 文件進行處理。我們是借助 ASM 的方式來實現(xiàn) class 文件的插樁處理。在對字節(jié)碼處理的過程中，需要先找到合適的插樁點，然后注入合適的指令。

這里拿 OkHttp 的字節(jié)插樁進行舉例：插樁的目標是在 OkHttpClient 調(diào)用 newCall 方法時，把當(dāng)前線程的上下文信息關(guān)聯(lián)到 OkHttp 的 Request 中。在 Transform 過程中，我們先根據(jù) OkHttpClient 的類名過濾出目標 class 文件，然后再根據(jù) newCall 這個方法名過濾要插樁的方法。接下來，需要在 newCall 方法開始的地方把上下文信息插入到 request 的 tags 對象中。經(jīng)過我們的分析，需要在 newCall 方法調(diào)用開始的時候，插入目標代碼。為了方便實現(xiàn)和調(diào)試，我們在擴展庫中實現(xiàn)了一個 OkHttp 的輔助工具，在目標位置插入調(diào)用這個工具的字節(jié)碼，傳入 request 對象就可以了。

插入后的字節(jié)碼會和擴展庫進行關(guān)聯(lián)。這樣就能解決三方框架數(shù)據(jù)采集和上下文自動關(guān)聯(lián)的問題。

相對于傳統(tǒng)做法，使用字節(jié)碼插樁的方案，業(yè)務(wù)代碼侵入性會更低，埋點對業(yè)務(wù)代碼和三方框架都能生效，同時結(jié)合擴展庫也能完成上下文的自動關(guān)聯(lián)。

如何確保性能

在可觀測數(shù)據(jù)采集過程中，會有大量的數(shù)據(jù)產(chǎn)生，對內(nèi)存、CPU 占用、I/O 負載都有一定的性能要求。

我們基于 C 對核心部分進行實現(xiàn)，確保多平臺的性能一致性，并從三個方面對性能做了優(yōu)化：

首先，是對協(xié)議化處理過程進行優(yōu)化。數(shù)據(jù)協(xié)議方面選擇使用 Protocal Buffer 協(xié)議，Protocal Buffer 相對 JSON 來說，不僅速度更快，而且更省內(nèi)存空間。在協(xié)議的序列化上，我們采用了手動封裝協(xié)議的實現(xiàn)，在序列化的過程中，避免了很多臨時內(nèi)存空間的開辟、復(fù)制以及無關(guān)函數(shù)的調(diào)用。

其次，在內(nèi)存管理方面，我們直接對 SDK 的最大使用內(nèi)存做了可配置的大小限制。內(nèi)存的使用，可以根據(jù)業(yè)務(wù)情況按需配置，避免 SDK 內(nèi)存占用過大對 App 的穩(wěn)定性造成影響；其次，還引入了動態(tài)內(nèi)存管理機制，內(nèi)存空間的使用按需增加，不會一直占用 App 的內(nèi)存空間，避免內(nèi)存空間的浪費。同時還提升了字符串的處理性能。在字符的處理上，引入了動態(tài)字符串機制，它可以記錄字符串自身的長度，獲取字符長度時，操作復(fù)雜度低，而且可以避免緩沖區(qū)溢出，同時也可以減少修改字符串時帶來的內(nèi)存重分配次數(shù)。

最后，在文件緩存管理方面，我們也限制了文件大小的上限，避免對端設(shè)備存儲空間的浪費。在緩存文件的落盤處理上，我們引入了 Ring File 機制，把緩存數(shù)據(jù)存儲在多個文件上面，以日志文件組的形式對多個文件進行組裝。整個日志文件組以環(huán)形數(shù)組的形式，從頭開始寫，寫到末尾再回到頭重新循環(huán)寫。

通過這種方式寫數(shù)據(jù)，可以減少寫文件時的隨機 Seek，而且 Ring File 的機制，可以確保單個日志文件不會過大，從而盡可能的降低系統(tǒng) I/O 的負載。除了 Ring File 的機制外，還把斷點保存、緩存清理的邏輯放到了一起聚合執(zhí)行，減少隨機 Seek。checkpoint 的文件大小也做了限制，在超出指定大小后會對 checkpoint 文件進行清理，避免 checkpoint 文件過大影響文件讀寫效率。

經(jīng)過上面的這些優(yōu)化措施之后，最終 SDK 采集數(shù)據(jù)的吞吐量提升了 2 倍，內(nèi)存和 CPU 占用都有明顯的降低。每秒鐘最高可支持 400+條數(shù)據(jù)的采集。

如何確保日志不丟失？

性能滿足要求還不夠，還需要確保采集到的數(shù)據(jù)不能丟失。在 App 的使用過程中，app 經(jīng)常可能會出現(xiàn)異常崩潰，手機設(shè)備異常重啟，以及網(wǎng)絡(luò)質(zhì)量差，網(wǎng)絡(luò)延時、抖動大的情況。在這類異常場景下，如何確保采集到數(shù)據(jù)不會丟失？

在采集數(shù)據(jù)時，我們使用了預(yù)寫日志（WAL）機制，并結(jié)合自建網(wǎng)絡(luò)加速通道來優(yōu)化這個問題。

引入預(yù)寫日志機制的目的是確保寫入到 SDK 的數(shù)據(jù)，在發(fā)送到服務(wù)器之前，不會因為異常原因而丟失。這個過程的核心是，在數(shù)據(jù)成功發(fā)送到服務(wù)器之前，先把數(shù)據(jù)緩存在移動設(shè)備的磁盤上，數(shù)據(jù)發(fā)送成功之后，再移除磁盤上的緩存數(shù)據(jù)。如果因為 App 異常原因，或者設(shè)備重啟導(dǎo)致數(shù)據(jù)發(fā)送失敗，因為緩存的數(shù)據(jù)還在，SDK 會根據(jù)記錄的斷點信息對數(shù)據(jù)發(fā)送進度進行恢復(fù)。同時預(yù)寫日志機制可以確保數(shù)據(jù)的寫入和發(fā)送并發(fā)執(zhí)行，不會互相阻塞；

在數(shù)據(jù)發(fā)送之前，還會對多條數(shù)據(jù)做聚合處理，并通過 lz4 算法進行壓縮處理，這種做法可以降低數(shù)據(jù)發(fā)送時的請求次數(shù)和網(wǎng)絡(luò)傳輸流量的消耗。如果數(shù)據(jù)發(fā)送失敗，還會有重試策略，確保數(shù)據(jù)至少能成功發(fā)送一次；

在數(shù)據(jù)發(fā)送時，SDK 支持就近接入加速邊緣節(jié)點，并通過邊緣節(jié)點與 SLS 之間的內(nèi)部網(wǎng)絡(luò)加速通道傳輸數(shù)據(jù)。

經(jīng)過這三種主要的方式優(yōu)化之后，數(shù)據(jù)包的平均大小降低了 2.1 倍，整體的 QPS 平均提升 13 倍，數(shù)據(jù)整體的發(fā)送成功率達到了 99.3%，網(wǎng)絡(luò)延時平均下降了 50%。

多系統(tǒng)數(shù)據(jù)關(guān)聯(lián)處理

解決了端側(cè)數(shù)據(jù)的串聯(lián)和采集性能問題之后，還需要處理多系統(tǒng)之間的數(shù)據(jù)存儲和關(guān)聯(lián)分析問題。

數(shù)據(jù)存儲方面，我們直接基于 SLS LogHub 能力，把相關(guān)的數(shù)據(jù)統(tǒng)一存儲，基于 SLS，日均可以承載 PB 級別的流量，這個吞吐量可以支持移動端可觀測數(shù)據(jù)的全量采集。

解決了數(shù)據(jù)的統(tǒng)一存儲問題之后，還需要處理兩個主要的問題。

第一個問題，不同系統(tǒng)可觀測數(shù)據(jù)之間的上下文關(guān)聯(lián)如何處理？

根據(jù) OTel 協(xié)議的約束，我們可以基于 parent_id 和 span_id 來處理根節(jié)點、父節(jié)點、子節(jié)點之間的映射關(guān)系。首先，在查詢 Trace 數(shù)據(jù)鏈路時，會先從 SLS 拉取一定時間段內(nèi)的所有 Trace 數(shù)據(jù)。然后按照 OTel 協(xié)議的約束，對每條數(shù)據(jù)進行節(jié)點類型的判定。

由于多系統(tǒng)的數(shù)據(jù)可能存在延時，在查詢 Trace 數(shù)據(jù)鏈路時，有些數(shù)據(jù)可能還沒有到達。我們還需要對暫時不存在的父節(jié)點進行虛擬化處理，確保 Trace 鏈路的準確性。接下來，還需要對節(jié)點進行規(guī)整處理，把屬于同一個 parent_id 的節(jié)點進行聚合，然后再按照每個節(jié)點的開始時間進行排序，最終就可以得到一條 trace 鏈路信息，基于這個鏈路信息，我們可以還原出系統(tǒng)的調(diào)用鏈路。

第二個問題， 在進行 Trace 分析時，我們往往還需要從系統(tǒng)視角出發(fā)，對不同維度的數(shù)據(jù)進一步分析。比如，如果想從設(shè)備 ID、App 版本、服務(wù)調(diào)用等不同維度，對 Trace 數(shù)據(jù)進一步分析，該怎么做？我們來看一下怎么解決這個問題。

多系統(tǒng)數(shù)據(jù)拓撲生成

當(dāng)我們從系統(tǒng)整體視角對問題進行分析時，所需要的 Trace 數(shù)據(jù)規(guī)模往往會比較大，每分鐘可能有數(shù)千萬條數(shù)據(jù)，而且對數(shù)據(jù)的時效性要求也比較高。傳統(tǒng)的流處理方式在這種場景下很容易遇到性能瓶頸問題。我們采用的方案是，把流處理問題轉(zhuǎn)換為批處理問題，把傳統(tǒng)的鏈路處理視角轉(zhuǎn)換為系統(tǒng)處理視角。經(jīng)過視角轉(zhuǎn)化之后，從系統(tǒng)視角來看，解決這個問題最主要的核心，就是如何確定兩個節(jié)點之間的關(guān)系。

我們看一下具體的處理過程。在批處理上，我們使用了 MapReduce 框架。首先，在數(shù)據(jù)源處理階段，我們基于 SLS 的定時分析（ScheduledSQL）能力，對數(shù)據(jù)進行聚合處理，按照分鐘級從 Trace 數(shù)據(jù)源中撈取數(shù)據(jù)。在 Map 階段，先按照 traceID 進行分組，對分組之后的數(shù)據(jù)再按照 spanID、parentID 維度對數(shù)據(jù)進行聚合。

然后計算出相關(guān)的統(tǒng)計數(shù)據(jù)，如成功率、失敗率、延時指標等基礎(chǔ)統(tǒng)計數(shù)據(jù)。在實際的業(yè)務(wù)使用中，往往還會采集一些和具體業(yè)務(wù)屬性相關(guān)的數(shù)據(jù)，這部分數(shù)據(jù)往往會根據(jù)業(yè)務(wù)的不同，有比較大的差異。針對這部分類型的數(shù)據(jù)，在聚合處理的過程中，支持按照其他維度對結(jié)果進行分組。此時會得到兩種中間產(chǎn)物：

包含兩個節(jié)點關(guān)系的聚合數(shù)據(jù)，我們把這種類型的數(shù)據(jù)，叫做邊信息

以及未匹配到的原始數(shù)據(jù)

這兩種中間產(chǎn)物，在 Combine 階段還會再進行聚合處理，最終會得到包含基礎(chǔ)統(tǒng)計指標，以及其他維度的結(jié)果數(shù)據(jù)。

最終產(chǎn)物會包含幾個主要的信息：

邊信息，可以體現(xiàn)調(diào)用關(guān)系。

依賴信息，可以體現(xiàn)服務(wù)依賴關(guān)系。

還有指標信息，以及其他資源信息等。其中，業(yè)務(wù)屬性相關(guān)的數(shù)據(jù)會體現(xiàn)在資源信息中。

基于這些產(chǎn)物，我們可以通過對資源、服務(wù)等信息的多個維度篩選，來統(tǒng)計出對應(yīng)維度的問題分布和影響鏈路。

自動化問題根因定位探索

接下來向大家介紹下，我們在自動化問題根因定位方向的一些探索。

我們知道，隨著 App 版本的迭代，每次 App 的發(fā)版可能會涉及到多個業(yè)務(wù)的代碼變更。這些變更，有的經(jīng)過充分測試，也有的未經(jīng)過充分測試，或者常規(guī)測試方法沒有覆蓋到，對線上業(yè)務(wù)可能會產(chǎn)生一定的潛在影響，導(dǎo)致部分業(yè)務(wù)不可用。App 規(guī)模越大，業(yè)務(wù)模式越多，對應(yīng)的業(yè)務(wù)數(shù)據(jù)量，請求鏈路，不確定性就越大。出了問題之后，往往需要多人跨域參與排查，人肉運維成本比較高。

如何在端側(cè)問題排查定位方向，通過技術(shù)手段進行研發(fā)效能的提速？ 我們基于機器學(xué)習(xí)技術(shù)做了一些探索。

我們目前的方法是，先對 Trace 源數(shù)據(jù)進行特征處理；然后再對特征進行聚類分析，去找到異常 Trace；最后再基于圖算法等，對異常 Trace 進行分析，找到異常的起始點。

首先，實時特征處理階段會讀取 Trace 源數(shù)據(jù)，對每個 Trace 鏈路按照由底向上找 5 個節(jié)點的方式生成一個特征，并對特征進行編碼。然后對編碼之后的特征通過 HDBSCAN 算法進行層次聚類分析，此時相似的異常會分到同一個組里面，接下來再從每組異常 Trace 中找出一條典型的異常 Trace。最后，通過圖算法找到這條異常 Trace 的起點，從而確定當(dāng)前異常 Trace 可能存在的問題根因。通過這種方式，只要是遵循 OTel 標準協(xié)議的數(shù)據(jù)源都能夠進行處理。

案例：多端鏈路追蹤

經(jīng)過對數(shù)據(jù)處理之后，我們來看下最終的效果。

這里有一個模擬 Android、iOS、服務(wù)端，端到端鏈路追蹤的場景。

我們使用 iOS App 來作為指令的發(fā)送端，Android App 來作為指令的響應(yīng)端，用來模擬遠程打開汽車空調(diào)的操作。我們從圖上可以看到，iOS 端“打開車機空調(diào)”這個操作觸發(fā)后，依次經(jīng)過了“用戶權(quán)限校驗”、“發(fā)送指令”、“調(diào)用網(wǎng)絡(luò)請求”等環(huán)節(jié)。Android 端收到指令后，依次執(zhí)行“遠程啟動空調(diào)”、“狀態(tài)檢查”等環(huán)節(jié)。

從這個調(diào)用圖可以看得到，Android、iOS、服務(wù)端，多端鏈路被串聯(lián)到了一起。我們可以從 Android、iOS、服務(wù)端的任何一個視角，對調(diào)用鏈路進行分析。每個操作的耗時，對應(yīng)服務(wù)的請求數(shù)，錯誤率，以及服務(wù)依賴都能體現(xiàn)出來。

整體架構(gòu)

接下來，我們來看下整套解決方案的架構(gòu)：

最底層是數(shù)據(jù)源，遵循 OTel 協(xié)議，各個端對應(yīng)的 SDK 按照協(xié)議規(guī)范統(tǒng)一實現(xiàn)；

數(shù)據(jù)存儲層，是直接依托于 SLS LogHub，所有系統(tǒng)采集到的數(shù)據(jù)統(tǒng)一存儲；

再往上是數(shù)據(jù)處理層，對關(guān)鍵指標、Trace 鏈路、依賴關(guān)系、拓撲結(jié)構(gòu)、還有特征等進行了預(yù)處理。

最后是上層應(yīng)用，提供鏈路分析、拓撲查詢、指標查詢、原始日志查詢，以及根因定位等能力

后續(xù)規(guī)劃

最后總結(jié)下我們后續(xù)的規(guī)劃：

在采集層，會繼續(xù)完善插件、注解等方式的支持，降低業(yè)務(wù)代碼的侵入性，提升接入效率

在數(shù)據(jù)側(cè)，會豐富可觀測數(shù)據(jù)源，后續(xù)會支持網(wǎng)絡(luò)質(zhì)量、性能等相關(guān)數(shù)據(jù)的采集

在應(yīng)用側(cè)，會提供用戶訪問監(jiān)測、性能分析等能力

審核編輯：劉清