移動域全鏈路可觀測架構和關鍵技術

阿里巴巴移動技術發表於2022-03-11
架構

作者：劉長青(執水)

本文側重闡述手淘團隊對移動領域全鏈路技術理念的原創性引入，整篇約1.2萬字、閱讀需要15分鐘，讀者將收穫移動技術域體驗優化的思路轉變，以及軟體定義體驗的沉澱和研發實踐。

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/o... 。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接入的效果。

全鏈路運維實踐

淘寶卡頓問題排查

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

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

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

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

餓了麼主鏈路接入

冷啟全鏈路

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

店鋪全鏈路

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

基於Falco的優化實踐

新指標體系

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

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

（圖16 App效能指標體系）

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

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

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

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

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

新指標體系下的優化

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

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

請求精簡提速-極簡呼叫實踐

以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優化幅度）

弱網策略優化-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‰。

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

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

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

傳統CDN適配規則會根據網路、view大小、系統等因素動態拼裝獲取「最佳」的圖片尺寸來減少網路頻寬、點陣圖記憶體佔用，提升裝置圖片載入體驗，本次裝置分級視角，並且會基於UED給出的規範，實現壓縮引數可配置，擴充套件原有CDN適配規則，實現不同機型的圖片分級策略，通過該能力，可以讓圖片的尺寸進一步縮小，加快圖片上屏。

（圖23 圖片裝置分級規則）

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

外鏈拉端鏈路從啟動到海關請求再到落地頁載入（主請求仍是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年體驗優化一期，我們在請求領域就引入類似理念並開展嘗試，直到如今尋求到合適的結構化理論基礎，並通過立足移動端特性開展深入實踐，持續做厚領域問題的定義和解決模型。希望打造出移動域可觀測技術體系、形成架構沉澱。

【參考資料】

我們招聘啦！

我們是大淘寶平臺技術的「終端平臺技術部」。我們擁有世界最大的電商場景和一流的移動技術平臺，打造著領先行業的技術產品，服務遍佈全世界10億＋的消費者，處理每日千億級的海量使用者請求。

作為阿里最重要的客戶端團隊，我們負責淘寶移動域研發運維支撐、原生技術挖掘、核心技術建設，包括不限於客戶端體驗、框架及創新體驗、廠商與系統技術、使用者增長及移動平臺。無論是基礎設施、業務創新還是技術發展，我們團隊都能為你提供巨大的機遇和成長空間，期待您加入

簡歷投遞方式

yangqing.yq@alibaba-inc.com

關注【阿里巴巴移動技術】微信公眾號，每週 3 篇移動技術實踐&乾貨給你思考！

相關文章