导语 |云函数 Serverless Cloud Function（下文简称SCF）是腾讯云为企业和开发者们提供的无服务器执行环境，帮助大家在无需购买和管理服务器的情况下运行代码。但是 SCF 在使用过程中经常会受到开发语言方面的限制，造成拓展性和成本上的问题。本文就将为大家介绍使用 Custom Runtime 来解锁 SCF 语言限制，希望与大家一同交流。文章作者：臧琳，腾讯云Serverless研发工程师。

一、背景

SCF 作为腾讯云 FaaS 核心产品，支持 javascript、python、php、java、go等多语言函数。但是，在用户实际使用过程中，我们发现了一些问题：

1. 寻求更多语言支持

我们时常会收到来自内外的各种关于编程语言的咨询，比如 SCF 是否支持 dotnet、rust、deno 甚至 C 等多种语言环境。

2. 关于现有语言的功能拓展

比如 php 想要安装更多的插件，就需要在执行环境中使用 phpize 来安装（因为部分插件可能和 os library 等底层库相关），但是云函数因为安全等原因，限制了相关权限。

3. 关于Runtime的拓展性

举个例子，现有 SCF java 的语言环境是 java8，如果用户想要在 SCF 中使用 JDK11 或者更新的 JDK15，有没有办法解决呢？

4. 使用成本

目前，用户如果想要在自己的业务代码中嵌入 SCF，需要了解 SCF 各个语言提供的入口函数及编程方法。虽然我们已经尽量将使用方法和接口设计得简单，但对于一些用户来说，仍然要处理编程语言上的接口依赖，以及学习如何正确使用这些接口 API。

5. 维护成本

简单来说，如果复用现有方案，给 SCF 提供多语言支持其实是可行的，但是需要给每一种语言编写一套使用 SCF 的 API。这不仅仅需要 SCF 研发同学懂得各种语言，还需要他们了解各个语言的安全特性，使用特性等，维护成本很高。

那么，有没有一种方法能够让我们只需要维护一套统一的 API，就能让用户从各种编程语言中解耦，还能解决上述列举的各项问题呢？答案就在于使用——Custom Runtime 。

二、Custom Runtime简介

Custom Runtime（以下简称CR）使用方法较为简单：CR 会暴露一套 HTTP API 提供给用户环境，而用户只需要到特定端口上发送/接收 HTTP 请求，即可以获得 SCF 下发的各种 event，并返回处理结果。具体的文档可以参考：Custom Runtime 说明 [1] 。

总体来说，要使用 Custom Runtime，用户需要做好以下准备：

1. bootstrap 可执行程序

此执行程序可以是任何形式的 Linux 可执行文件，比如 C 语言编译出的二进制文件，或者是一个简单的 shell 脚本。

2. 用户的事件处理函数

也就是通过 CR 约定的 HTTP API 实现 event 的获得和处理，以及结果返回。

3. 用户语言 Runtime（可选）

针对解释型语言，或者是需要 Runtime 来运行的语言，比如 js、python、dotnet 等，需要用户提供自己的 Runtime，并在 bootstrap 中提供相应的启动 Runtime 的命令。

腾讯云官网上也提供了利用 CR 实现 shell 云函数的示例[2]，有兴趣的小伙伴可以看看。

三、Custom Runtime 具体模型及用法示例

Custom Runtime 函数的内部处理流程如下所示：

目前 Custom Runtime 的实现在 SCF 侧是一个 HTTP Server 。用户侧代码作为 HTTP Client 通过约定的 API 给 SCF 发请求来获得事件及相关信息，并发送 HTTP 请求返回处理结果给 SCF 服务。

HTTP Server 端口号和 URL，通过两个环境变量传递到云函数环境中:

SCF_RUNTIME_API:SCF_RUNTIME_API_PORT

HTTP API 定义如下图所示：

1. 冷启动阶段（函数部署阶段）

冷启动阶段主要是部署用户代码，完成用户初始化，这个阶段 SCF 会在用户提供的程序包（zip包）中寻找 bootstrap 可执行程序，然后拉起该程序。bootstrap 由用户实现，内部启动用户代码等工作。

用户函数在冷启动阶段需要完成代码初始化工作，并通知 SCF，初始化工作完成。即发 POST 到 SCF_RUNTIME_API:SCF_RUNTIME_API_PORT/runtime/init/ready.

SCF 服务侧接收用户 ready 的请求，初始化工作结束，通知上层服务。函数进入调用流程（即 event 此时可以下发到函数侧）。

2. 热启动阶段（调用阶段）

函数通过GET SCF_RUNTIME_API:SCF_RUNTIME_API_PORT/runtime/invocation/next 获得 event 及相关 ctx 信息。

SCF 在函数拉取 event 之后，等待用户函数返回。

函数处理 event 之后，如正常返回，通过 POST SCF_RUNTIME_API:SCF_RUNTIME_API_PORT/runtime/invocation/response 传递返回信息给 SCF 服务。

如函数调用出现异常（此处指业务代码需要返回错误信息），则通过 POST SCF_RUNTIME_API:SCF_RUNTIME_API_PORT/runtime/invocation/error 返回错误信息。

SCF 服务传递返回给上层服务，函数一次调用结束，进入下一次 event 调用周期。

这里我们用 SCF 中 CustomRuntime 的 Deno 模板示例做说明，如下图所示，程序包里有：

bootstrap: 入口文件，这里是shell，可以看到红线标注这一行就是启动deno程序；
deno 二进制：Deno Runtime，启动 deno 程序必须的 launcher ；
demo.ts：用户函数，里面就实现了上面提到的和 SCF 服务端交互的逻辑，也是用户业务逻辑的主要处理函数。

bootstrap 主要是启动 demo.ts，下面我们看看 demo.ts 里的代码实现：

可以看到，主要是完成初始化阶段。下面再来看看调用是怎么完成的：

可以看到，是通过 GET （fetch）循环拉取 event，然后调用 processEvent() 来进行处理。processEvent() 逻辑如下所示：

分别处理正常返回和错误返回。最后再来看一下我们是怎么封装这里的 postData() 函数的：

以上就是一个 Deno 函数使用 SCF 的 Custom Runtime 实现云函数的全过程。

四、结语

从上文的论述我们不难看出：

1. SCF与语言无关

因为 CR 的使用与语言无关，所以解锁了 SCF 的语言限制,也就是说只要可以实现一个 HTTP Client，就可以通过 HTTP API 的调用和 SCF 进行交互，从而完成云函数的事件处理及调用。

2. bootstrap 是入口

举个例子，如果我用 C 语言实现一个 HTTP Client，按照 CR 的约定完成与 SCF 的交互，那么完全可以编译成一个名字叫 bootstrap 的二进制文件，然后就可以跑 C 的FaaS 函数了。

3. bootstrap可配置

用户可以在 bootstrap 里面启动多个进程，可以解锁多种玩法，当然，要符合安全，毕竟用户函数运行环境有安全限制。但是，这已经可以解决一些“云函数+agent进程”的需求。

4. 使用简单

相对于学习各个语言的函数编写规范，了解云函数对各个语言的支持。使用 CR 只需要学习 HTTP API 的使用即可。更多的语言，环境相关的问题都是用户在业务开发中使用到的，不需要额外学习。

Custom Runtime 刚刚上线，已经得到了一些外网客户的关注。比如，有人用 Custom Runtime 把 Swift 放到了 SCF 里面，并做了相应的支持 [3] ；有人用 Custom Runtime 在 SCF 中跑了 WASM, 并在上面做了 Rust 语言的支持 [4] 。

还有很多类似场景，我们也在不断的努力，引入更多的语言，借助语言的生态，带动Serverless的生态发展。最后，欢迎大家体验 SCF Custom Runtime，留下宝贵的意见！

参考资料：

[1] Custom Runtime 说明 :

https://cloud.tencent.com/document/product/583/47274

[2] 官网示例 :

https://cloud.tencent.com/document/product/583/47610

[3] 场景拓展1：

https://github.com/stevapple/swift-tencent-scf-runtime