创新推出 | Serverless 场景排查问题利器：函数实例命令行操作

简介： 实例命令行功能的推出希望能消除用户使用 Serverless 的“最后一公里”，直接将真实的函数运行环境展现给用户，此后 Serverless 将不再是一个“黑盒”，用户可以更加信任和依赖 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 连接没有和函数实例断开，那么函数实例将一直处于活跃状态，和 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 编写并部署到函数计算上：