作者 | 千風

本文分為三個部分：概述中引入了積壓問題，并介紹了函數計算異步調用基本鏈路；并在指標介紹部分詳細介紹了指標查看方式，分類解讀了不同的指標含義；最后以一個常見的異步請求積壓場景為例，介紹如何在 1 分鐘內快速定位積壓問題。

為異步調用保駕護航

使用函數計算異步調用的開發者最關心的問題是：調用請求能否在預期的時間內被處理完成。若沒能處理完成，那么在客戶眼中就是異步調用請求積壓了，然而基于之前函數計算異步調用指標體系，無論是定位積壓，還是查看積壓，過程都是十分繁瑣的。

針對以上問題，函數計算推出了一系列異步調用請求積壓相關的指標，能夠幫助用戶快速定位請求積壓，向用戶展示積壓量化值。本文將詳細介紹如何通過這些監控指標快速定位到函數異步調用出現的積壓問題，為各位開發者講解升級后的異步調用指標體系。

在開始之前，先簡單介紹下函數計算異步調用。

異步調用是函數計算調用函數的一種方式，通過異步調用你不僅可以確保函數會至少執行一次，還可以保存調用執行過程中的狀態轉換信息和執行結果，其調用鏈路如下所示：

用戶/事件源發起異步調用請求后會立刻返回本次請求 ID，隨后函數計算系統將本次調用的相關信息轉換為消息的格式，放入 MNS 消息隊隊列中供系統內下游模塊消費，下游模塊會基于解析出來的調用消息進行函數調用。

調用完成后，如果函數配置了 Destination，則系統會基于調用結果以及 Destination 內容進行進一步處理，Destination 相關內容介紹請參考異步調用文檔：

https://help.aliyun.com/document_detail/181866.html

指標升級

升級后的函數計算異步調用鏈路監控指標主要新增了如下幾類：

下面我們將對上述指標進行詳細解讀。

指標查看

目前可以通過函數計算控制臺或者 Serverless Devs 工具這兩種方式查看函數的監控指標大盤，下面我們將以控制臺為例，指導大家如何查看異步調用鏈路相關的監控指標，基于 Serverless Devs 的查看方式可以參考：

https://github.com/devsapp/fc/blob/main/docs/zh/command/metrics.md

下面介紹的步驟前提是已開通了函數計算服務；且成功創建了服務以及函數，如果還未進行這些操作，請參考使用控制臺創建函數：

https://help.aliyun.com/document_detail/51783.html

首先打開函數計算控制臺，點擊左側監控大盤標簽，滑倒底部，可以查看到該地域所有服務的異步調用處理情況以及異步消息處理平均延時概覽表格：

此時我們點擊任意一個服務名稱，進入后，可以看到該服務下所有函數的異步調用處理情況；以及異步消息處理平均延時概覽表格：

接下來我們點擊任意一個函數名稱，進入后可以看到所有函數緯度的監控指標，并以圖的形式展示：

至此，我們已經學會了這些指標的查看途徑。下面繼續為各位開發者介紹解讀上述異步鏈路相關指標。

指標解讀

我們將根據不同的指標類型對監控指標進行分類解讀。

異步調用處理情況

異步請求入隊

異步調用中，到達函數計算的請求數，當入隊請求數大于請求處理完成數時，表示有請求積壓，函數處理異步請求的速度小于異步請求發起的速度。請調整函數彈性伸縮（含預留資源）上限，參考：

https://help.aliyun.com/document_detail/185038.html#task-2538034

或可釘釘搜索加入阿里函數計算官網客戶群（11721331）聯系我們進行處理圖片。

異步請求處理完成

異步調用中，函數計算處理完成的請求數，異步請求處理完成數量，應始終不大于異步請求入隊的數量。

異步請求積壓數

已經到達函數計算的異步請求中，等待處理以及正在處理中的請求統一視為積壓請求， 這些請求的數量為異步消息積壓數，當這個值不為 0 時，表示異步調用請求是有積壓的。

該指標將異步調用請求積壓量化，解決積壓數不可見問題，極大提高了異步調用的可觀測性，也是本次升級的重要內容之一。

異步請求處理延遲

平均處理時延

函數異步調用請求從進入處理隊列到開始處理的時延，按指定時間粒度統計求平均值。當該值高于預期時，表明函數異步調用請求可能存在積壓。

“異步請求入隊”、“異步請求處理完成” 以及 “平均處理延時” 這三個指標被放置在監控大盤的概覽圖表中，旨在幫助用戶快速定位到出現積壓的函數，解決積壓定位難的問題。

1 分鐘定位積壓問題

在之前的異步調用指標體系下，如果想要定位積壓問題，首先需要找到積壓函數，此時需要逐個函數查看其函數監控指標詳情，定位成功后，也無法直觀看到具體的積壓量化值。

升級后的異步調用指標體系能夠很好地解決積壓問題定位難以及積壓量化的問題。下面將圍繞積壓問題的場景，描述如何使用上述指標快速定位積壓問題。

業務場景

問題描述：

小張的業務涉及到三個函數，且都是異步調用，某天用戶的業務出了問題，每個環節的異步處理時延都增大了。為了快速定位問題，用戶想到了異步鏈路監控指標，進行了如下定位動作。

定位過程：

首先打開地域級別的監控大盤，選擇目標時間段，查看該地域下各個服務的監控指標；

發現多個服務的異步調用平均處理延時高于預期，同時其異步請求入隊數均大于請求處理完成數，表示這些服務都有一定程度異步調用消息積壓，且 A-Service 的異步請求入隊數量和異步調用請求完成數差別最大，積壓最嚴重，點擊 A-Service 查看監控指標：

可以看到該服務下的函數 A-Function 是積壓源，點擊 A-Function 查看函數緯度的監控指標：

從請求積壓數圖中可以看到積壓是從 15:07 時間開始的，當前該賬號下未完成的異步調用請求數最大時大約有 7000 左右 ，同時異步調用請求處理平均時延在逐步升高，目前是 30 萬毫秒左右。每分鐘處理的異步調用請求數在 800 -- 900 之間。

注：由于小張目前使用的是賬號級別共享隊列，因此異步請求積壓數顯示的整個賬號下的異步調用請求積壓數，如因業務需要，函數需要獨享隊列，可以聯系函數計算團隊進行開通。

進一步發現，地域按量實例數圖中實例數已經打滿，因此定位到原因是因為 A-Function 的請求激增，賬號級別的按量實例數限制打滿了，使得其他函數的異步調用也受到了影響，導致業務每個環節都受到了影響。

問題解決：

定位到問題后，小張立刻聯系了函數計算團隊，基于業務量進行了地域按量實例限制調整。

同時 A-Function 調用量最大，可能會對地域緯度的異步調用請求調度以及按量實例數產生一定的沖擊，對其他函數的異步調用請求造成影響，因此函數計算團隊建議為 A-Function 開啟獨享隊列功能，同時設置彈性實例上限，這樣將 A-Function 的異步調用請求進行隔離，避免對其他函數的影響。

總結

升級后的函數計算異步調用監控指標體系能夠幫助用戶解決積壓問題定位難以及積壓量化等問題，結合云監控報警的設置，極大提高了函數計算異步調用應用的穩定性。

同時，為了盡量避免請求積壓情況的發生，我們目前正在對函數計算異步處理系統層面進行優化，包括隊列回收機制、獨享隊列能力以及積壓消息重定向策略等，從而提高函數計算系統處理異步調用請求的能力。這樣，通過強大的異步調用請求處理系統以及全面的監控指標體系，為函數計算異步調用保駕護航。

福利大放送

開發者如何自我提升？如何拓展自身技能，了解最優學習路徑迅速入門？阿里云 Serverless 免費開放超全開發者學習資料，將最前沿的技術知識沉淀送給各位。內含：技術電子書、技術大會資料合集、知識圖譜、18 節入門視頻課等，助力所有開發者共同學習進步！

關注 Serverless 公眾號后臺回復 學習 即可獲得開發者學習資料下載鏈接！

發布云原生技術最新資訊、匯集云原生技術最全內容，定期舉辦云原生活動、直播，阿里產品及用戶最佳實踐發布。與你并肩探索云原生技術點滴，分享你需要的云原生內容。

關注【阿里巴巴云原生】公眾號，獲取更多云原生實時資訊！

總結

以上是生活随笔為你收集整理的异步请求积压可视化｜如何 1 分钟内快速定位函数计算积压问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。