作者 | 孔德慧（夏莞）
來源 |
阿裡巴巴雲原生公衆号背景
1. Serverless 将成為下一個十年雲的預設程式設計範式
随着 Serverless 概念的進一步普及，開發者逐漸從觀望狀态進入嘗試階段，越來越多的企業使用者開始将業務遷移到 Serverless 平台。在阿裡集團内部，淘寶、飛豬、閑魚、高德、語雀等核心功能穩步落地，在阿裡集團外部，新浪微網誌、世紀聯華、石墨文檔、TPLink、藍墨雲班課等各行各業的企業也紛紛解鎖 Serverless 使用的不同場景。Serverless 正在成為成為下一個十年雲的預設程式設計範式。
更多案例請參考
函數計算使用者案例。
Serverless 降本增效免運維的特性為開發者帶來了實打實的好處：基于函數計算的 Serverless 方案為藍墨節省了 60% 左右的 IT 成本，為石墨文檔節約了 58% 的伺服器成本；提升碼隆科技的開發效率，實作兩周内功能上線；平穩支撐負載的波峰波谷相差 5 倍以上的新浪微網誌，每天輕松處理數十億請求。
2. 可觀測性成為 Serverless 發展的絆腳石？
随着 Serverless 的深入使用，開發者逐漸發現 Serverless 架構下的問題定位比傳統應用更加困難，主要原因如下：
- 元件分布化：Serverless 架構的應用往往粘合多個雲服務，請求需要流經多款雲産品，一旦端到端延時變長或表現不符合預期，問題定位十分複雜，需要依次去各個産品側逐漸排查。
- 排程黑盒化：Serverless 平台承擔着請求排程、資源配置設定的責任，實時彈性擴容會帶來不可避免的冷啟動，Serverless 的資源伸縮是無需開發者參與也不受開發者控制的。冷啟動會影響端對端延時，這次請求有沒有遇到冷啟動，冷啟動的時間都消耗在哪些步驟，有沒有可優化的空間都是開發者急于知道的問題。
- 執行環境黑盒化：開發者習慣于在自己的機器上執行自己的代碼，出了問題登入機器檢視異常現場，檢視執行環境的 CPU/記憶體/IO 情況。面對 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 - 函數計算可觀測性現狀
- 為了回答請求在函數計算的生命曆程，串聯分布式系統的上下遊服務，擁抱開源可觀測能力，我們內建了 OpenTracing，支援鍊路追蹤。
- 為了暴露系統狀态，提供應用級别監控，我們內建了 ARMS(Java)，内置了 APM 能力。
- 為了加快端到端定位問題的速度，我們支援了請求級别名額（FCInsights），釋出了監控中心，問題發現/調查一站式解決。
- 為了相容開發者已有的使用者體驗，我們擁抱開源，內建 OpenTracing，支援 Grafana Dashboard；我們支援三方監控平台，實作代碼幾乎零改造接入APM 監控系統。
- 為了相容傳統開發者的可觀測體驗，支援探針安裝，我們拓展了程式設計模型，支援函數 LifeCycle，為內建三方監控提供可能。
圖 3 - 函數計算相容開源可觀測能力
相比于自己發明創造 FaaS 可觀測性新體驗，函數計算相容開源可觀測能力，內建 Jaeger，支援 Grafana 大盤，也支援以非常小的改動接入 New Relic 等優秀三方監控平台。函數計算是首家相容開源、擁抱容器生态和雲原生開發者的 FaaS 提供商，可觀測體驗的平滑遷移支撐應用在容器和 Serverless 平台的平滑遷移。
1）內建 OpenTracing，支援鍊路追蹤
FC 與鍊路追蹤服務內建，為開發者提供了完整的調用鍊路還原、調用量統計、鍊路拓撲分析、冷啟動定位等工具。幫助開發者快速分析和診斷分布式架構下的性能瓶頸。
FC 鍊路追蹤具有以下特點：
- 擁抱開源：完全相容 OpenTracing 協定，沒有附加學習成本。
- 主動記錄：上報請求在函數計算中消耗的端對端時間。
- 排程透明：暴露代碼準備時間與執行個體啟動時間，是首個暴露冷啟動延時與具體時間消耗的 FaaS 産品。
- 承上啟下：串起上下遊應用，既可以通過 span context 與上遊應用連接配接，又将 span context 傳入函數，連接配接下遊服務。
圖 4 - 鍊路追蹤鍊路示例
圖 5 - 鍊路追蹤綜合能力詳情
2）內建 ARMS，内置 APM 能力
FC 無縫對接 ARMS 應用監控，開發者隻需為函數新增一個環境變量即可開啟 APM 應用監控功能，ARMS 探針以對代碼無入侵的方式監測應用性能，提供應用級别的可觀測性，包括函數執行個體的 CPU、記憶體名額、Java 虛拟機名額、代碼 Profiling 資訊、SQL 查詢等函數執行個體的名額。
圖 6 - ARMS 示例
3）釋出監控中心(Insights)，問題發現調查一站式解決
FC 支援請求級别名額，通過為使用者每個請求多打一條名額日志的方式為請求裝上攝像頭。通過請求級别名額，使用者可以清楚地看到請求的執行時間、使用記憶體，是否異常、錯誤類型、冷啟動情況，traceID 等資訊。也可以基于請求級别名額串聯起所有的可觀測性能力。
監控中心則是 FC 可觀測性能力的集大成者，監控中心內建了 Metrics、Logs、Tracing的能力，可以在一個站點完成預覽名額、檢視日志、分析鍊路的能力，争取做到問題發現調查一站式解決。
監控中心具有如下特點：
- 多元度：支援 Region、Service、Function、Qualifier、Request 多元度的名額，展示各個次元下的調用數和錯誤分布。
- 多層次：內建 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 上來。
接下來我們會繼續投入做以下事情：
- 完善監控中心，支援報警配置，預警異常名額。
- 提供執行個體級别名額，做到代碼問題可定位，環境現場可追溯。
- 內建開源項目，內建 Prometheus，Opentelemetry，配置 Grafana 大盤。
- 豐富名額内容，目前還有一些名額是不好透出的，沒有暴露的，我們要逐漸都暴露出來。
希望函數計算的可觀測性成為一盞燈，照亮每一個 Serverless 應用。
廣告時間：歡迎加入雲原生Serverless 團隊（函數計算，Serverless工作流，Serverless應用引擎），以公共雲、集團、開源社群三位一體的方式打造業界領先的Serverless 産品體系。職位需求見
JD，招聘長期有效，有興趣的同學可以發送履歷至 [email protected]。