簡介：實例命令行功能的推出希望能消除用戶使用 Serverless 的“最后一公里”，直接將真實的函數運行環境展現給用戶。

背景介紹

全托管的 Serverless 計算平臺能給用戶帶來更少的運維代價、更強的穩定性和更快的彈性能力，在 Serverless 落地的過程中，遇到的一個很大的挑戰是 Serverless 平臺如何給予開發者足夠的安全感。讓開發者們無負擔地使用并信任 Serverless，是我們一直追求的目標。

全托管的初衷是為了減小開發者的使用和運維復雜度，但這一定程度上削減了用戶對自身服務的控制權力。比如在很多場景中，用戶會想知道，如何能夠掌握自己應用的實際運行情況？應用出現問題時如何能快速確認是自身問題還是云平臺問題？如果是云平臺的問題，如何能快速恢復服務，及時止損？這些問題的根本原因，都是用戶對云平臺無法做到完全的信任，這也進一步阻礙了他們遷移應用和擴展業務場景。所以我們也在思考，如何打破這種不信任局面，讓用戶擁有更多資源層面上的掌控力，但又能遠離資源層的復雜運維。

在這樣的背景和需求下，阿里云函數計算創新推出了 Serverless 場景下的函數實例命令行操作功能，支持用戶在控制臺界面登錄進函數實例內部，或者使用工具對實例執行指定的命令。本文具體介紹這個功能的使用方式和使用場景。

實例 Exec 功能定位及使用方式

實例命令行操作功能提供和 K8S Pod Exec 與 Docker Container Exec 一致的使用體驗，支持在函數實例的真實運行環境中執行具體命令。

同時，由于 Serverless 極致彈性、按量收費等特性，在 Serverless 場景下的實例 Exec 功能又與 K8S 和 Docker 有著一些本質的區別：

只能對還存活著的實例（包括預留常駐實例和按量活躍實例）執行 Exec 操作，如果按量實例空閑超時被釋放，則無法再執行；

InstanceExec 請求不占用實例的并發度。因此即使函數的實例并發度設置為 1，也可以同時執行 InvokeFunction 和 InstanceExec 操作

InstanceExec 的一次操作被視作一次 InvokeFunction 請求調用。只要 InstanceExec 請求建立的 websocket 連接沒有和函數實例斷開，那么函數實例將一直處于活躍狀態，和 Invoke Function 采用同樣的計費規則。用戶可以設置 InstantceExec 的 idleTimeout 參數讓客戶端在空閑指定時間后主動斷開連接

實例命令行操作功能支持在控制臺上登錄實例、使用 Serverless Dev 工具執行命令，或者 SDK 調用接口，執行命令。

控制臺登錄實例

在函數計算官網控制臺上在函數詳情-監控指標-實例指標頁面，在最右側可以對實例執行登陸操作。

點擊“登錄實例”，界面將會調到一個終端界面，即可馬上登錄進實例，執行命令進行問題排查。

在函數詳情-監控指標-實例指標頁面，點擊實例 ID 可以進入到函數的實例詳情頁面，界面右上方有登錄實例的按鈕，點擊即可進入實例。

SDK 調用

以 golang SDK 為例，其它 SDK 的調用方式大都類似。

SDK 對 InstanceExec API 進行了封裝，在調用接口的時候需要使用 OnStdout 、OnStderr 傳入兩個回調函數，回調函數定義了處理 Exec 通道返回數據的具體邏輯 ；同時可以使用返回的 execConn 輸入 stdin 消息以傳輸給遠端的 Exec 通道。

適用場景

1. 排查線上問題

在一些日常的場景下，實例命令行操作會帶來更符合用戶習慣、更高效便捷的排查問題方式。

用戶小王是 Serverless 小白用戶，寫完一個程序部署到函數計算后，發現函數中設置的環境變量不生效，如果進一步排查，則需要修改代碼，打印日志，重新部署，查看日志，使用這樣繁瑣的排查方式。現在借助實例命令行操作，小王可以直接一個命令：s exec {instance_id} ENV 便可以一步定位問題。

實例命令行操作提供了便捷的登錄體驗，能幫助用戶解決復雜場景下的應用問題。一些情況下，用戶已經無法通過函數日志、監控指標來具體定位問題，需要借助比如 coredump 、tcpdump、jmap 等工具進行深入排查。

比如，用戶小李發現自己的線上程序最近會出現一些函數錯誤，報錯內容都是連接遠程某服務超時。小李懷疑是函數實例與遠端服務的網絡鏈接不穩定，想進入實例內部，調查分析下實例與遠端服務的網絡情況。他可以按照這樣的步驟進行：

• 登錄進實例內部后，先安裝 tcpdump 工具，需要執行 apt-get update 和 apt-get install tcpdump 兩條命令：

• 安裝完畢后，執行 tcpdump 命令，對遠端服務 IP 的請求進行抓包，并將抓包結果保存在 tcpdump.cap 文件中：

• 抓包完畢，借助 OSS 命令行工具 ossutil64 ，將 tcpdump.cap 文件上傳到自己的 OSS ，然后下載到本地借助分析工具 wireshark 可以進行分析。

2. 程序性能優化

很多時候，開發者需要通過各種 profiling 工具來分析性能、資源使用等問題。比如應用實例CPU、內存等資源使用不符合預期；應用性能低于預期，通過 profiling 工具找到瓶頸等等。通過實例命令行操作，開發者能夠方便的運行語言、框架提供的各種 profiling 工具，優化程序性能和資源使用。

以運行在函數計算上的高德自主出行為例，其峰值 TPS 會達到數十萬級別，作為實時在線應用，服務能接受的請求延遲在幾十毫秒級別。考慮到成本壓力，在上線前他們期望壓測出單實例最高能承受的 TPS 和對應的調用延遲，以此評估需要的實例數量。

但是高德在壓測中發現單實例的平均/長尾延時不符合預期，當單實例 TPS 達到 300 TPS 的時候，請求延遲會直線上升。他們想確定，是否是自己的應用程序哪里存在性能瓶頸，或者是函數計算運行時的性能存在問題？借助實例命令行操作，他們可以登錄進實例內部，通過 profiling 深入分析后發現了性能問題，最后優化了程序性能達到了上線標準。

下面以 custom runtime 為例：demo 示例程序使用 golang 編寫并部署到函數計算上。

• 登錄進入實例后，下載 golang 安裝包 ：

• 并解壓安裝 go :

• 執行 go tool pprof 命令，并產生分析文件：

? ? ? ? ?/root/pprof/pprof.bootstrap.samples.cpu.001.pb.gz

• 最后借助 OSS 命令行工具 ossutil64， 運行 ./ossutil64 cp 命令，將分析文件上傳到自己的 OSS Bukcet 中 ，便可以下載到用戶本地進行可視化分析。

總結

實例命令行功能的推出希望能消除用戶使用 Serverless 的“最后一公里”，直接將真實的函數運行環境展現給用戶，此后 Serverless 將不再是一個“黑盒”，用戶可以更加信任和依賴 Serverless 平臺來擴展更多的業務場景和規模。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的Serverless 场景排查问题利器 : 函数实例命令行操作的全部內容，希望文章能夠幫你解決所遇到的問題。

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