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

本文介绍: 构建开源 FaaS 平台的必要性与可⾏性Ope nFu nc t ion 简介冷启动优化：Dap r proxy 模式及 Wasm ⽀持Op e nFu nc t ion 在⾃动驾驶领域的应⽤社区、路线图与 DemoOpenFunc t ion 是青云科技在 2022 年初开源的，在 2022 年 4 月成为了 CNCF 的 Sand box 项目。云厂商中立与各个云厂商的 BaaS 服务松耦合通过 Dap r，简化了与各云厂商或开源 BaaS 服务的集成同时支持同步与异步函数。

作者：

霍秉杰：KubeSp here 可观测性、边缘计算和 Ser v er less 团队负责人，Flue n t Oper a t o r 和 OpenFunc t ion 项目的创始人，还是多个可观测性开源项目包括 Kube-Even ts、No ti fi cat ion Mana g er 等的作者，热爱云原生技术，并贡献过 Keda、Pro m etheus Oper ato r、Tha n os、Lok i 和 Falco 等知名开源项目。

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

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

前言

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

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

构建开源 Fa aS 平台的必要性

什么是 Ser verless？加州大学伯克利分校在论文《A Berk eley Vie w on Ser verless Co mpu ting》给出了明确定义：Ser verless co mpu ting = Fa aS + Ba aS。

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

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

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

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

构建开源 FaaS 平台的可行性

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

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

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

这些 Bui ld ing Bloc k 会由一系列的 components 支撑，比如 PubSub Brokers 可以支持各种云上的 MQ、AWS s qs 或者一些开源的中间件如 Redi s、Kaf ka；Bindings 也会支持一些云上的存储和开源组件如 Kafka、MySQL、Redi s。

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

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

OpenFunc ti on 简介

OpenFunc ti on 是什么

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

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

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

Function：Func tion 是一个主控模块，控制函数的构建和 serving，Build、Serving 和 Status 等信息也会在 Function 的 CRD 中显示。
Build：支持使用 Build pack s 的方式构建函数的镜像，也支持使用 Dockerfile 的方式构建 Serverless 应用；后端技术是 Sh ip w right，Sh ip w right 可以切换构建镜像的引擎，所以可以通过 Shipw right 选择不同的镜像构建工具，最终将应用构建为容器镜像。
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 增加的新特性，是基于 Kubernet es Gateway API 来实现的。之所以选择 Kubernet es 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–base d 的访问，也可以基于 OpenFunction Gateway 的 IP 加上 Host 相关的 Heade rs 来进行 host–base d 访问。

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

冷启动 优化

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

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

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

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

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

⽀持 WasmEdge 作为 Wasm 运⾏时

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

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

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

OpenFunction 在⾃动驾驶 领域的应⽤

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

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

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

异步：消息 队列 实时数据 → Pro m etheus 指标

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

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

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

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

社区、路线图与 Demo

OpenFunction 路线图

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

早起贡献及应用者

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