偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

移動域全鏈路可觀測架構(gòu)和關(guān)鍵技術(shù)

移動開發(fā)
本文側(cè)重闡述手淘團(tuán)隊對移動領(lǐng)域全鏈路技術(shù)理念的原創(chuàng)性引入,整篇約1.2萬字、閱讀需要15分鐘,讀者將收獲移動技術(shù)域體驗優(yōu)化的思路轉(zhuǎn)變,以及軟件定義體驗的沉淀和研發(fā)實踐。

App 現(xiàn)有架構(gòu)挑戰(zhàn)

2013年開始All in無線到如今,阿里集團(tuán)移動技術(shù)發(fā)展十余年,歷經(jīng)幾個關(guān)鍵階段:

  • 第一階段,解決大規(guī)模業(yè)務(wù)并發(fā)研發(fā)的痛點,定義了Atlas(容器化框架, 提供組件解耦、動態(tài)性等支持)架構(gòu);
  • 第二階段,建設(shè)ACCS(淘寶無線全雙工、低延時、高安全的通道服務(wù))長連雙工加密網(wǎng)絡(luò)能力,補齊端到端互操作移動服務(wù)能力追趕行業(yè);
  • 第三階段,面向業(yè)務(wù)特性建設(shè)Weex、小程序等動態(tài)化研發(fā)框架,移動技術(shù)進(jìn)入動態(tài)化跨平臺時期。

中后期通過阿里移動小組機制進(jìn)行各BU拉通和能力共建。自此,移動基礎(chǔ)設(shè)施基本成型,各個領(lǐng)域各自沉淀若干組做到能力復(fù)用,App基本形成上層業(yè)務(wù)、中間研發(fā)框架或容器、基礎(chǔ)能力三層的架構(gòu)。我們團(tuán)隊作為無線端側(cè)基礎(chǔ)設(shè)施的承建方,過去重點是負(fù)責(zé)集團(tuán)移動端的基礎(chǔ)能力建設(shè),近年來,團(tuán)隊重點深入淘寶業(yè)務(wù)場景展開性能優(yōu)化,通過體驗優(yōu)化項目橫向剖析App架構(gòu)和及相關(guān)調(diào)用鏈路,感受到集團(tuán)App普遍存在如下共性問題:

(圖1 淘寶App架構(gòu)挑戰(zhàn))

  • 運維排查效率低下: 首先是監(jiān)控階段,多數(shù)問題無監(jiān)控或者監(jiān)控上報后的信息無法支撐更有效的分析,需要依賴日志進(jìn)行問題排查;其次是沒有日志的問題,發(fā)生異常時并不會主動上傳日志,需要手動撈取,用戶不在線更是拉取不到日志;拉取到日志后,還會繼續(xù)遇到日志讀不懂的問題問題;跟服務(wù)端有關(guān)的鏈路,還會遇到服務(wù)端鷹眼日志只保存5分鐘的問題,經(jīng)過這樣一輪下來,基本時間已經(jīng)過去半天...
  • 端到端追蹤不完整: 一個完整的業(yè)務(wù)鏈路,流量會穿越端到端多層,以一次下單為例,通過客戶端所觸發(fā)的網(wǎng)絡(luò)請求到達(dá)服務(wù)器之后,會經(jīng)過若干客戶端模塊處理、觸發(fā)N次后端應(yīng)用調(diào)用以及歷經(jīng)移動網(wǎng)絡(luò)的不穩(wěn)定性,試想一下,這些調(diào)用中有哪些出問題會影響這次下單交易,有哪些步驟會拖慢整個處理流程、請求沒返回不清楚是服務(wù)端問題還是網(wǎng)絡(luò)問題,假如各調(diào)用全鏈路性能定義不清,意味著各層問題得不到充分暴露,這些因素都是需要考慮的,加上端側(cè)天然異步調(diào)用,導(dǎo)致各階段度量和全鏈路打通存在重大挑戰(zhàn),目前現(xiàn)狀就是客戶端各層沒有統(tǒng)一調(diào)用規(guī)范,并且缺乏拓?fù)浣Y(jié)構(gòu),無法還原調(diào)用鏈路,導(dǎo)致端到端無法追蹤;
  • 優(yōu)化缺少統(tǒng)一口徑: 過去因為各研發(fā)框架性能口徑自閉環(huán),不管是客戶端原生技術(shù),還是跨平臺技術(shù)都是面向技術(shù)視角統(tǒng)一采集通用的技術(shù)口徑,這種情況會天然導(dǎo)致各業(yè)務(wù)實現(xiàn)和表現(xiàn)差異巨大,通俗說就是不接近用戶體感,會導(dǎo)致線上的數(shù)據(jù)難以反應(yīng)真實情況及優(yōu)劣趨勢,長久以來,淘寶的體驗也一直在劣化,每年基本都要靠運動式方式來搞體驗優(yōu)化,無法常態(tài)化保持;
  • 移動Paas流程賦能成本: 大量的SDK組件輸出集團(tuán)各BU后,基礎(chǔ)能力嵌入到不同的App宿主環(huán)境后,同樣會遇到上面提到的幾類問題,對各BU同學(xué)來說,基礎(chǔ)設(shè)施更是黑盒,如果問題涉及到基礎(chǔ)設(shè)施,排查過程更加艱辛,加上沒有現(xiàn)有的工具可以自助診斷問題在哪,遇到問題只能過來咨詢,各種拉群拉人,導(dǎo)致答疑成本居高不下。

以上是從APP結(jié)構(gòu)的角度對當(dāng)前客戶端在運維排查、度量監(jiān)控、全鏈路優(yōu)化等方面的不足進(jìn)行的一些思考,也是我們后續(xù)的發(fā)力方向。

可觀測體系

監(jiān)控到可觀測性的演變

可觀測性是一套理念系統(tǒng),沒有對技術(shù)實現(xiàn)的具體要求,重點是通過引入該理念,將理念應(yīng)用到我們的業(yè)務(wù)迭代和問題洞察中。傳統(tǒng)的運維可能只能給我們帶來最頂層的告警和異常的概況,當(dāng)需要更深層次的錯誤信息定位的時候,往往會通過建群拉人,然后先通過人肉找尋問題的特征,甚至是某個模塊的開發(fā)承擔(dān)起分析各個模塊的依賴關(guān)系等的工作,問題處理基本涉及3個角色以上(業(yè)務(wù)、測試、開發(fā)、架構(gòu)、平臺等)。

相比傳統(tǒng)的監(jiān)控,可觀測性能夠通過結(jié)合數(shù)據(jù),并且將數(shù)據(jù)有機聯(lián)系在一起,產(chǎn)生更好的連接,幫助我們更好的觀察系統(tǒng)的運行狀況,快速定位和解決問題?!副O(jiān)控告訴我們系統(tǒng)的哪些部分是工作的,而可觀測性告訴我們那里為什么不工作了」,下圖2說明了兩者之間的關(guān)系,監(jiān)控側(cè)重宏觀大盤展現(xiàn),而可觀測性包含了傳統(tǒng)監(jiān)控的范疇。

(圖2 監(jiān)控和可觀測的關(guān)系)

從上圖來看,核心還是觀察各個模塊以及關(guān)鍵調(diào)用和依賴等的輸出,基于這些輸出來判斷整體的工作狀態(tài),業(yè)界通常會把這些關(guān)鍵點總結(jié)為Traces、Loggings、Metrics。

可觀測性關(guān)鍵數(shù)據(jù)

(圖3 可觀測性關(guān)鍵數(shù)據(jù))

結(jié)合Traces、Loggings、Metrics的定義和淘寶現(xiàn)有情況,做了一些解讀:

  • Loggings(日志):基于現(xiàn)有TLOG(無線端到端日志系統(tǒng))日志通道,展現(xiàn)的是App運行時產(chǎn)生的事件或者程序在執(zhí)行的過程中間產(chǎn)生的一些日志,可以詳細(xì)解釋系統(tǒng)的運行狀態(tài),如頁面跳轉(zhuǎn)、請求日志、全局CPU、內(nèi)存使用等信息,多數(shù)日志是沒有實現(xiàn)串聯(lián)的,現(xiàn)在引入結(jié)構(gòu)化的調(diào)用鏈路日志后,日志在調(diào)用鏈場景結(jié)構(gòu)化后其實可以轉(zhuǎn)變?yōu)門race,支撐單機排查;
  • Metrics(指標(biāo)):是聚合后的數(shù)值,偏宏觀大盤使用,對于問題定位缺乏細(xì)節(jié)展示,一般有各種維度、指標(biāo),Metrics數(shù)據(jù)量一般很大,需要針對場景做一些采樣控制;
  • Traces(追蹤):是最標(biāo)準(zhǔn)的調(diào)用日志,除了定義了調(diào)用的父子關(guān)系外(一般通過TraceID、SpanID),一般還會定義操作的服務(wù)、方法、屬性、狀態(tài)、耗時等詳細(xì)信息,通過Trace能夠代替一部分Logs的功能,長期看通過Trace的聚合也能得到每個模塊、方法的Metrics度量指標(biāo),但日志存儲大,成本高。

全鏈路可觀測性架構(gòu)

上述可觀測體系理念在后端有一些實踐落地,但回歸到移動領(lǐng)域的特性和現(xiàn)狀,有種種問題如下:

  • 調(diào)用規(guī)范的問題:與云端的差異是端側(cè)完全異步,異步API極其豐富,且沒有統(tǒng)一調(diào)用規(guī)范;
  • 多技術(shù)域的問題:研發(fā)框架數(shù)量眾多,能力對外黑盒,如何串聯(lián)存在大量難以感知的成本;
  • 端云差異的問題:端側(cè)的海量分布式設(shè)備,意味著可觀測模式的挑戰(zhàn)與服務(wù)端也有本質(zhì)差異,logging與metrics在服務(wù)端可以基于一套體系完全上報實現(xiàn),但單機埋點和日志量差異極大,這也是端側(cè)埋點系統(tǒng)和日志系統(tǒng)分離的原因,端側(cè)則需要實現(xiàn)如何兼顧海量設(shè)備的單機問題排查和大數(shù)據(jù)下的指標(biāo)趨勢定義;
  • 端云關(guān)聯(lián)的問題:端到端現(xiàn)實一直是割裂狀態(tài),以端側(cè)為視角如何更好感知后端狀態(tài),如何做關(guān)聯(lián),如怎么持續(xù)推進(jìn)serverRT(后端請求調(diào)用耗時)從IDC(互聯(lián)網(wǎng)數(shù)據(jù)中心)到CDN覆蓋,端側(cè)全鏈路標(biāo)識如何讓后端也感知。

因此,我們需要圍繞以上這些問題對移動技術(shù)領(lǐng)域全鏈路進(jìn)行定義,并建立起相關(guān)領(lǐng)域級的分析能力和好的評價標(biāo)準(zhǔn),才能更深刻的洞察移動端的問題所在,才能在問題排查和性能度量領(lǐng)域持續(xù)服務(wù)好集團(tuán)各App以及跨域的問題。

(圖4 全鏈路可觀測架構(gòu)定義設(shè)想)

  • 數(shù)據(jù)層:定義指標(biāo)規(guī)范和采集方案,基于Opentracing(分布式跟蹤規(guī)范)數(shù)據(jù)上報;
  • 領(lǐng)域?qū)樱簢@問題發(fā)現(xiàn)到問題定位、性能持續(xù)優(yōu)化體系、技術(shù)升級沉淀幾方面演進(jìn);
  • 平臺層:沉淀集團(tuán)&競對視角的比對,結(jié)合線上線下指標(biāo),引入廠商視角,驅(qū)動App性能提升;
  • 業(yè)務(wù)層:全鏈路視角,打通端到端,除了客戶端同學(xué),還可以服務(wù)不同技術(shù)棧跨域的研發(fā)人員。

回顧全鏈路可觀測項目的目標(biāo),我們設(shè)定為“打造全鏈路可觀測體系,改善性能并驅(qū)動業(yè)務(wù)體驗改善,提升問題定位效率”,后續(xù)章節(jié)會重點講解每一層的實踐。

移動端opentracing可觀測架構(gòu)

全鏈路構(gòu)成

(圖5 端到端情況、詳情場景分層圖)

端到端現(xiàn)有鏈路長,端側(cè)存在各類研發(fā)框架和能力,雖然后端調(diào)用鏈路明確,但從全鏈路視角看,并沒有與端側(cè)打通。以用戶瀏覽詳情動線為例,一次首屏打開,會觸發(fā)奧創(chuàng)、MTOP(無線網(wǎng)關(guān))、DX三個模塊不同的調(diào)用時序,不同的模塊有各自的處理過程,不同階段有不同的耗時和狀態(tài)(成功、失敗等);接著繼續(xù)看滑動,可以看到模塊的調(diào)用時序組合又不一樣,因此不同場景下可以由若干要素隨機組合,需要根據(jù)用戶實際場景,劃分若干維度來定義全鏈路:

  • 場景定義:一次用戶操作為一個場景,如點擊、滑動都是單獨的場景,場景也可以是多個單個場景的組合;
  • 能力分層:不同場景,有業(yè)務(wù)類,框架類、容器類、請求類的調(diào)用,可以對每個領(lǐng)域進(jìn)行分層;
  • 階段定義:不同分層有各自的階段。如框架類有4個本地階段,而請求類可以包含后端服務(wù)端處理階段;
  • 用戶動線:一次動線由若干場景組成。

全鏈路,就是把復(fù)雜的大調(diào)用分解為有限個結(jié)構(gòu)化的小調(diào)用,并且可以衍生出各種case:

  • 「單場景+單階段」的組合全鏈路;
  • 「單場景+若干分層+若干階段」組合的全鏈路;
  • 「若干場景+若干分層+若干階段」組合的全鏈路;
  • ... ...

Falco-基于OpenTracing模型

全鏈路為了支持Logs + Metrics + Tracing 行業(yè)標(biāo)準(zhǔn),引入分布式調(diào)用規(guī)范opentracing協(xié)議,在上述的客戶端架構(gòu)上進(jìn)行二次建模(后續(xù)簡稱為Falco)。

OpenTracing 規(guī)范是 Falco 的模型基礎(chǔ),以下不再列舉,完整可參考OpenTracing設(shè)計規(guī)范,https://opentracing.io/docs/overview/。Falco定義了端側(cè)領(lǐng)域的調(diào)用鏈追蹤模型,主要表結(jié)構(gòu)如下:

(圖6 Falco數(shù)據(jù)表模型)

  • span公共頭:黃色部分,對應(yīng)OpenTracing規(guī)范的Span基礎(chǔ)屬性;
  • scene:對應(yīng)OpenTracing的baggage部分,會從根span往下透傳,存放業(yè)務(wù)場景,命名規(guī)則為「業(yè)務(wù)標(biāo)識_行為」。比如詳情首屏為ProductDetail_FirstScreen、詳情刷新為ProductDetail_Refresh;
  • layer: 對應(yīng)OpenTracing的Tags部分,定義了層的概念,目前劃分為業(yè)務(wù)層、容器層和能力層。處理業(yè)務(wù)邏輯的模塊歸屬業(yè)務(wù)層,命名為business;提供視圖容器歸屬容器&框架層,如DX、Weex都是,命名為frameworkContainer;僅提供一個原子能力的模塊,歸屬能力層,命名為ability,如mtop、picture,層可應(yīng)用于對同層同能力的不同模塊進(jìn)行橫向性能對比;
  • stages:對應(yīng)OpenTracing的Tags部分,表示一次模塊調(diào)用包含的階段。每一層基于領(lǐng)域模型劃分了關(guān)鍵階段,目的是讓同層的不同模塊具備一致的對比口徑,如DX和TNode對比,可以從預(yù)處理耗時、解析耗時、渲染耗時衡量彼此優(yōu)劣。比如預(yù)處理階段名為preProcessStart,也可以自定義;
  • module:對應(yīng)OpenTracing的Tags部分,更多的是邏輯模塊。比如 DX、mtop、圖片庫、網(wǎng)絡(luò)庫;
  • Logs:對應(yīng)OpenTracing的Logs部分,日志僅記錄到TLog,不輸出到UT埋點。

Falco-關(guān)鍵要點

(圖7 Falco關(guān)鍵實現(xiàn))

  1. 端側(cè)traceID:滿足唯一性、生成快、可擴(kuò)展、可讀、長度短等原則生成;
  2. 調(diào)用&還原抽象:由traceID和span多級序列號一路透傳,明確上下游關(guān)系;
  3. 端到端串聯(lián):核心解決云端串聯(lián)的問題,端側(cè)ID透傳到服務(wù)端,服務(wù)端存放和鷹眼ID的映射關(guān)系;接入層返回鷹眼ID,端側(cè)全鏈路模型存在鷹眼ID,通過這樣的雙向映射關(guān)系,我們能知道一個未返回的請求究竟是因為在網(wǎng)絡(luò)階段沒有成功、還是沒有到達(dá)接入層、或者是業(yè)務(wù)服務(wù)沒有返回,從而將耳熟能詳、粗粒度的網(wǎng)絡(luò)問題變得可定義和可解釋;
  4. 分層度量:核心目的是讓同層的不同模塊具備一致的對比口徑,支撐框架升級后的性能橫向?qū)Ρ?,思路為抽象客戶端領(lǐng)域模型,如以框架類為例子,雖然框架不同,但一些關(guān)鍵調(diào)用和解析是一致的,因此可以抽象成為標(biāo)準(zhǔn)階段,其它類似;
  5. 結(jié)構(gòu)化埋點:首先采用列式存儲,利于大數(shù)據(jù)集的數(shù)據(jù)聚合操作和數(shù)據(jù)壓縮,減少數(shù)據(jù)量;其次,業(yè)務(wù)+場景+階段沉淀到一張表中,方便關(guān)聯(lián)查詢;
  6. 基于Falco的領(lǐng)域問題沉淀:包括復(fù)雜問題的關(guān)鍵定義、追蹤問題的線索型日志、某些特殊訴求的埋點。所有領(lǐng)域問題的信息被結(jié)構(gòu)化沉淀到Falco,領(lǐng)域技術(shù)開發(fā)者也可以基于沉淀的領(lǐng)域信息持續(xù)開展分析能力的建設(shè),只有實現(xiàn)數(shù)據(jù)的有效性供給和領(lǐng)域性解釋合一,才能定義和解決更深層次的問題。

(圖8 Falco領(lǐng)域問題模型)

基于Falco的運維實踐

運維的范疇極為廣泛,圍繞問題發(fā)現(xiàn)、問題接手、定位分析、問題修復(fù)關(guān)鍵流程,從海量設(shè)備的指標(biāo)觀測、告警,到單機排查、日志分析等,大家都知道要這么做,里面每個流程都涉及很多能力的建設(shè),但實際執(zhí)行起來很難做,各方也不認(rèn)可,淘寶客戶端一直以來存在指標(biāo)準(zhǔn)確性和日志拉取效率低下的問題。如APM性能指標(biāo)為例,淘寶App過去很多指標(biāo)不準(zhǔn),業(yè)務(wù)同學(xué)不認(rèn)可,不能指導(dǎo)實際優(yōu)化。本章節(jié)會從重點分享下淘寶App在指標(biāo)準(zhǔn)確性和日志拉取效率方面的相關(guān)優(yōu)化實踐。

(圖9 問題扭轉(zhuǎn)用戶動線以及運維系統(tǒng))

宏觀指標(biāo)體系

以端性能橫向戰(zhàn)役為契機,基于用戶體感的體驗,APM開啟了相關(guān)升級工作,核心涉及啟動、外鏈以及各業(yè)務(wù)場景下的可視可交互指標(biāo),如何做到讓指標(biāo)對應(yīng)的終點更貼近用戶體感,主要有以下一些工作:

  • 8060算法的升級:視覺有用的元素提取出來計算(如圖片和文字),剔除用戶不能感知的元素(空白控件、兜底圖),如制定視圖可視規(guī)范,滿足圖片庫、魚骨圖等自定義控件打標(biāo);
  • H5領(lǐng)域:支持UC 頁面元素可視可交互以及前端 JSTracker(事件埋點框架)回溯算法,與H5頁面可視算法打通;
  • 深入復(fù)雜的場景:制定自定義框架可視規(guī)范,打通 Flutter 、TNode(動態(tài)化研發(fā)框架)并校準(zhǔn)等各類研發(fā)框架,8060算法交由各研發(fā)框架來實現(xiàn);
  • 外鏈領(lǐng)域:打通H5頁面口徑,重新定義外鏈離開等負(fù)向動作。

以啟動為例,APM 在 校準(zhǔn)后,包含了圖片上屏等階段后,數(shù)據(jù)雖然上漲了,但更符合業(yè)務(wù)方訴求。

(圖10 校準(zhǔn)后啟動數(shù)據(jù)趨勢)

以外鏈為例,打通H5后,新口徑也出現(xiàn)了上漲,但更符合體感。

(圖11 校準(zhǔn)后外鏈前后口徑數(shù)據(jù)對比)

基于此戰(zhàn)役,已實現(xiàn)打通若干研發(fā)框架可視指標(biāo)和校正工作。

單機排查體系

對于問題排查,目前核心還是基于TLOG,本次僅圍繞用戶問題排查動線中日志上報、日志分析、定位診斷關(guān)鍵環(huán)節(jié)遇到的問題(無日志、日志看不懂、定位難等),介紹運維排查體系為提升問題定位效率做的努力。

(圖12 單機排查問題定位核心功能)

  • 提升日志上傳成功率,從幾個方面保障在排查問題時有日志供應(yīng)過來,一是內(nèi)置日志主動上傳能力,在核心場景或問題反饋多時機觸發(fā),提高日志觸達(dá)率,如輿情反饋、新功能上線發(fā)生異常時;二對TLOG能力進(jìn)行升級,涉及到分片策略、重試、日志治理等優(yōu)化,解決以往用戶反饋較多日志上傳的時效問題;最后是收集各類異常信息,作為快照,通過MTOP鏈路旁路上報,輔助還原現(xiàn)場;
  • 提升日志的定位效率,首先對日志做分類,如區(qū)分出頁面日志、全鏈路日志支持快速篩選過濾;接著是打通各個場景的全鏈路調(diào)用拓?fù)浣Y(jié)構(gòu),目的是可以快速看出問題發(fā)生在哪個節(jié)點,以便快速分發(fā)處理;最后結(jié)構(gòu)化錯誤、慢、UI卡等問題,原則是將領(lǐng)域問題的解釋權(quán)交給領(lǐng)域,比如卡頓日志有幾類,如APM凍幀、ANR、主線程卡頓等;業(yè)務(wù)類有請求失敗、請求RT大于xx時間、頁面白屏等,通過各領(lǐng)域的能力 對接來提升問題的快速診斷定位能力;
  • 全鏈路追蹤能力建設(shè),鷹眼(分布式跟蹤系統(tǒng)在阿里后端的實現(xiàn))接入業(yè)務(wù)眾多,日志量大,不可避免要做日志的采樣,對于沒有命中采樣的調(diào)用,緩存只有5分鐘,需要想辦法在5分鐘內(nèi)通知鷹眼保持更久的時間。第一階段,后端解析服務(wù)會解析出調(diào)用鏈的鷹眼ID,通知鷹眼服務(wù)存儲對應(yīng)的trace日志,成功通知后可以存3天;第二階段感知網(wǎng)關(guān)發(fā)生異常,取出鷹眼ID,通知鷹眼存儲將存儲前置;第三階段,類似場景追蹤,獲取核心場景的鷹眼trace日志,嘗試放在摩天輪平臺上存儲。第一階段已經(jīng)上線,可以做到關(guān)聯(lián)跳轉(zhuǎn)鷹眼平臺,一般從問題發(fā)生到排查都過了5分鐘,因此成功率不高,還需要結(jié)合2、3階段進(jìn)一步提升成功率,正在規(guī)劃開發(fā)中;
  • 平臺能力的建設(shè),基于端側(cè)全鏈路日志做解析,在可視化方面,通過結(jié)構(gòu)化展示全鏈路日志內(nèi)容,方便快速部分節(jié)點的異常;還有就是基于結(jié)構(gòu)化日志,對全鏈路日志中的耗時異常、接口報錯、數(shù)據(jù)大小異常等問題進(jìn)行快速診斷。

以上是今年在運維做的一些嘗試,目的是希望可以通過技術(shù)升級,在排查領(lǐng)域用技術(shù)賦能代替流程賦能。

下面接著繼續(xù)給大家展示下淘寶的實踐和集團(tuán)其它app接入的效果。

全鏈路運維實踐

1 淘寶卡頓問題排查

內(nèi)部同事反饋在海外用淘寶App,出現(xiàn)卡、部分頁面打不開等現(xiàn)象,經(jīng)過上訴排查過程,提取到TLOG日志后。

  • 通過“全鏈路可視化”功能(圖10),可以看到H5頁面spanID為0.1的network狀態(tài)為“失敗”,導(dǎo)致頁面打不開;
  • 通過“全鏈路診斷”耗時異常功能(圖11),可以看到大量network耗時分布在2s、3s+,有的甚至8s+,network階段發(fā)生在請求調(diào)用階段(傳輸),與海外用戶訪問到阿里的CDN節(jié)點慢相關(guān)。

(圖13 全鏈路可視化功能)

(圖14 全鏈路卡頓診斷功能)

2 餓了么主鏈路接入

冷啟全鏈路

(圖14 餓了么全鏈路視圖-冷啟全鏈路)

店鋪全鏈路

(圖15 餓了么全鏈路視圖-店鋪全鏈路)

基于Falco的優(yōu)化實踐

新指標(biāo)體系

現(xiàn)在重點介紹下我們怎么圍繞Falco可觀測模型,從端到端全鏈路視角構(gòu)建線上性能基線,用數(shù)據(jù)驅(qū)動淘寶App體驗持續(xù)改善,首先就是數(shù)據(jù)指標(biāo)體系的構(gòu)建,主要有如下幾點:

  • 指標(biāo)定義和規(guī)范:貼近用戶的感受,圍繞用戶點擊到內(nèi)容呈現(xiàn)到滑動頁面的操作動線來定義相關(guān)指標(biāo),重點采集頁面打開、內(nèi)容上屏、點擊響應(yīng)、滑動等技術(shù)場景,如內(nèi)容展現(xiàn)有頁面可視可交互、圖片上屏指標(biāo),滑動有滑動幀率(手指)、凍幀等指標(biāo)來衡量;
  • 指標(biāo)度量方案:原則是不同領(lǐng)域的指標(biāo)交由對應(yīng)領(lǐng)域負(fù)責(zé),以卡頓指標(biāo)為例,可以是廠商的口徑(蘋果MetricKit)、也可以是自建的口徑(APM的主線程卡頓/ANR等)、還可以是不同業(yè)務(wù)域的自定義指標(biāo)(場景全鏈路),如MTOP請求失敗、詳情頭圖上屏等;
  • 指標(biāo)組成:由線上集合指標(biāo)和線下集合指標(biāo)組成,基于線上和線下數(shù)據(jù)和相關(guān)規(guī)范,立足用戶視角和競對情況牽引APP體驗優(yōu)化。

(圖16 App性能指標(biāo)體系)

  1. APM為例,定義了滑動相關(guān)的指標(biāo)如下:

(圖17 APM相關(guān)指標(biāo)定義方案)

  1. 場景全鏈路為例,某個具體業(yè)務(wù)下,對于用戶的一次交互行為,從發(fā)起響應(yīng)到結(jié)束響應(yīng),從前端到服務(wù)端到客戶端的完整調(diào)用鏈路,詳情基于場景全鏈路下的詳情首屏指標(biāo):

(圖18 場景全鏈路-詳情首屏定義)

還有其他等等... ...

新指標(biāo)體系下的優(yōu)化

FY22 平臺技術(shù)圍繞全鏈路視角,以體驗為出口,深入業(yè)務(wù)開展摸排優(yōu)化,圍繞指標(biāo)定義并拆解問題域,面向用戶真實體感開展各大專項優(yōu)化。我們自底向上一一介紹,通用的網(wǎng)絡(luò)層策略優(yōu)化,如何圍繞請求周期,從連通性->傳輸層->超時策略提升;面向用戶體感的有技術(shù)策略升級,如網(wǎng)關(guān)和圖片的優(yōu)化;面向業(yè)務(wù)場景的技術(shù)改造,會場框架的預(yù)處理預(yù)加載、安全保鏢的輕量化實踐,甚至是業(yè)務(wù)上的體驗分級,如首頁信息流低端機下不啟用端智能,下面會重點介紹相關(guān)實踐。

(圖19 淘寶App全鏈路優(yōu)化技術(shù)方案)

1 請求精簡提速-極簡調(diào)用實踐

以MTOP請求作為一個場景,鏈路主要涉及「MTOP到網(wǎng)絡(luò)庫」的交互,通過對全鏈路線程模型現(xiàn)狀分析,從MTOP發(fā)起到網(wǎng)絡(luò)層接收到會幾點會導(dǎo)致請求慢:

  • 數(shù)據(jù)拷貝多:現(xiàn)有網(wǎng)絡(luò)層機制,網(wǎng)絡(luò)庫存在hook攔截處理,基于NSURLConnection + "URL Loading System" 轉(zhuǎn)發(fā)到網(wǎng)絡(luò)庫進(jìn)行網(wǎng)絡(luò)傳輸,涉及多次數(shù)據(jù)拷貝,中轉(zhuǎn)攔截處理非常耗時;
  • 線程切換多:線程模型過于復(fù)雜,完成一次請求頻繁切換線程;
  • 異步轉(zhuǎn)同步:原有請求使用一個隊列 NSOperationQueue 來處理任務(wù),底層維護(hù)的這個隊列把請求和響應(yīng)綁在一起,使得發(fā)送之后要等待響應(yīng)結(jié)果回來才會釋放,"HTTP Operation" 占住完整的一個HTTP收發(fā)過程的全部IO,違背了網(wǎng)絡(luò)請求的并行性,operation queue容易打滿阻塞。

以上幾點問題,在大批量請求、系統(tǒng)資源競爭激烈場景下下(冷啟動,幾十個請求一擁而上),更為明顯。

(圖20 線程模型優(yōu)化前后-極簡調(diào)用)

改造方案,通過MTOP直接調(diào)用網(wǎng)絡(luò)庫接口來獲得較大性能體驗提升

  • 簡化線程模型: 跳過系統(tǒng)URL Loading System hook機制,完成收發(fā)數(shù)據(jù)線程切換,減少線程切換;
  • 避免弱網(wǎng)阻塞:數(shù)據(jù)包Sending 與 Receiving 拆分處理,空口長RT不影響 I/O 并發(fā)容量;
  • 汰換廢棄API:升級老舊NSURLConnection 到直接調(diào)用 網(wǎng)絡(luò)庫API。

數(shù)據(jù)效果:可以看到,在系統(tǒng)資源更為緊張環(huán)境下,如低端機上優(yōu)化幅度更為明顯。

(圖21 極簡調(diào)用AB優(yōu)化幅度)

2 弱網(wǎng)策略優(yōu)化-Android網(wǎng)絡(luò)多通道實踐

在WIFI信號差、弱網(wǎng)環(huán)境下,有時候多次重試對成功率提升效果并不明顯。系統(tǒng)提供了一種能力,允許設(shè)備在WIFI環(huán)境下將請求切換蜂窩網(wǎng)卡的能力。網(wǎng)絡(luò)應(yīng)用層可以利用該技術(shù),減少請求的超時等一類錯誤,提升請求的成功率。

在Android 21之后,系統(tǒng)提供了新的獲取網(wǎng)絡(luò)對象的方式,即使設(shè)備當(dāng)前具有通過以太網(wǎng)的數(shù)據(jù)連接,應(yīng)用程序也可以使用此方法來獲取連接的蜂窩網(wǎng)絡(luò)。

所以,當(dāng)用戶設(shè)備同時存在WIFI和蜂窩網(wǎng)絡(luò)的情況下,可以在特定策略下將不同請求同時調(diào)度到以太網(wǎng)和蜂窩網(wǎng)兩個網(wǎng)卡通道上,實現(xiàn)網(wǎng)絡(luò)加速。

核心改動點:

  • 方案前提:當(dāng)前Wi-Fi網(wǎng)絡(luò)環(huán)境是否支持蜂窩網(wǎng)絡(luò);
  • 觸發(fā)時機:當(dāng)請求發(fā)出超過一定時間未返回數(shù)據(jù)后,觸發(fā)切換蜂窩網(wǎng)絡(luò)重試的請求,原先流程的請求不中斷,使用優(yōu)先返回的通道的請求響應(yīng),晚返回的會取消;
  • 時間控制:根據(jù)特定場景Orange配置,后續(xù)還需要靈活根據(jù)網(wǎng)絡(luò)強弱來動態(tài)調(diào)整;
  • 產(chǎn)品形態(tài)&合規(guī)上:使用時給用戶透出文案 “正在同時使用WIFI和移動網(wǎng)絡(luò)改善瀏覽體驗,可在設(shè)置-通用里關(guān)閉”,彈出策略為 每次啟動首次功能觸發(fā)。

(圖22 Android多通道網(wǎng)絡(luò)能力優(yōu)化+用戶合規(guī)授權(quán))

數(shù)據(jù)效果:在網(wǎng)絡(luò)資源競爭劇烈的情況下,WiFi+蜂窩雙通道網(wǎng)絡(luò)場景下,長尾和超時率優(yōu)化較為明顯,AB數(shù)據(jù),首頁API, P99/P999分位性能分別提升23%/63%,錯誤率減少1.19‰,首頁圖片, P99/P999分位性能分別提升12%/58%,錯誤率減少0.41‰。

3 技術(shù)策略分級-圖片分級實踐

不同設(shè)備性能千差萬別,業(yè)務(wù)的復(fù)雜度也越來越高,很多業(yè)務(wù)無法在低端設(shè)備上讓用戶體驗到應(yīng)有的效果,反而會帶來卡頓等不良的體驗。以往會通過“延遲、并發(fā)、預(yù)加載”等手段來優(yōu)化性能,但只是規(guī)避了問題,核心鏈路仍然要要直面關(guān)鍵的調(diào)用耗時。所以,我們需要對業(yè)務(wù)做體驗分級,基于對業(yè)務(wù)流程的分級處理,讓高端設(shè)備體驗最完美復(fù)雜的流程,低端設(shè)備也能順滑的使用核心功能,理想是期望實現(xiàn) 用戶體驗 & 業(yè)務(wù)核心指標(biāo) 的雙高,退一步來說,讓部分功能有損(不影響核心業(yè)務(wù)指標(biāo))的情況下,讓性能體驗更佳,初步的設(shè)想是希望分2步走來實現(xiàn):

  • 第一階段,業(yè)務(wù)分級需要豐富的策略庫和判斷條件來實現(xiàn)分級,我們將在核心組件上沉淀這部分通用能力,幫助業(yè)務(wù)快速的實現(xiàn)業(yè)務(wù)分級能力;
  • 第二階段,隨著大量的業(yè)務(wù)都接入了分級能力,積累了大量的業(yè)務(wù)分級策略以及AB數(shù)據(jù),那么可以去做單點業(yè)務(wù)分級策略的推薦&最優(yōu)化,實現(xiàn)大量相似的業(yè)務(wù)可以快速復(fù)用,提升效率。

傳統(tǒng)CDN適配規(guī)則會根據(jù)網(wǎng)絡(luò)、view大小、系統(tǒng)等因素動態(tài)拼裝獲取「最佳」的圖片尺寸來減少網(wǎng)絡(luò)帶寬、位圖內(nèi)存占用,提升設(shè)備圖片加載體驗,本次設(shè)備分級視角,并且會基于UED給出的規(guī)范,實現(xiàn)壓縮參數(shù)可配置,擴(kuò)展原有CDN適配規(guī)則,實現(xiàn)不同機型的圖片分級策略,通過該能力,可以讓圖片的尺寸進(jìn)一步縮小,加快圖片上屏。

(圖23 圖片設(shè)備分級規(guī)則)

4 輕量化鏈路架構(gòu)-安全免簽實踐

外鏈拉端鏈路從啟動到海關(guān)請求再到落地頁加載(主請求仍是MTOP),涉及多次安全加簽,加簽屬于CPU密集型任務(wù),低端機長尾明顯,拉端耗時過長會導(dǎo)致流量跳失,F(xiàn)Y22 S1 在巨浪業(yè)務(wù)上,拉端鏈路做了很多性能優(yōu)化,優(yōu)化性能可以帶來跳失率的降低,目前性能大頭海關(guān)請求,海關(guān)請求安全加簽耗時占比高,因此希望跳過安全加簽,業(yè)務(wù)可以根據(jù)情況使用,提升進(jìn)端的流量價值,鏈路涉及到MTOP、Aserver(統(tǒng)一接入層)、安全多方改造:

(圖24 安全免簽架構(gòu)變化)

  • 網(wǎng)關(guān)協(xié)議升級:協(xié)議升級支持免簽,對外提供設(shè)置免簽接口,若業(yè)務(wù)API設(shè)置免簽,攜帶頭到網(wǎng)絡(luò)庫;
  • AMDC調(diào)度服務(wù):穩(wěn)定性考慮,目前短期會先通過AMDC(無線網(wǎng)絡(luò)策略調(diào)度服務(wù))調(diào)度到線上安全生產(chǎn)環(huán)境,因此AMDC調(diào)度模塊會根據(jù)描述標(biāo)識判斷是否返回客戶端免簽vip,功能穩(wěn)定性后,會靈活調(diào)度到線上主站環(huán)境;
  • 驗簽?zāi)K遷移:安全延簽?zāi)芰η爸迷贏Server接入層,基于運維成本考慮,能力會從Aserver統(tǒng)一遷移到安全,后續(xù)Aserver不會有延簽?zāi)K,安全會根據(jù)API/header特征 決定啟用驗簽等功能;
  • MTOP免簽錯誤重試:免簽情況下,MTOP層遇到非法簽名請求失敗會觸發(fā)降級老鏈路,保障用戶體驗。

總結(jié)&展望

總結(jié):本文主要闡述了面對移動端現(xiàn)有挑戰(zhàn),如何通過實現(xiàn)調(diào)用鏈路Tracing、標(biāo)準(zhǔn)Logging及場景化追蹤完成可觀測能力的建設(shè),并基于全鏈路視角和新可觀測能力,打造全鏈路運維體系和性能持續(xù)優(yōu)化體系,補齊移動端長久缺失的調(diào)用鏈追蹤能力、解決復(fù)雜調(diào)用場景下問題的快速定位、改變過去拉群人肉排查的低效過程,開始了流程賦能到技術(shù)賦能的轉(zhuǎn)變,并圍繞該能力構(gòu)建全鏈路Metrics指標(biāo),打造全鏈路性能指標(biāo)體系,深入業(yè)務(wù)場景展開治理,升級平臺技術(shù)能力,用數(shù)據(jù)驅(qū)動業(yè)務(wù)體驗改善和體驗的長效追蹤。

不足:雖然淘寶App陸續(xù)在接入各類場景,但離15分鐘內(nèi)定位出問題還有不小的差距,相關(guān)的卡點還較多,如日志上報成功率、服務(wù)端日志獲取的有效性、問題定位效率的提升、接入源頭的數(shù)據(jù)質(zhì)量檢驗產(chǎn)品化&技術(shù)化、領(lǐng)域技術(shù)方對問題的認(rèn)識和持續(xù)沉淀結(jié)構(gòu)化信息,最后就是整個產(chǎn)品的用戶體驗,需要持續(xù)優(yōu)化。

展望:延續(xù)阿里巴巴移動技術(shù)小組的移動原生技術(shù)理念,我們要做好技術(shù)做好體驗,需深入移動域腹地,直面東西向多研發(fā)框架、南北向端到端全鏈路等領(lǐng)域挑戰(zhàn)。18年體驗優(yōu)化一期,我們在請求領(lǐng)域就引入類似理念并開展嘗試,直到如今尋求到合適的結(jié)構(gòu)化理論基礎(chǔ),并通過立足移動端特性開展深入實踐,持續(xù)做厚領(lǐng)域問題的定義和解決模型。希望打造出移動域可觀測技術(shù)體系、形成架構(gòu)沉淀。

責(zé)任編輯:張燕妮 來源: 阿里巴巴移動技術(shù)
相關(guān)推薦

2022-11-18 16:02:11

博睿數(shù)據(jù)可觀測性APM

2023-07-07 07:27:14

全鏈路虎牙APM

2022-01-04 17:08:02

全鏈路觀測平臺

2022-11-26 09:49:07

分布式鏈路追蹤技術(shù)

2023-01-30 22:34:44

Node.js前端

2023-09-24 23:35:46

云原生Kubernetes

2017-07-12 13:49:45

微服務(wù)架構(gòu)數(shù)據(jù)共享

2025-02-17 09:00:00

DeepSeek人工智能AI

2023-09-20 20:11:07

Java

2023-01-12 09:40:28

數(shù)字人建模動畫

2021-06-29 16:12:21

詞: 云架構(gòu)混合云云計算

2009-03-04 09:24:00

小額支付IVRRFID

2009-03-20 10:04:00

4G移動通信

2025-05-06 07:51:10

2021-11-19 09:40:50

數(shù)據(jù)技術(shù)實踐

2011-03-21 15:29:46

2018-01-03 00:38:20

大數(shù)據(jù)Hadoop分布式文件系統(tǒng)
點贊
收藏

51CTO技術(shù)棧公眾號