Serverless 可觀測性的過去、現在與未來

作者 | 孔德慧（夏莞）

背景

1. Serverless 將成爲下一個十年雲的默認編程範式

隨着 Serverless 概念的進一步普及，開發者逐漸從觀望狀態進入嘗試階段，越來越多的企業用戶開始將業務遷移到 Serverless 平臺。在阿里集團內部，淘寶、飛豬、閒魚、高德、語雀等核心功能穩步落地，在阿里集團外部，新浪微博、世紀聯華、石墨文檔、TPLink、藍墨雲班課等各行各業的企業也紛紛解鎖 Serverless 使用的不同場景。Serverless 正在成爲成爲下一個十年雲的默認編程範式。

更多案例請參考函數計算用戶案例。

Serverless 降本增效免運維的特性爲開發者帶來了實打實的好處：基於函數計算的 Serverless 方案爲藍墨節省了 60% 左右的 IT 成本，爲石墨文檔節約了 58% 的服務器成本；提升碼隆科技的開發效率，實現兩週內功能上線；平穩支撐負載的波峯波谷相差 5 倍以上的新浪微博，每天輕鬆處理數十億請求。

廣告時間：歡迎加入雲原生 Serverless 團隊（函數計算，Serverless 工作流，Serverless 應用引擎），以公共雲、集團、開源社區三位一體的方式打造業界領先的 Serverless 產品體系。職位需求見 JD，招聘長期有效，有興趣的同學可以發送簡歷至 dehui.kdh@alibaba-inc.com。

2. 可觀測性成爲 Serverless 發展的絆腳石？

隨着 Serverless 的深入使用，開發者逐漸發現 Serverless 架構下的問題定位比傳統應用更加困難，主要原因如下：

函數計算是阿里雲的 Serverless 產品，在過去的一年，函數計算團隊爲了更好地回答以上問題做了很多努力。

本文主要介紹函數計算在可觀測性上的嘗試與函數計算可觀測性現狀。

Serverless 下可觀測性

可觀測性是通過外部表現判斷系統內部狀態的衡量方式。 

-- 維基百科

在應用開發中，可觀測性幫助我們判斷系統內部的健康狀況。在系統平穩運行時，幫助我們評估風險，預測可能出現的問題。當系統出現問題時，幫助我們快速定位問題，及時止損。

一個好的可觀測性系統要幫助用戶儘可能快地發現問題、定位問題並且端到端地解決問題。

在 Serverless 這種免運維的平臺體系中，可觀測性是開發者的眼睛，沒有可觀測，何談高可用？

1. 可觀測性 1.0

圖 1 - 可觀測性基礎

可觀測性主要包含三個部分：日誌、指標、鏈路追蹤。

和幾乎所有 FaaS 產品一樣，函數計算（FC）在商業化之初就支持了函數日誌和指標的查看。

用戶在 FC 配置 SLS 的 Project 和 Logstore，FC 將函數打到 stdout 的日誌轉存到用戶的 Logstore 中。用戶可以通過 SLS 控制檯查看函數日誌，並藉助 SLS 的能力對日誌進行分析和聚合。

FC 將指標日誌推送到雲監控，通過雲監控提供函數調用數 / 錯誤數 / 函數延時 / 函數內存等基本指標。

函數日誌和基本指標是應用的聽診器，雖然樸素簡陋，卻也能幫助用戶發現問題，定位問題。

即使出現開發者無法排查的問題，在用戶量不那麼大的年代，開發同學可以爲用戶提供貼身服務，結合後臺日誌幫用戶定位問題。

函數日誌和指標使用詳細信息請參考配置並查看函數日誌 / 監控指標。

2. 可觀測性 2.0 - 雲原生的可觀測

隨着 Serverless 的發展，越來越多的場景在 Serverless 落地，使用規模越來越大，產品架構越來越複雜，應用聽診器的可觀測性 1.0 已經不能滿足各行各業開發者的監控訴求。這種近乎黑盒的執行環境給開發者帶來了強烈的距離感與不信任感。開發者需要掌控自己的應用，想要知道每一個請求在函數計算經歷了怎樣的歷程，想要看看端到端的延時長是不是因爲冷啓動，想要查看函數實例的執行環境，想要在請求出現異常時第一時間定位問題，想要複用熟悉的開源觀測平臺。

在面對這些需求時，團隊內部也經過了長時間的激烈討論，一部分同學認爲我們應該支持這些需求，另一部分同學則認爲這些需求某種程度上與 Serverless 本質相違背，Serverless 就是要屏蔽底層的計算資源，用戶不需要關心底層計算資源的情況。另一方面我們暴露了這些指標有什麼用呢，用戶就算看到了有冷啓動，看到了系統時間消耗，看到了底層實例的 CPU，用戶又不能有任何實質操作，這些指標真的意義嗎？這兩種觀點爭論不休，而我，是堅定的反對者。

後來團隊搬到了 EFC，每天都要等待着那不知什麼時候會來的電梯（輸入你要去的樓層，去對應的電梯安靜地等待，看不到電梯目前所在樓層），電梯告訴我們，你就在這裏等哦，我肯定會來的，但是我現在到了哪層，我什麼時候下來你大可不必知道，你知道了也沒用，我的這個調度肯定是最優的，你要相信專業電梯的調度算法。可是，我怎麼能相信你呢？

於開發者而言，函數計算也是那不知什麼時候會來的電梯吧，我們和開發者說您的請求我們一定會穩定執行的，您的執行環境一定很健康，請求過多我們會自動擴容的，但是當前實例的監控指標，我什麼時候擴容您大可不必知道，我們的調度肯定是最優的，您要相信專業研發團隊的調度算法。同樣的，開發者又怎麼相信我們呢？

Serverless 的可觀測性不單單要幫助開發者排查問題，也要逐步揭開 Serverless 那層神祕的面紗，贏取開發者對 Serverless 的信任。

於是有了函數計算可觀測性 2.0，我們希望可觀測性 2.0 可以成爲應用的心電圖。

圖 2 - 函數計算可觀測性現狀

圖 3 - 函數計算兼容開源可觀測能力

相比於自己發明創造 FaaS 可觀測性新體驗，函數計算兼容開源可觀測能力，集成 Jaeger，支持 Grafana 大盤，也支持以非常小的改動接入 New Relic 等優秀三方監控平臺。函數計算是首家兼容開源、擁抱容器生態和雲原生開發者的 FaaS 提供商，可觀測體驗的平滑遷移支撐應用在容器和 Serverless 平臺的平滑遷移。

1）集成 OpenTracing，支持鏈路追蹤

FC 與鏈路追蹤服務集成，爲開發者提供了完整的調用鏈路還原、調用量統計、鏈路拓撲分析、冷啓動定位等工具。幫助開發者快速分析和診斷分佈式架構下的性能瓶頸。

FC 鏈路追蹤具有以下特點：

圖 4 - 鏈路追蹤鏈路示例

圖 5 - 鏈路追蹤綜合能力詳情

2）集成 ARMS，內置 APM 能力

FC 無縫對接 ARMS 應用監控，開發者只需爲函數新增一個環境變量即可開啓 APM 應用監控功能，ARMS 探針以對代碼無入侵的方式監測應用性能，提供應用級別的可觀測性，包括函數實例的 CPU、內存指標、Java 虛擬機指標、代碼 Profiling 信息、SQL 查詢等函數實例的指標。

圖 6 - ARMS 示例

3）發佈監控中心 (Insights)，問題發現調查一站式解決

FC 支持請求級別指標，通過爲用戶每個請求多打一條指標日誌的方式爲請求裝上攝像頭。通過請求級別指標，用戶可以清楚地看到請求的執行時間、使用內存，是否異常、錯誤類型、冷啓動情況，traceID 等信息。也可以基於請求級別指標串聯起所有的可觀測性能力。

監控中心則是 FC 可觀測性能力的集大成者，監控中心集成了 Metrics、Logs、Tracing 的能力，可以在一個站點完成預覽指標、查看日誌、分析鏈路的能力，爭取做到問題發現調查一站式解決。

監控中心具有如下特點：

圖 7 - 監控中心示例

4）擴展編程模型，集成三方監控

函數實例的生命週期完全由平臺控制，用戶無法控制實例的啓動與回收，也不感知實例的暫停與重啓，這就使得在函數計算上執行除主線程外的背景線程格外困難。監控探針就是諸多重要的背景線程的一種。

FC 擴展了編程模型，發佈 RuntimeLifeCycle 功能，Runtime LifeCycle 會監聽函數實例生命週期事件，允許函數實例在暫停和回收前回調用戶的函數邏輯。這一功能的發佈使 FC 集成三方 APM 監控成爲可能。用戶只需要在實例暫停前將採集的指標發出去、在實例回收前將內存中的數據清理掉就可以在 APM 平臺上實時地查看監控指標了。

圖 8 - Tingyun APM 示例

圖 9 - NewRelic APM 示例

3. 總結

函數計算可觀測性經歷了 1.0-> 2.0 的發展，從閉門造車的可觀測發展成開源的可觀測，從平臺的可觀測發展爲開發者的可觀測，從 FaaS Only 的可觀測演進成了雲原生的可觀測。

作爲首家兼容開源可觀測、擁抱容器生態和雲原生開發者的 FaaS 提供商，函數計算也將更有實力實現開發者業務的平滑遷移。

未來規劃

FC 可觀測性相比於一年前前進了一小步，從黑盒的可觀測演進成了微弱燭光的可觀測，但距離 “Serverless 應用白盒化” 的目標還有着很長的路要走。我們希望能夠兼容開發者的監控體驗，支撐着用戶平滑地放心地將業務遷到 Serverless 上來。

接下來我們會繼續投入做以下事情：

希望函數計算的可觀測性成爲一盞燈，照亮每一個 Serverless 應用。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/i75HuedWko_H0DqOobaYzg

猜你喜歡