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

2013年開(kāi)始All in無(wú)線到如今，阿里集團(tuán)移動(dòng)技術(shù)發(fā)展十余年，歷經(jīng)幾個(gè)關(guān)鍵階段：

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

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

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

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

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

可觀測(cè)體系

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

移動(dòng)端opentracing可觀測(cè)架構(gòu)

全鏈路構(gòu)成

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

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

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

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

• 「單場(chǎng)景+單階段」的組合全鏈路；
• 「單場(chǎng)景+若干分層+若干階段」組合的全鏈路；
• 「若干場(chǎng)景+若干分層+若干階段」組合的全鏈路；
• ... ...

Falco-基于OpenTracing模型

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

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

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

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

Falco-關(guān)鍵要點(diǎn)

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

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

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

基于Falco的運(yùn)維實(shí)踐

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

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

宏觀指標(biāo)體系

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

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

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

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

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

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

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

單機(jī)排查體系

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

(圖12 單機(jī)排查問(wèn)題定位核心功能)

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

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

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

全鏈路運(yùn)維實(shí)踐

1 淘寶卡頓問(wèn)題排查

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

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

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

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

2 餓了么主鏈路接入

冷啟全鏈路

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

店鋪全鏈路

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

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

新指標(biāo)體系

現(xiàn)在重點(diǎn)介紹下我們?cè)趺磭@Falco可觀測(cè)模型，從端到端全鏈路視角構(gòu)建線上性能基線，用數(shù)據(jù)驅(qū)動(dòng)淘寶App體驗(yàn)持續(xù)改善，首先就是數(shù)據(jù)指標(biāo)體系的構(gòu)建，主要有如下幾點(diǎn)：

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

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

1. APM為例，定義了滑動(dòng)相關(guān)的指標(biāo)如下：

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

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

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

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

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

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

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

1 請(qǐng)求精簡(jiǎn)提速-極簡(jiǎn)調(diào)用實(shí)踐

以MTOP請(qǐng)求作為一個(gè)場(chǎng)景，鏈路主要涉及「MTOP到網(wǎng)絡(luò)庫(kù)」的交互，通過(guò)對(duì)全鏈路線程模型現(xiàn)狀分析，從MTOP發(fā)起到網(wǎng)絡(luò)層接收到會(huì)幾點(diǎn)會(huì)導(dǎo)致請(qǐng)求慢：

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

以上幾點(diǎn)問(wèn)題，在大批量請(qǐng)求、系統(tǒng)資源競(jìng)爭(zhēng)激烈場(chǎng)景下下(冷啟動(dòng)，幾十個(gè)請(qǐng)求一擁而上)，更為明顯。

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

改造方案，通過(guò)MTOP直接調(diào)用網(wǎng)絡(luò)庫(kù)接口來(lái)獲得較大性能體驗(yàn)提升

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

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

（圖21 極簡(jiǎn)調(diào)用AB優(yōu)化幅度）

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

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

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

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

核心改動(dòng)點(diǎn)：

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

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

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

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

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

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

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

（圖23 圖片設(shè)備分級(jí)規(guī)則）

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

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

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

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

總結(jié)&展望

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

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

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