Serverless 將成爲下一個十年雲的默認編程範式
隨着 Serverless 概念的進一步普及，開發者逐漸從觀望狀態進入嘗試階段，越來越多的企業用戶開始將業務遷移到 Serverless 平臺。在阿里集團內部，淘寶、飛豬、閒魚、高德、語雀等核心功能穩步落地，在阿里集團外部，新浪微博、世紀聯華、石墨文檔、TPLink、藍墨雲班課等各行各業的企業也紛紛解鎖 Serverless 使用的不同場景。Serverless 正在成爲成爲下一個十年雲的默認編程範式。
更多案例請參考 函數計算用戶案例
Serverless 降本增效免運維的特性爲開發者帶來了實打實的好處：基於函數計算的 Serverless 方案爲藍墨節省了 60% 左右的 IT 成本，爲石墨文檔節約了 58% 的服務器成本；提升碼隆科技的開發效率，實現兩週內功能上線；平穩支撐負載的波峯波谷相差 5 倍以上的新浪微博，每天輕鬆處理數十億請求。
可觀測性成爲 Serverless 發展的絆腳石？
隨着 Serverless 的深入使用，開發者逐漸發現 Serverless 架構下的問題定位比傳統應用更加困難，主要原因如下：
- 組件分佈化：Serverless 架構的應用往往粘合多個雲服務，請求需要流經多款雲產品，一旦端到端延時變長或表現不符合預期，問題定位十分複雜，需要依次去各個產品側逐步排查。
- 調度黑盒化：Serverless 平臺承擔着請求調度、資源分配的責任，實時彈性擴容會帶來不可避免的冷啓動，Serverless 的資源伸縮是無需開發者參與也不受開發者控制的。冷啓動會影響端對端延時，這次請求有沒有遇到冷啓動，冷啓動的時間都消耗在哪些步驟，有沒有可優化的空間都是開發者急於知道的問題。
- 執行環境黑盒化：開發者習慣於在自己的機器上執行自己的代碼，出了問題登錄機器查看異常現場，查看執行環境的 CPU/內存/IO 情況。面對 Serverless 應用，機器不是自己的，登也登不上，看也看不了，開發者眼前一片漆黑。
- 產品非標化：在 Serverless 場景下，開發者無法控制執行環境，無法安裝探針，無法使用開源的三方監控平臺，調查問題的方式不得不發生改變，傳統的調查問題經驗無法施展，非常不順手。
函數計算是阿里雲的 Serverless 產品，在過去的一年，函數計算團隊爲了更好地回答以上問題做了很多努力。
本文主要介紹函數計算在可觀測性上的嘗試與函數計算可觀測性現狀。
Serverless 下可觀測性
可觀測性是通過外部表現判斷系統內部狀態的衡量方式。
--維基百科
在應用開發中，可觀測性幫助我們判斷系統內部的健康狀況。在系統平穩運行時，幫助我們評估風險，預測可能出現的問題。當系統出現問題時，幫助我們快速定位問題，及時止損。
一個好的可觀測性系統要幫助用戶儘可能快地發現問題、定位問題並且端到端地解決問題。
在 Serverless 這種免運維的平臺體系中，可觀測性是開發者的眼睛，沒有可觀測，何談高可用？
可觀測性 1.0
圖1：可觀測性基礎
可觀測性主要包含三個部分：日誌、指標、鏈路追蹤。
和幾乎所有 FaaS 產品一樣，函數計算（FC）在商業化之初就支持了函數日誌和指標的查看。
- 函數日誌
用戶在 FC 配置 SLS 的 Project 和 Logstore，FC將函數打到 stdout 的日誌轉存到用戶的 Logstore中。用戶可以通過 SLS 控制檯查看函數日誌，並藉助 SLS 的能力對日誌進行分析和聚合。
- 基本指標
FC 將指標日誌推送到雲監控，通過雲監控提供函數調用數/錯誤數/函數延時/函數內存等基本指標。
函數日誌和基本指標是應用的聽診器，雖然樸素簡陋，卻也能幫助用戶發現問題，定位問題。
即使出現開發者無法排查的問題，在用戶量不那麼大的年代，開發同學可以爲用戶提供貼身服務，結合後臺日誌幫用戶定位問題。
函數日誌和指標使用詳細信息請參考 配置並查看函數日誌，監控指標。
可觀測性 2.0 -- 雲原生的可觀測
隨着 Serverless 的發展，越來越多的場景在 Serverless 落地，使用規模越來越大，產品架構越來越複雜，應用聽診器的可觀測性 1.0 已經不能滿足各行各業開發者的監控訴求。這種近乎黑盒的執行環境給開發者帶來了強烈的距離感與不信任感。
開發者需要掌控自己的應用，想要知道每一個請求在函數計算經歷了怎樣的歷程，想要看看端到端的延時長是不是因爲冷啓動，想要查看函數實例的執行環境，想要在請求出現異常時第一時間定位問題，想要複用熟悉的開源觀測平臺。
在面對這些需求時，團隊內部也經過了長時間的激烈討論，一部分同學認爲我們應該支持這些需求，另一部分同學則認爲這些需求某種程度上與 Serverless 本質相違背，Serverless 就是要屏蔽底層的計算資源，用戶不需要關心底層計算資源的情況。另一方面我們暴露了這些指標有什麼用呢，用戶就算看到了有冷啓動，看到了系統時間消耗，看到了底層實例的 CPU，用戶又不能有任何實質操作，這些指標真的意義嗎？這兩種觀點爭論不休，而我，是堅定的反對者。
後來團隊搬到了 EFC，每天都要等待着那不知什麼時候會來的電梯（輸入你要去的樓層，去對應的電梯安靜地等待，看不到電梯目前所在樓層）。電梯告訴我們，你就在這裏等哦，我肯定會來的，但是我現在到了哪層，我什麼時候下來你大可不必知道，你知道了也沒用，我的這個調度肯定是最優的，你要相信專業電梯的調度算法。可是，我怎麼能相信你呢？
於開發者而言，函數計算也是那不知什麼時候會來的電梯吧，我們和開發者說您的請求我們一定會穩定執行的，您的執行環境一定很健康，請求過多我們會自動擴容的，但是當前實例的監控指標，我什麼時候擴容您大可不必知道，我們的調度肯定是最優的，您要相信專業研發團隊的調度算法。同樣的，開發者又怎麼相信我們呢？
Serverless 的可觀測性不單單要幫助開發者排查問題，也要逐步揭開 Serverless 那層神祕的面紗，贏取開發者對 Serverless 的信任。
於是有了函數計算可觀測性 2.0，我們希望可觀測性 2.0 可以成爲應用的心電圖。
圖2：函數計算可觀測性現狀
- 爲了回答請求在函數計算的生命歷程，串聯分佈式系統的上下游服務，擁抱開源可觀測能力，我們集成了 OpenTracing，支持鏈路追蹤。
- 爲了暴露系統狀態，提供應用級別監控，我們集成了 ARMS(Java)，內置了 APM 能力。
- 爲了加快端到端定位問題的速度，我們支持了請求級別指標（FC Insights），發佈了監控中心，問題發現/調查一站式解決。
- 爲了兼容開發者已有的用戶體驗，我們擁抱開源，集成 OpenTracing，支持 Grafana Dashboard；我們支持三方監控平臺，實現代碼幾乎零改造接入APM 監控系統。
- 爲了兼容傳統開發者的可觀測體驗，支持探針安裝，我們拓展了編程模型，支持函數LifeCycle，爲集成三方監控提供可能。
圖3：函數計算兼容開源可觀測能力
相比於自己發明創造 FaaS 可觀測性新體驗，函數計算兼容開源可觀測能力，集成 Jaeger，支持 Grafana 大盤，也支持以非常小的改動接入 New Relic 等優秀三方監控平臺。函數計算是首家兼容開源、擁抱容器生態和雲原生開發者的 FaaS 提供商，可觀測體驗的平滑遷移支撐應用在容器和 Serverless 平臺的平滑遷移。
集成OpenTracing，支持鏈路追蹤
FC 與鏈路追蹤服務集成，爲開發者提供了完整的調用鏈路還原、調用量統計、鏈路拓撲分析、冷啓動定位等工具。幫助開發者快速分析和診斷分佈式架構下的性能瓶頸。
FC 鏈路追蹤具有以下特點：
• 擁抱開源：完全兼容OpenTracing 協議，沒有附加學習成本；
• 主動記錄：上報請求在函數計算中消耗的端對端時間；
• 調度透明：暴露代碼準備時間與實例啓動時間，是首個暴露冷啓動延時與具體時間消耗的 FaaS 產品；
• 承上啓下：串起上下游應用，既可以通過span context 與上游應用連接，又將 span context 傳入函數，連接下游服務。
圖4：鏈路追蹤鏈路示例
圖5：鏈路追蹤綜合能力詳情
集成 ARMS，內置 APM 能力
FC 無縫對接 ARMS 應用監控，開發者只需爲函數新增一個環境變量即可開啓 APM 應用監控功能，ARMS 探針以對代碼無入侵的方式監測應用性能，提供應用級別的可觀測性，包括函數實例的 CPU、內存指標、Java 虛擬機指標、代碼 Profiling 信息、SQL 查詢等函數實例的指標。
圖6：ARMS 示例
發佈監控中心(Insights)，問題發現調查一站式解決
FC 支持請求級別指標，通過爲用戶每個請求多打一條指標日誌的方式爲請求裝上攝像頭。通過請求級別指標，用戶可以清楚地看到請求的執行時間、使用內存，是否異常、錯誤類型、冷啓動情況，traceID 等信息。也可以基於請求級別指標串聯起所有的可觀測性能力。
監控中心則是 FC 可觀測性能力的集大成者，監控中心集成了 Metrics、Logs、Tracing的能力，可以在一個站點完成預覽指標、查看日誌、分析鏈路的能力，爭取做到問題發現調查一站式解決。
監控中心具有如下特點：
- 多維度：支持 Region、Service、Function、Qualifier、Request 多維度的指標，展示各個維度下的調用數和錯誤分佈；
- 多層次：集成 Metrics、Logs、Tracing 的能力，全方位多層次對應用進行監控；
- 全鏈路：結合指標、日誌、鏈路等信息，層層遞進，抽絲剝繭，真正做到可以在一個站點發現問題，定位問題並解決問題。
圖7：監控中心示例
擴展編程模型，集成三方監控
函數實例的生命週期完全由平臺控制，用戶無法控制實例的啓動與回收，也不感知實例的暫停與重啓，這就使得在函數計算上執行除主線程外的背景線程格外困難。監控探針就是諸多重要的背景線程的一種。
FC 擴展了編程模型，發佈 Runtime LifeCycle 功能，Runtime LifeCycle 會監聽函數實例生命週期事件，允許函數實例在暫停和回收前回調用戶的函數邏輯。這一功能的發佈使 FC 集成三方 APM 監控成爲可能。用戶只需要在實例暫停前將採集的指標發出去、在實例回收前將內存中的數據清理掉就可以在 APM 平臺上實時地查看監控指標了。
圖8：Tingyun APM 示例
圖9：NewRelic APM 示例
總結
函數計算可觀測性經歷了 1.0 -> 2.0 的發展，從閉門造車的可觀測發展成開源的可觀測，從平臺的可觀測發展爲開發者的可觀測，從FaaS Only 的可觀測演進成了雲原生的可觀測。
作爲首家兼容開源可觀測、擁抱容器生態和雲原生開發者的 FaaS 提供商，函數計算也將更有實力實現開發者業務的平滑遷移。
未來規劃
FC 可觀測性相比於一年前前進了一小步，從黑盒的可觀測演進成了微弱燭光的可觀測，但距離 “Serverless 應用白盒化” 的目標還有着很長的路要走。我們希望能夠兼容開發者的監控體驗，支撐着用戶平滑地放心地將業務遷到 Serverless 上來。
接下來我們會繼續投入做以下事情：
- 完善監控中心，支持報警配置，預警異常指標；
- 提供實例級別指標，做到代碼問題可定位，環境現場可追溯；
- 集成開源項目，集成 Prometheus，Opentelemetry，配置 Grafana 大盤；
- 豐富指標內容，目前還有一些指標是不好透出的，沒有暴露的，我們要逐步都暴露出來；
- ... ...
希望函數計算的可觀測性成爲一盞燈，照亮每一個 Serverless 應用。
作者：夏莞
本文爲阿里雲原創內容，未經允許不得轉載。