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)定義方案)

2. 場景全鏈路為例，某個具體業(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)沉淀。