使用 OpenFunction 在任何基础设施上运行 Serverless 工作负载

作者：

霍秉杰：KubeSphere 可观测性、边缘计算和 Serverless 团队负责人，Fluent Operator 和 OpenFunction 项目的创始人，还是多个可观测性开源项目包括 Kube-Events、Notification Manager 等的作者，热爱云原生技术，并贡献过 Keda、Prometheus Operator、Thanos、Loki 和 Falco 等知名开源项目。

王翼飞：青云科技资深软件工程师，负责开发和维护 OpenFunction 项目。专注于 Serverless 领域的研发，对 Knative、Dapr、Keda 等开源项目有深入的了解和实践经验。

来源：2023 上海 KubeCon 分享，公众号后台回复关键词 KubeCon-2023 即可获取 PPT 下载链接。

前言

本文主要包括以下几个部分：

构建开源 FaaS 平台的必要性与可⾏性
OpenFunction 简介
冷启动优化：Dapr proxy 模式及 Wasm ⽀持
OpenFunction 在⾃动驾驶领域的应⽤
社区、路线图与 Demo

构建开源 FaaS 平台的必要性

什么是 Serverless？加州大学伯克利分校在论文《A Berkeley View on Serverless Computing》给出了明确定义：Serverless computing = FaaS + BaaS。

对于函数计算平台，函数是不可或缺的，即 FaaS 是主体。同时，FaaS 也需要和后端的 BaaS 服务产生联系，所以丰富的后端服务是函数的重要依托。

云厂商通常提供托管的函数计算（FaaS）和各类后端中间件服务，这样就会把开发者锁定在自己的云平台之上。

现阶段我们也看到，有一些公司因为云上的成本过高，想要下云或者从一个云迁移到另一个云也就是跨云迁移。如果其函数绑定在云的 BaaS 服务上，则不利于跨云的迁移。所以，跨云迁移之后如何去处理各个云厂商 BaaS 服务接口的差异，成了目前较大的挑战。

从另一个角度看，一个 FaaS 平台通常需要支持多种语言，也会利用到众多后端服务。举例来讲，5 种语言需要和 10 种后端服务对接，那么这样做就会有 5×10 即 50 种实现，还是比较复杂的。

构建开源 FaaS 平台的可行性

如何解决上述问题呢？我们可以引入 Dapr 来简化函数与众多后端服务的交互。

Dapr 是一个分布式应用的运行时，能够把分布式应用的能力抽象成一个个 Building Block。

举几个例子来讲，一般的分布式应用程序都有 service 之间的相互调用，所以会有一个 service 的 Building Block；通常也会有 publish、subscribe 这样的模式，所以也会有一个 publish and subscribe 的 Building Block；此外还会有一些输入输出，所以有一个 Binding Building Block；当然还有其他的，可参考上图。

这些 Building Block 会由一系列的 components 支撑，比如 PubSub Brokers 可以支持各种云上的 MQ、AWS sqs 或者一些开源的中间件如 Redis、Kafka；Bindings 也会支持一些云上的存储和开源组件如 Kafka、MySQL、Redis。

所以 Dapr 就能解决上文提到的问题。FaaS 平台的每一种语言，只需要和 Dapr 交互，Dapr 的 API 再和构成每一个 Building Block 的 component 交互，通过 Dapr 去处理与众多后端服务的交互，这样就把复杂度从 N × M 降为了 N × 1.

另外 Dapr 解耦了 FaaS 平台与各云厂商的 BaaS，做到了云厂商中立，解决了跨云迁移的问题。

OpenFunction 简介

OpenFunction 是什么

OpenFunction 是青云科技在 2022 年初开源的，在 2022 年 4 月成为了 CNCF 的 Sandbox 项目。

云厂商中立
- 与各个云厂商的 BaaS 服务松耦合
- 通过 Dapr，简化了与各云厂商或开源 BaaS 服务的集成
同时支持同步与异步函数
- 同步函数基于 Kubernetes Gateway API 实现了 OpenFunction Gateway 作为函数⼊⼝
- 异步函数可直接从事件源消费事件，并可根据事件源特有的指标自动伸缩
支持直接从函数代码生成符合 OCI 标准的函数镜像
- 基于 Cloud Native Buildpacks 实现
支持 0 与 N 之间的水平自动伸缩
既能运行函数，也能运行 Serverless 应用
支持 Wasm Runtime
更完善的 CI/CD

上图是 OpenFunction 的架构图，总体分为：Build，Function，Serving 和 Events 几个部分。

Function：Function 是一个主控模块，控制函数的构建和 serving，Build、Serving 和 Status 等信息也会在 Function 的 CRD 中显示。
Build：支持使用 Buildpacks 的方式构建函数的镜像，也支持使用 Dockerfile 的方式构建 Serverless 应用；后端技术是 Shipwright，Shipwright 可以切换构建镜像的引擎，所以可以通过 Shipwright 选择不同的镜像构建工具，最终将应用构建为容器镜像。
Serving : 通过 Serving CRD 将应用部署到不同的运行时中，可以选择同步运行时或异步运行时。同步运行时可以通过 Knative Serving 或者 Keda-HTTP 来支持，异步运行时通过 Dapr+Keda 来支持。同时现在也支持 WasmEdgeRuntime 来支持 Wasm 函数。
Events : 对于事件驱动型函数来说，需要提供事件管理的能力。由于 Knative 事件管理过于复杂，所以我们研发了一个新型事件管理驱动叫 OpenFunction Events。

OpenFunction Events

EventBus 利用 Dapr 的能力解耦了 EventBus 与底层具体 Message Broker 的绑定，你可以对接各种各样的 MQ。

OpenFunction Gateway

OpenFunction Gateway 是 OpenFunction 0.7.0 增加的新特性，是基于 Kubernetes Gateway API 来实现的。之所以选择 Kubernetes Gateway API，是因为其 CRD 和其下游实现是解耦的，用户可以选择自己喜欢的 Gateway 实现，比如 APISIX、Istio、Contour 等；另外 Kubernetes Gateway API 也提供了一些新的特性，比如 HTTP 流量的分发、跨 Namespace routing 功能。

在之前 OpenFunction 需要把流量转发到 Knative 的 Gateway，然后再路由到 Knative 的 Revision，链路比较长。有了 OpenFunction Gateway，可以直接把流量转发到 Knative 的 Revision。也就是说可以不再依赖 Knative 网络相关的组件，整个流量转发的链路也会变短。

为什么引入 OpenFunction Gateway

通过 Knative Gateway 访问同步函数需指定⼀个由随机串组成的 service url，不可预测且对⽤户不友好。

通过 OpenFunction Gateway 访问同步函数，可通过函数名及 namespace ⽣成函数访问 url。另外还可以通过 Gateway 的 Service 加上 Function 的 namespace 和 name 来进行 path-based 的访问，也可以基于 OpenFunction Gateway 的 IP 加上 Host 相关的 Headers 来进行 host-based 访问。

如果我们想在集群外部访问集群内部的 Function，我们可以在 OpenFunction Gateway 上面配置 domain 相关的字段，配置成 magic DNS，这样我们就可以直接在集群外部通过域名来访问集群内部的 Function。

冷启动优化

冷启动优化一直是 FaaS 平台的难点。

之前我们采用的是 Dapr sidecar 模式，但是会影响 Function 启动的时间。函数很小的情况下，Dapr sidecar 的 container 启动时间以及 Dapr plant 初始化所需要的时间，比 Function 启动时间更长。

我们设计了 Dapr Proxy 模式，就是让所有 Function 的 pod 共享一个 Dapr sidecar。如果我们将 Function 扩容到很大的值，副本数较多，那么 sidecar 也会造成大量的资源开销，采用这个模式将有效避免这种情况。

接下来我们还有一个基于 Pool 的冷启动优化的计划。上文中提到的 Proxy 模式，对 Function 启动时间的优化是有限的。所以我们考虑采用 Pool 的方式来优化冷启动。

引入一个预创建的 Pod Pool，在有调用请求时，可以根据请求的相关信息判断要调用哪个 Function，然后对这个 Function 的 code 热加载，将其变成针对某个 Function 的 Pod，后续的流量就可以直接进入到这个特定的 Function Pod，这个过程不需要 K8s Pod 调度创建等逻辑的参与，所以这个方式对冷启动的时间优化是非常显著的。

⽀持 WasmEdge 作为 Wasm 运⾏时

在 OpenFunction 1.0.0 中，我们支持 WasmEdge 作为 Wasm 运行时。WebAssembly 作为 FaaS 平台运行时，具有很多优势，比如启动时间短、镜像体积小、安全性比较高。另外 WasmEdge 对 HTTP 支持也比较好。

但是目前 Wasm Function 访问后端服务有一个问题，因为 WebAssembly 程序访问 API 是受限的，所以也需要通过 Dapr 提供相对统一的方式来完成对后端服务的访问。

目前 Dapr、Rust、SDK 以及 Dapr WasmEdge 等相关的项目，还不够成熟，所以我们暂时还没有集成。后续相关生态成熟之后，再进行集成。

OpenFunction 在⾃动驾驶领域的应⽤

下面介绍一个将 OpenFunction 用在自动驾驶领域的案例，来自 OpenFunction 的社区用户------驭势科技。

简单来讲，自动驾驶就是车端会上传很多传感器的数据到云端，云端再对这些数据进行处理。

上图是云端的架构图。举例来说，车端的 MQTT Broker 将云端的数据传到云端的 MQ 上，运维人员会创建多种异步函数和同步函数来处理这些数据。MQTT topic 的数据会由一个函数处理，其他数据由另外一个函数处理，处理完的数据分别存到了不同的后端服务里，因为业务比较多，所以可能是不同的团队去去实现的，那么就需要用不同的语言去实现。

异步：消息队列实时数据 → Prometheus 指标

驭势科技还有一个比较高阶的使用例子。

车端上传 MQTT 的数据，通过异步函数从 MQTT 的数据提取出 Metrics，再将其发送到 Prometheus 的 Pushgateway，这种方式相当于将车端的数据变成了 Metrics 再存储下来。

为什么⾃动驾驶需要云⼚商中⽴的 Serverless 平台？

对于云商中立的需求
- 不同的客户要求部署到不同的云厂商
- 一些客户的车端数据比较敏感，要求放到和公有云隔离的环境
- 不同的云⼚商有不同的后端服务，如果没有⼀个云⼚商中⽴的云平台，对于同⼀处理逻辑则需要为对接的每⼀个云⼚商都实现相似的服务
对于 Serverless 的需求
- 数据处理逻辑多样同时经常变化，来⾃同⼀数据源的数据在不同场景下的处理逻辑不尽相同
- ⾃动驾驶涉及的模块较多，不同的模块由不同的团队负责，需要多语⾔⽀持
- ⼤量⻋端数据需要实时处理；⾃动驾驶⻋辆也有潮汐的特性，数据处理需求有⾼峰和低⾕

社区、路线图与 Demo

OpenFunction 路线图

函数框架
- ⽀持 Dapr State Management 与 Dapr Workflow
- ⽀持更多语⾔的异步函数框架包括 Python、Rust
- ⽀持将 Java 函数编译成 Native 程序运⾏在 Quarkus 环境中
函数运行时
- 实现 Serverless ⼯作流（Workflow）
- 预研基于 Pod Pool 的冷启动优化⽅案
- ⽀持 OpenTelemetry 作为另⼀个函数追踪⽅案
用户工具
- 增加 OpenFunction 控制台
与 AIGC 结合

早起贡献及应用者

越来越多的社区贡献者
- 主要 Maintainer 来⾃ KubeSphere 团队
- SkyWalking PMC 成员 @arugal 实现了 SkyWalking 和 OpenFunction Go Functions Framework 的集成
- 驭势科技 (UISEE) @webup @kehuili 以及印度的贡献者正在参与 Node.js 和 Python Functions Framework 的开发
- SAP @lizzze 参与 functions-framework-go 的开发
- 来⾃阿⾥云、微众银⾏等社区贡献者也在积极参与
- 乌克兰的贡献者在帮忙维护 openfunction.dev
越来越多的公司开始采用
- 国内某电信公司采用 OpenFunction 构建云函数计算平台
- 驭势科技（UISEE）采用 OpenFunction 处理车云数据
- 微众银行
- 某证券公司
- 喜马拉雅
- 云学堂

参与 OpenFunction 社区

欢迎各位小伙伴参与社区！

附录：函数示例

同步函数触发异步函数示例

同步函数：github.com/OpenFunctio...
异步函数：github.com/OpenFunctio...