函数计算平台 OpenFunction 在自动驾驶领域的应用

嘉宾 | 霍秉杰 整理 | 王新

出品 | CSDN 云原生

2022 年 5 月 10 日，在 CSDN 云原生系列在线峰会第 4 期“ApacheSkyWalking 峰会”上，青云科技资深架构师霍秉杰分享了 SkyWalkingv9 如何帮助 OpenFunction 实现函数可观测。

Serverless: 下一波浪潮

随着技术的发展，人们越来越少关注底层技术栈的一些细节，越来越多关注自己应用的商业逻辑。CNCF 发布的 Serverless 白皮书印证了这一点。

如上图所示，从下往上，最底层是 CaaS（Container as a Service），它向下抽象和屏蔽了基础设施的差异，向上提供了一个应用运行的平台，用户对基础设施和应用有相对全面和灵活的掌控。

中间层是 PaaS（Platform as a Service），主要分为两类，一类是传统的 PaaS 平台，例如 Cloud Foundry、Heroku; 另一类则是容器平台，例如 OpenShift、KubeSphere，它们可以提供 Kubernetes 没有的一些能力，比如用户的鉴权、认证与管理，可观测性包括监控、告警、日志、事件与审计，服务网格，还有 CI/CD 等。这使得用户可以更加关注于开发和部署应用，其他可以依赖平台提供的能力。

最上层是 FaaS（Function as a Service），包括云厂商的函数计算服务和开源的函数计算平台。在 FaaS 这层，用户更多关注自己应用的业务逻辑部分，其他的方面都交给平台去处理。

为什么需要一个云厂商中立的 FaaS 平台?

近几年我们越来越多地听到多云、分布式云、混合云这样的提法，其中原因应该是 Kubernetes 带来了云厂商中立的可能性，于是很多公司开始基于 Kubernetes 去做多云、分布式云、混合云的方案或产品。但是在 FaaS 领域却很难实现厂商中立，因为每个云厂商都有自己的 FaaS 平台，通常这些云厂商的 FaaS 平台都会和自己云上的后端服务绑定。CNCF Serverless 白皮书其实也提到了这一点：各个厂商由于编程模型，事件及消息接口，还有后端服务的不同导致用了一个厂商的 FaaS 平台后，就很难迁移到别的厂商的 FaaS 平台。

如何构建一个云厂商中立的 FaaS 平台?

那么有没有可能去构建一个云厂商中立的 FaaS 平台？如何去构建这样一个平台？首先不开源肯定是不太可能做到厂商中立的，不开源就成了另一个厂商。

CNCF 的 Serverless 白皮书在 2018 年发布，里面提到 Serverless 缺乏标准化，成熟度方面也有所欠缺。四年过去了，其实这两个方面都有所改观。首先标准化方面，据 CNCF 2021 年的调查报告显示正在使用以及正在评估使用 Kubernetes 的受访者已经达到创纪录的 96%，Kubernetes 逐渐走向底层成为更上层平台和服务的基础设施；此外四年以来云原生 Serverless 领域也有了很多进展，其中最著名的 Knative 就是在 2018 年开源的，四年以来 Knative 已经发布了 v1.0 版并且现在已经捐给了 CNCF。本文不会过多介绍 Knative，而是会着重介绍另外两个云原生 Serverless 领域的技术，Dapr 和 KEDA。

KEDA 全称是 Kubernetes Event-driven Autoscaling。顾名思义 KEDA 主要用于 Kubernetes 上分布式应用的自动伸缩，其独特之处在于可根据众多事件源特有的指标进行伸缩，包括开源的中间件及各大云厂商的后端服务等事件源。我们可以用 KEDA 来解耦事件源与分布式应用的自动伸缩，KEDA 使得应用可以根据使用中间件或服务的特有指标进行伸缩，无论该中间件或服务是云上托管的还是开源的。

Dapr 全称是分布式应用运行时，它是把分布式应用的各种能力抽象成多个 Building Block，比如有的应用有状态管理的需求，需要存取一些状态，Dapr 有一个 State Management 的 Building Block 可以提供这方面的能力；有一些事件驱动的分布式应用，有发布订阅的需求，Dapr 有一个 pubsub 的 Building Block 可以提供这方面的能力；再比如很多应用都有输入和输出，于是 Dapr 提供了 Input/Output Binding 的 Building Block。总之，使用 Dapr 可以把分布式的应用和其依赖的后端服务进行解耦。

具体来说一般 FaaS 平台都需要支持多语言，通常需要和多种后端服务去打交道。我们假设一个 FaaS 平台需要支持 5 种语言并且需要和 10 个 message queue 去对接。不用 Dapr 的情况下，每种语言都得用每个 message queue 该语言的 SDK 去对接这个 message queue，总共就会有 50 种实现；在使用 Dapr 的情况下，每种语言仅需要用 Dapr 的 SDK 去和 Dapr 对接，再由 Dapr 去和各个 message queue 对接，这时候只需要 5 种实现。可以看到在引入了 Dapr 之后，极大地降低了 FaaS 平台的复杂度。

相当于我们在 Serverless 的 FaaS 和 BaaS 之间额外添加了一层 Dapr。

Dapr 相当于 FaaS 访问 BaaS 的一个统一的接口。

几个星期之前我们把如何在 OpenFunction 中使用 Dapr 和 Dapr 全球社区做了一个分享，Dapr 的两位联合创始人 Mark 和 Yaron 对 OpenFunction 这种用法很欣赏，也很高兴看到 Dapr 被应用到越来越多的 Serverless Function runtimes 中。

OpenFunction 简介

OpenFunction 主要由 3 个部分组成： Build，Serving 和 Events. 在 Build 和 Serving 之上还有一层抽象 Function， 由 Function 来控制函数的 Build 和 Serving. Function 是用户和 OpenFunction 交互的统一接口，用户无需和 Build 以及 Serving 打交道。

Build 主要负责把函数的代码构建成函数的镜像。采用的是 Cloud Native Buildpacks 技术，这也是最近几年涌现出来的一个云原生构建技术，它的特点就是不需要依赖 Dockerfile 就能够把函数的镜像给 build 出来。目前已被 Google Cloud，IBM Cloud，VMWare， Heroku 等公司采用。现在 OpenFunction 也支持用另外三种依赖于 Dockerfile 的构建技术去 build 应用包括 buildah, BuildKit 和 Kaniko. 以后也会陆续支持用这些依赖于 Dockerfile 的构建技术去构建函数镜像。

Serving 应该是 OpenFunction 中最关键的部分，主要负责运行函数。目前 Serving 包含了同步和异步两个函数运行时。同步函数目前支持用 Knative 作为运行时，我们也计划支持用 KEDA http-addon 作为另一个同步函数运行时，目前我们已经有 Maintainer 积极参与到了这个项目中。OpenFunction 比较有特色的应该是它的异步函数运行时。很少看到在开源或者是云厂商的 FaaS 平台里有专门的异步函数运行时，如果有异步函数也多是通过把事件源的事件转换成一个 HTTP 的请求后再去处理。OpenFunction 的异步函数是直接对接事件源的，由 KEDA 和 Dapr 构成，这是 OpenFunction 所特有的。

OpenFunction Events 的作用类似 Knative Eventing. 但是 Knative Eventing 在设计与使用上都过于复杂，于是 OpenFunction 受 Argo Events 的启发设计了自己的事件管理框架 OpenFunction Events，其由 EventSource, Sink, EventBus 和 Trigger 等部分组成。

OpenFunction Build

当一个函数创建后，Function 会创建一个 Builder，Builder 会创建 Shipwright 的 Build 和 BuildRun，结合 Shipwright 的 BuildStrategy， Shipwright 会生成 Tekton 的 TaskRun，TaskRun 中包含多个 Step，函数代码就是在这些 Step 的控制下构建成函数镜像。

OpenFunction Serving

如前所述，OpenFunction 现在支持 Knative 同步函数运行时和 OpenFunction 异步函数运行时。二者都可以和 Dapr 集成，区别在于 Knative 同步函数运行时因为输入来自 HTTP 请求，只用到了 Dapr 的 output binding 和 pubsub 的 publish 部分；而 OpenFunction 异步函数运行时的输入和输出都是通过 Dapr 对接中间件或云服务，所以用到了 Dapr 的 input 和 output binding 或 pubsub 的 publish 和 subscribe.

我们未来计划支持 KEDA http-addon 作为另一个同步函数运行时，同时也将探讨通过 pool 的技术优化函数冷启动的时间。

OpenFunction Events

OpenFunction Events 是受 Argo Events 启发，其和 Argo Events 的不同之处在于 OpenFunction 的 EventBus 由于使用了 Dapr 的 pubsub 与底层的 message queue 是解耦的，这意味着它并不会绑定到某个云平台或者开源软件上。当 EventSource 收到外部事件后，有两条路径：它可以直接触发一个同步函数，也可以将事件写入到 EventBus 进行持久化。事件写入 EventBus 后也有两种处理方式：它可以直接触发一个异步函数；也可以定义一个 Trigger 来对事件进行筛选，筛选出感兴趣事件后，可触发一个同步函数，或者将筛选出的事件写回到 EventBus 作为输出。

OpenFunction Functions Framework

Functions Framework 是 OpenFunction 的另一个重要组成部分，由 context、plugins、Runtime、Framework 这构成。Framework 读取 OpenFunction 的 Context，将 Function 的上下文读取出来，并且查看这个函数有没有插件，如果有的话则将插件注册进来，然后创建 Runtime 并且启动。当同步或者异步函数触发后，由 Runtime 控制函数运行的生命周期。首先会执行插件的 pre-phase hooks，再调用用户函数，之后调用插件的 post-phase hooks, 最后处理这个函数输出。

加入插件的机制的很大一部分原因是想在这个函数执行的前后，执行一些用户不需要关心的自定义逻辑。比如 OpenFunction 和 SkyWalking 的集成，就需要在这个函数执行前后做一些处理，这个我们稍后展开。

FaaS 可观测性: SkyWalking v9 助力 OpenFunction 实现函数可观测

函数的性能对用户来说比较重要，于是经过和 SkyWalking 社区的充分讨论和合作，OpenFunction 在 v0.6.0 实现了与 SkyWalking 的集成，用户经过简单的配置就能通过 SkyWalking v9 监测函数的性能。

以上面的同步函数触发异步函数为例，为了监测同步和异步函数的性能，用户只需要在函数的 annotation 做如下配置即可（也可以将配置放入 configmap 以对所有函数生效）：

做好上述 tracing 的配置，部署函数后，用户将可以在 SkyWalking V9 的 FaaS 页面看到如下函数调用链及性能数据：

完整示例详见：https://github.com/OpenFunction/samples/tree/main/functions/tracing

SkyWalking 与 OpenFunction 集成 Demo 详见：http://demo.skywalking.apache.org/functions

Case Study: OpenFunction 在自动驾驶领域的应用

OpenFunction 有个社区用户驭势科技是自动驾驶行业的，他们把 OpenFunction 应用于自动驾驶，下面我们看看 OpenFunction 在驭势科技的应用。

驭势科技自动驾驶场景

如上图所示，自动驾驶的场景比较复杂，设计的模块比较多包括车辆检测、调度命令分发、环境感知、行人规避、路由规划、底盘控制、多车协同等等。

为什么自动驾驶厂商需要一个云厂商中立的 FaaS 平台？

原因有以下几点：

• 不同的客户要求部署到不同的云厂商
• 一些客户的车端数据比较敏感，要求放到和公有云隔离的环境
• 数据处理逻辑多样，来自同一数据源的数据在不同场景下的处理逻辑不尽相同
• 数据处理逻辑经常变化
• 自动驾驶涉及的模块较多，不同的模块由不同的团队负责，需要多语言支持
• 大量车端数据需要实时处理
• 自动驾驶车辆也有潮汐的特性，数据处理需求有高峰和低谷

此外，不同的云厂商有不同的后端服务，如果没有一个云厂商中立的 FaaS 平台，对于同一处理逻辑则需要为对接的每一个云厂商都实现相似的实现。

使用 OpenFunction 同步与异步函数处理车辆数据

驭势科技使用 OpenFunction 处理车端数据的归档：

• 同步函数接收请求并分解任务并发送至消息队列
• 消息队列中的子任务触发异步函数运行
• 用不同语言编写的异步函数处理不同的子任务，并将处理结果发送至不同的后端服务
• 利用消息队列解耦生产者和消费者函数

FaaS 应用场景概览

据 CNCF Serverless 白皮书所示，FaaS 可以应用到如下众多场景中去：

• HTTP REST APIs for web applications
• Mobile backends
• Executing logic in response to storage changes like S3, database (insert, update, trigger, delete)
• Performing analytics on IoT sensor input messages (such as MQTT messages)
• Stream processing at scale (ETL, analyzing or modifying data in motion)
• Business logic like order processing, stock trade processing
• Chatbot
• Serving machine learning and AI models
• Batch jobs or scheduled tasks: Jobs that require intense parallel computation, IO, or network for only a few minutes
• Continuous integration pipelines

概括地说，Serverless 架构主要解决 IaaS, PaaS, CaaS 无法高效解决或解决不了的问题：

• 高效地解决新问题：Solved a brand new problem efficiently where an on-demand model wasn’t available
• 高效地解决老问题：Solved a traditional cloud problem much more efficiently (performance, cost)
• 解决“大”的问题：Showed a dimension of “largeness”, whether in size of data processed or requests handled
• 解决弹性的问题：Showed resilience by scaling automatically (up and down) with a low error rates
• 解决快的问题：Brought a solution to market much faster than previously possible (days to hours)

OpenFunction 社区

OpenFunction 已经逐渐被越来越多的公司采用：

• 国内某电信公司采用 OpenFunction 构建云函数计算平台
• 驭势科技 (UISEE) 采用 OpenFunction 处理车端数据
• 全象低代码平台采用 OpenFunction 实现插件机制

也有越来越多的社区贡献者参与到了 OpenFunction 项目中来：

• 主要 Maintainer 来自 KubeSphere 团队
• SkyWalking PMC 成员张伟 @arugal 实现了 SkyWalking 和 OpenFunction Go 版 Functions Framework 的集成
• 驭势科技 (UISEE) 正在参与 Nodejs 和 Python 版 Functions Framework 的开发
• 全象团队参与了命令行工具 ofn 的开发
• @Geffzhang 正在参与 dotNet 版 Functions Framework 的开发

OpenFunction 已经在 2022 年 4 月 26 日经 CNCF 技术监督委员会（TOC）投票被正式接纳为 CNCF 沙箱项目，欢迎更多的社区贡献者参与到 OpenFunction 项目中来。

加入 OpenFunction 社区：

• 微信：搜索并添加公众号 kubesphere , 回复 OpenFunction
• Slack: https://slack.cncf.io 注册并搜索 #openfunction
• Discord: https://discord.gg/hG3yc6uAyC

OpenFunction 路线图

OpenFunction 将在之后的开发中，将重点放在如下功能上：

• 支持更多语言的异步函数框架包括 Nodejs, Python, Java 和 .NET
• 支持将 Java 函数编译成 Native 程序运行在 Quarkus 环境中
• 使用 KEDA 的 http-add-on 作为 Knative Serving 之外同步函数运行时的又一个选择
• 支持 OpenTelemetry 生态作为 SkyWalking 之外的另一个函数 Tracing 的方案
• 增加 OpenFunction 控制台
• 实现 Serverless 工作流
• 对在边缘运行的函数有更好的支持
• 预研基于 Pool 的冷启动优化方案
• 使用 WebAssembly 作为更加轻量的运行时，结合 Rust 函数来加速冷启动速度

函数示例

下面是两个函数的例子，一个异步函数，一个同步函数触发异步函数。

异步函数示例

下面是用异步函数进行日志告警的例子，K8s 的日志被收集并发送到 Kafka 后可以触发异步函数，异步函数找到日志中的某些错误后可以发送告警到 Notification Manager，最后 Notification Manager 会发通知到 Slack。

函数的代码及定义详见：https://github.com/OpenFunction/samples/tree/main/functions/async/logs-handler-function。

同步函数触发异步函数

下面是一个同步函数触发异步函数的例子，同步函数接收 HTTP 请求，处理后将处理结果通过 Dapr 发送到 Kafka，Kafka 中的 Event 进而会触发异步函数。

同步函数的代码及定义详见：https://github.com/OpenFunction/samples/tree/main/functions/knative/with-output-binding。

异步函数的代码及定义详见：https://github.com/OpenFunction/samples/tree/main/functions/async/bindings/kafka-input。

​controller-manager 被重启后，同样会根据配置的变化，把部分资源类型自动转化成联邦资源的逻辑，也就是说，在 Host 集群创建的这部分资源会自动同步到所有成员集群，实际的多集群同步靠 kubefed-controller-manager 来执行。以下资源会被自动创建联邦资源下发：

本文由博客一文多发平台 OpenWrite 发布！

标签：异步,函数,平台,OpenFunction,驾驶,Dapr,FaaS
来源： https://www.cnblogs.com/kubesphere/p/16333545.html