背景介紹
全托管的 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 連接配接沒有和函數執行個體斷開，那麼函數執行個體将一直處于活躍狀态，和 InvokeFunction 采用同樣的計費規則。使用者可以設定 InstantceExec 的 idleTimeout 參數讓用戶端在空閑指定時間後主動斷開連接配接。
執行個體指令行操作功能支援在控制台上登入執行個體、使用 Serverless Devs 工具執行指令，或者 SDK 調用接口，執行指令。
控制台登入執行個體
在函數計算官網控制台上在函數詳情-監控名額-執行個體名額頁面，在最右側可以對執行個體執行登陸操作。
點選“登入執行個體”，界面将會調到一個終端界面，即可馬上登入進執行個體，執行指令進行問題排查。
在函數詳情-監控名額-執行個體名額頁面，點選執行個體 ID 可以進入到函數的執行個體詳情頁面，界面右上方有登入執行個體的按鈕，點選即可進入執行個體。
SDK 調用
以 golang SDK 為例，其它 SDK 的調用方式大都類似。
SDK 對 InstanceExec API 進行了封裝，在調用接口的時候需要使用建 OnStdout、OnStderr 傳入兩個回調函數，回調函數定義了處理 Exec 通道傳回資料的具體邏輯 ；同時可以使用傳回的 execConn 輸入 stdin 消息以傳輸給遠端的 Exec 通道。
command := []string{"/bin/bash"}
execConn, err := client.InstanceExec(
fc.NewInstanceExecInput(
serviceName, functionName, instanceID, command,
).WithStdin(true)
.WithStdout(true)
.WithStderr(true)
.WithTTY(true)
.WithIdleTimeout(120)
.OnStdout(
func(data []byte) { fmt.Printf("STDOUT: %s\n", data) },
).OnStderr(
func(data []byte) { fmt.Printf("STDERR: %s\n", data) },
))
if err != nil {
fmt.Printf("%v", err)
}
if err := execConn.WriteStdin([]byte("ls\r")); err != nil {
fmt.Println("Write Stdin error", err)
} 适用場景
排查線上問題
在一些日常的場景下，執行個體指令行操作會帶來更符合使用者習慣、更高效便捷的排查問題方式。
使用者小王是 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 可以進行分析。
程式性能優化
很多時候，開發者需要通過各種 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、分布式系統穩定性等領域。
原文連結：https://developer.aliyun.com/article/858354?utm_content=g_1000319676
本文為阿裡雲原創内容，未經允許不得轉載。