青云霍秉杰：云原生函数OpenFunction在自动驾驶领域的应用

嘉宾 | 霍秉杰   整理 | 王新

出品 | CSDN云原生

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

戳👇观看霍秉杰分享视频

利用SkyWalking监测函数性能，实现可观测性

随着技术的发展，人们越来越少关注底层技术栈的一些细节，越来越多关注自己应用的商业逻辑。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领域的技术——KEDA和Dapr。

KEDA全称是Kubernetes Event-drivenAutoscaling，顾名思义，KEDA主要用于Kubernetes上分布式应用的自动伸缩，其独特之处在于可根据众多事件源特有的指标进行伸缩，包括开源的中间件及各大云厂