App 現有架構挑戰

2013年開始All in無線到如今，阿里集團移動技術發展十余年，歷經幾個關鍵階段：

• 第一階段，解決大規模業務并發研發的痛點，定義了Atlas（容器化框架, 提供組件解耦、動態性等支持）架構；
• 第二階段，建設ACCS（淘寶無線全雙工、低延時、高安全的通道服務）長連雙工加密網絡能力，補齊端到端互操作移動服務能力追趕行業；
• 第三階段，面向業務特性建設Weex、小程序等動態化研發框架，移動技術進入動態化跨平臺時期。

中后期通過阿里移動小組機制進行各BU拉通和能力共建。自此，移動基礎設施基本成型，各個領域各自沉淀若干組做到能力復用，App基本形成上層業務、中間研發框架或容器、基礎能力三層的架構。我們團隊作為無線端側基礎設施的承建方，過去重點是負責集團移動端的基礎能力建設，近年來，團隊重點深入淘寶業務場景展開性能優化，通過體驗優化項目橫向剖析App架構和及相關調用鏈路，感受到集團App普遍存在如下共性問題：

(圖1 淘寶App架構挑戰)

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

以上是從APP結構的角度對當前客戶端在運維排查、度量監控、全鏈路優化等方面的不足進行的一些思考，也是我們后續的發力方向。

可觀測體系

監控到可觀測性的演變

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

相比傳統的監控，可觀測性能夠通過結合數據，并且將數據有機聯系在一起，產生更好的連接，幫助我們更好的觀察系統的運行狀況，快速定位和解決問題。「監控告訴我們系統的哪些部分是工作的，而可觀測性告訴我們那里為什么不工作了」，下圖2說明了兩者之間的關系，監控側重宏觀大盤展現，而可觀測性包含了傳統監控的范疇。

(圖2 監控和可觀測的關系)

從上圖來看，核心還是觀察各個模塊以及關鍵調用和依賴等的輸出，基于這些輸出來判斷整體的工作狀態，業界通常會把這些關鍵點總結為Traces、Loggings、Metrics。

可觀測性關鍵數據

(圖3 可觀測性關鍵數據)

結合Traces、Loggings、Metrics的定義和淘寶現有情況，做了一些解讀：

• Loggings（日志）：基于現有TLOG（無線端到端日志系統）日志通道，展現的是App運行時產生的事件或者程序在執行的過程中間產生的一些日志，可以詳細解釋系統的運行狀態，如頁面跳轉、請求日志、全局CPU、內存使用等信息，多數日志是沒有實現串聯的，現在引入結構化的調用鏈路日志后，日志在調用鏈場景結構化后其實可以轉變為Trace，支撐單機排查；
• Metrics（指標）：是聚合后的數值，偏宏觀大盤使用，對于問題定位缺乏細節展示，一般有各種維度、指標，Metrics數據量一般很大，需要針對場景做一些采樣控制；
• Traces（追蹤）：是最標準的調用日志，除了定義了調用的父子關系外（一般通過TraceID、SpanID），一般還會定義操作的服務、方法、屬性、狀態、耗時等詳細信息，通過Trace能夠代替一部分Logs的功能，長期看通過Trace的聚合也能得到每個模塊、方法的Metrics度量指標，但日志存儲大，成本高。

全鏈路可觀測性架構

上述可觀測體系理念在后端有一些實踐落地，但回歸到移動領域的特性和現狀，有種種問題如下：

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

因此，我們需要圍繞以上這些問題對移動技術領域全鏈路進行定義，并建立起相關領域級的分析能力和好的評價標準，才能更深刻的洞察移動端的問題所在，才能在問題排查和性能度量領域持續服務好集團各App以及跨域的問題。

(圖4 全鏈路可觀測架構定義設想)

• 數據層：定義指標規范和采集方案，基于Opentracing（分布式跟蹤規范）數據上報；
• 領域層：圍繞問題發現到問題定位、性能持續優化體系、技術升級沉淀幾方面演進；
• 平臺層：沉淀集團&競對視角的比對，結合線上線下指標，引入廠商視角，驅動App性能提升；
• 業務層：全鏈路視角，打通端到端，除了客戶端同學，還可以服務不同技術棧跨域的研發人員。

回顧全鏈路可觀測項目的目標，我們設定為“打造全鏈路可觀測體系，改善性能并驅動業務體驗改善，提升問題定位效率”，后續章節會重點講解每一層的實踐。

移動端opentracing可觀測架構

全鏈路構成

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

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

• 場景定義：一次用戶操作為一個場景，如點擊、滑動都是單獨的場景，場景也可以是多個單個場景的組合；
• 能力分層：不同場景，有業務類，框架類、容器類、請求類的調用，可以對每個領域進行分層；
• 階段定義：不同分層有各自的階段。如框架類有4個本地階段，而請求類可以包含后端服務端處理階段；
• 用戶動線：一次動線由若干場景組成。

全鏈路，就是把復雜的大調用分解為有限個結構化的小調用，并且可以衍生出各種case：

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

Falco-基于OpenTracing模型

全鏈路為了支持Logs + Metrics + Tracing 行業標準，引入分布式調用規范opentracing協議，在上述的客戶端架構上進行二次建模（后續簡稱為Falco）。

OpenTracing 規范是 Falco 的模型基礎，以下不再列舉，完整可參考OpenTracing設計規范，https://opentracing.io/docs/overview/。Falco定義了端側領域的調用鏈追蹤模型，主要表結構如下：

(圖6 Falco數據表模型)

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

Falco-關鍵要點

(圖7 Falco關鍵實現)

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

(圖8 Falco領域問題模型)

基于Falco的運維實踐

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

(圖9 問題扭轉用戶動線以及運維系統)

宏觀指標體系

以端性能橫向戰役為契機，基于用戶體感的體驗，APM開啟了相關升級工作，核心涉及啟動、外鏈以及各業務場景下的可視可交互指標，如何做到讓指標對應的終點更貼近用戶體感，主要有以下一些工作：

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

以啟動為例，APM 在 校準后，包含了圖片上屏等階段后，數據雖然上漲了，但更符合業務方訴求。

(圖10 校準后啟動數據趨勢)

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

(圖11 校準后外鏈前后口徑數據對比)

基于此戰役，已實現打通若干研發框架可視指標和校正工作。

單機排查體系

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

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

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

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

下面接著繼續給大家展示下淘寶的實踐和集團其它app接入的效果。

全鏈路運維實踐

1 淘寶卡頓問題排查

內部同事反饋在海外用淘寶App，出現卡、部分頁面打不開等現象，經過上訴排查過程，提取到TLOG日志后。

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

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

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

2 餓了么主鏈路接入

冷啟全鏈路

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

店鋪全鏈路

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

基于Falco的優化實踐

新指標體系

現在重點介紹下我們怎么圍繞Falco可觀測模型，從端到端全鏈路視角構建線上性能基線，用數據驅動淘寶App體驗持續改善，首先就是數據指標體系的構建，主要有如下幾點：

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

（圖16 App性能指標體系）

1. APM為例，定義了滑動相關的指標如下：

(圖17 APM相關指標定義方案)

2. 場景全鏈路為例，某個具體業務下，對于用戶的一次交互行為，從發起響應到結束響應，從前端到服務端到客戶端的完整調用鏈路，詳情基于場景全鏈路下的詳情首屏指標：

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

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

新指標體系下的優化

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

（圖19 淘寶App全鏈路優化技術方案）

1 請求精簡提速-極簡調用實踐

以MTOP請求作為一個場景，鏈路主要涉及「MTOP到網絡庫」的交互，通過對全鏈路線程模型現狀分析，從MTOP發起到網絡層接收到會幾點會導致請求慢：

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

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

（圖20 線程模型優化前后-極簡調用）

改造方案，通過MTOP直接調用網絡庫接口來獲得較大性能體驗提升

• 簡化線程模型: 跳過系統URL Loading System hook機制，完成收發數據線程切換，減少線程切換；
• 避免弱網阻塞：數據包Sending 與 Receiving 拆分處理，空口長RT不影響 I/O 并發容量；
• 汰換廢棄API：升級老舊NSURLConnection 到直接調用 網絡庫API。

數據效果：可以看到，在系統資源更為緊張環境下，如低端機上優化幅度更為明顯。

（圖21 極簡調用AB優化幅度）

2 弱網策略優化-Android網絡多通道實踐

在WIFI信號差、弱網環境下，有時候多次重試對成功率提升效果并不明顯。系統提供了一種能力，允許設備在WIFI環境下將請求切換蜂窩網卡的能力。網絡應用層可以利用該技術，減少請求的超時等一類錯誤，提升請求的成功率。

在Android 21之后，系統提供了新的獲取網絡對象的方式，即使設備當前具有通過以太網的數據連接，應用程序也可以使用此方法來獲取連接的蜂窩網絡。

所以，當用戶設備同時存在WIFI和蜂窩網絡的情況下，可以在特定策略下將不同請求同時調度到以太網和蜂窩網兩個網卡通道上，實現網絡加速。

核心改動點：

• 方案前提：當前Wi-Fi網絡環境是否支持蜂窩網絡；
• 觸發時機：當請求發出超過一定時間未返回數據后，觸發切換蜂窩網絡重試的請求，原先流程的請求不中斷，使用優先返回的通道的請求響應，晚返回的會取消；
• 時間控制：根據特定場景Orange配置，后續還需要靈活根據網絡強弱來動態調整；
• 產品形態&合規上：使用時給用戶透出文案 “正在同時使用WIFI和移動網絡改善瀏覽體驗，可在設置-通用里關閉”，彈出策略為 每次啟動首次功能觸發。

（圖22 Android多通道網絡能力優化+用戶合規授權）

數據效果：在網絡資源競爭劇烈的情況下，WiFi+蜂窩雙通道網絡場景下，長尾和超時率優化較為明顯，AB數據，首頁API， P99/P999分位性能分別提升23%/63%，錯誤率減少1.19‰，首頁圖片， P99/P999分位性能分別提升12%/58%，錯誤率減少0.41‰。

3 技術策略分級-圖片分級實踐

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

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

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

（圖23 圖片設備分級規則）

4 輕量化鏈路架構-安全免簽實踐

外鏈拉端鏈路從啟動到海關請求再到落地頁加載（主請求仍是MTOP），涉及多次安全加簽，加簽屬于CPU密集型任務，低端機長尾明顯，拉端耗時過長會導致流量跳失，FY22 S1 在巨浪業務上，拉端鏈路做了很多性能優化，優化性能可以帶來跳失率的降低，目前性能大頭海關請求，海關請求安全加簽耗時占比高，因此希望跳過安全加簽，業務可以根據情況使用，提升進端的流量價值，鏈路涉及到MTOP、Aserver（統一接入層）、安全多方改造：

（圖24 安全免簽架構變化）

• 網關協議升級：協議升級支持免簽，對外提供設置免簽接口，若業務API設置免簽，攜帶頭到網絡庫；
• AMDC調度服務：穩定性考慮，目前短期會先通過AMDC（無線網絡策略調度服務）調度到線上安全生產環境，因此AMDC調度模塊會根據描述標識判斷是否返回客戶端免簽vip，功能穩定性后，會靈活調度到線上主站環境；
• 驗簽模塊遷移：安全延簽能力前置在AServer接入層，基于運維成本考慮，能力會從Aserver統一遷移到安全，后續Aserver不會有延簽模塊，安全會根據API/header特征 決定啟用驗簽等功能；
• MTOP免簽錯誤重試：免簽情況下，MTOP層遇到非法簽名請求失敗會觸發降級老鏈路，保障用戶體驗。

總結&展望

總結：本文主要闡述了面對移動端現有挑戰，如何通過實現調用鏈路Tracing、標準Logging及場景化追蹤完成可觀測能力的建設，并基于全鏈路視角和新可觀測能力，打造全鏈路運維體系和性能持續優化體系，補齊移動端長久缺失的調用鏈追蹤能力、解決復雜調用場景下問題的快速定位、改變過去拉群人肉排查的低效過程，開始了流程賦能到技術賦能的轉變，并圍繞該能力構建全鏈路Metrics指標，打造全鏈路性能指標體系，深入業務場景展開治理，升級平臺技術能力，用數據驅動業務體驗改善和體驗的長效追蹤。

不足：雖然淘寶App陸續在接入各類場景，但離15分鐘內定位出問題還有不小的差距，相關的卡點還較多，如日志上報成功率、服務端日志獲取的有效性、問題定位效率的提升、接入源頭的數據質量檢驗產品化&技術化、領域技術方對問題的認識和持續沉淀結構化信息，最后就是整個產品的用戶體驗，需要持續優化。

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