共计 7790 个字符，预计需要花费 20 分钟才能阅读完成。
嘉宾 | 霍秉杰 整顿 | 王新
出品 | 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/OpenFuncti…
SkyWalking 与 OpenFunction 集成 Demo 详见：http://demo.skywalking.apache…
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/OpenFuncti…。
同步函数触发异步函数
上面是一个同步函数触发异步函数的例子，同步函数接管 HTTP 申请，解决后将处理结果通过 Dapr 发送到 Kafka，Kafka 中的 Event 进而会触发异步函数。
同步函数的代码及定义详见：https://github.com/OpenFuncti…。
异步函数的代码及定义详见：https://github.com/OpenFuncti…。
controller-manager 被重启后，同样会依据配置的变动，把局部资源类型主动转化成联邦资源的逻辑，也就是说，在 Host 集群创立的这部分资源会主动同步到所有成员集群，理论的多集群同步靠 kubefed-controller-manager 来执行。以下资源会被主动创立联邦资源下发：
本文由博客一文多发平台 OpenWrite 公布！
