Serverless开源框架对比

Kubernetes 的蓬勃发展由催生了一系列以它为基础的Serverless框架，目前开源的Serverless框架大多以Kubernetes为基础。接下来，将针对性介绍2020年应用较为广泛的几种Serverless框架.

一、Openfass

OpenFaaS是一个构建无服务器功能的框架，它拥有对指标的第一个类支持。任何流程都可以打包为一个功能，使你能够使用一系列web事件，而无需重复的样板化编码。

优点：

• 通过UI入口和单击安装轻松使用
• 为Linux或Windows的任何语言编写函数，以容器方式运行
• 支持Kubernetes、Docker、mesos等多种运行平台
• 用于模板和定义函数的YAML格式的命令行工具
• 根据请求数自动扩缩

Openfaas概述

1. Watchdog

通过添加Watchdog程序(一个小型的Golang HTTP服务器)，您可以将任何Docker镜像都添加到一个serverless函数中。

函数Watchdog是执行入口，允许通过STDIN将HTTP请求转发到目标进程。通过将应用程序写入标准输出，将响应发送回调用方。

1. gateway

API网关为函数提供了一个外部路由，并通过Prometheus收集监控数据。

API网关将根据需求来扩展函数，底层通过更改Docker Swarm或Kubernetes API中的服务副本数。UI允许您在浏览器中调用函数，并根据需要创建新的函数。

1. 命令行

容器中的任何实例都可以是FaaS中的一个函数。通过使用FaaS CLI，您可以直接部署您的函数，或者通过诸如Node.js或Python这样的模板快速创建新的函数。

核心功能

watchdog对于我们编写的函数封装了一层http的外壳（通过创建子进程，写入子进程的标准输入，然后从子进程标准输出接受响应数据）

Wtachdog，作为函数的对外代理程序，必须作为启动的入口，处理流程如下图所示。

二、KNative

KNative是谷歌开源的 serverless 架构方案，旨在提供一套简单易用的 serverless 方案，把 serverless 标准化。目前参与的公司主要是 Google、Pivotal、IBM、Red Hat，2018年7月24日才刚刚对外发布，当前还处于快速发展的阶段。knative 是为了解决容器为核心的 serverless 应用的构建、部署和运行的问题。

用户只需要编写代码（或者函数），以及配置文件（如何build、运行以及访问等声明式信息），然后运行build和deploy就能把应用自动部署到集群（可以是公有云，也可以是私有云）。其他事情交由serverless平台（比如这里的KNative）自动处理的，这些事情包括：

• 自动完成代码到容器的构建

• 把应用（或者函数）和特定的事件进行绑定：当事件发生时，自动触发应用（或者函数）

• 网络的路由和流量控制

• 函数的自动伸缩

和标准化的 FaaS 不同（只运行特定标准的 Function 代码），KNative期望能够运行所有的workload: traditional application、function、container。KNative建立在kubernetes平台之上，使用kubernetes提供的容器管理能力，以及基于envoy实现的网络管理功能。

• Serving：服务系统，用来配置应用的路由、升级策略、自动扩缩容等功能
• Eventing：事件系统，用来自动完成事件的绑定和触发

Serving

serving 的核心功能是让应用运行起来提供服务。虽然听起来很简单，但这里包括了很多的事情：

• 自动化启动和销毁容器
• 根据名字生成网络访问相关的 service、ingress 等对象
• 监控应用的请求，并自动扩缩容
• 支持蓝绿发布、回滚功能，方便应用发布流程

KNative在Kubernetes之上提供了更高一层的抽象（这些对象是基于kubernetes的CRD实现的）。这些抽象出来的概念对应的关系如下图：

• Configuration：应用的最新配置，也就是应用目前期望的状态，对应了kubernetes 的容器管理（deployment）。每次应用升级都会更新configuration，
  而KNative也会保留历史版本的记录（图中的 revision），结合流量管理，KNative可以让多个不同的版本共同提供服务，方便蓝绿发布和滚动升级.
• Route：应用的路由规则，也就是进来的流量如何访问应用
• Service：注意这里不是kubernetes中提供服务发现的那个service，而是KNative 自定义的CRD，它的全称目前是services.serving.knative.dev。
  单独控制route和configuration就能实现serving的所有功能，但KNative更推荐使用Service来管理，因为它会自动帮你管理route和configuration.

Eventing

serving 系统实现的功能是让应用/函数能够运行起来，并且自动伸缩，那什么时候才会调用应用呢？除了我们熟悉的正常应用调用之外，serverless 最重要的是基于事件的触发机制，也就是说当某件事发生时，就触发某个特定的函数。

事件概念的出现，让函数和具体的调用方能够解耦。函数部署出来不用关心谁会调用它，而事件源触发也不用关心谁会处理它。

目前Serverless的产品和平台很多，每个地方支持的事件来源以及对事件的定义都是不同的（比如 AWS Lambda 支持很多自己产品的事件源）。
KNative自然也会定义自己的事件类型，除此之外，KNative还联合CNCF在做事件标准化的工作，目前的产出是CloudEvents这个项目。

为了让整个事件系统更有扩展性和通用性，knative 定义了很多事件相关的概念。我们先来介绍一下：

• EventSource：事件源，能够产生事件的外部系统
• Feed：把某种类型的EventType和EventSource 和对应的Channel绑定到一起
• Channel：对消息实现的一层抽象，后端可以使用 kafka、RabbitMQ、Google PubSub 作为具体的实现。channel name 类似于消息集群中的 topic，可
  以用来解耦事件源和函数。事件发生后 sink 到某个 channel 中，然后 channel 中的数据会被后端的函数消费
• Subscription：把 channel 和后端的函数绑定的一起，一个 channel 可以绑定到多个KNative service

它们之间的关系流程图如下：

Bus是KNative内部的事件存储层，用户可以选择自己感兴趣的实现，目前支持的方式有：Stub（在内存中实现的简单消息系统）、Kafka、Google PubSub。如果想要事件能够正常运行，必须在KNative集群中安装其中一个 bus 实现方式。

有了bus之后，我们就可以监听外部的事件了。目前支持的事件源有三个：github（比如 merge 事件，push 事件等），kubernetes（events），Google PubSub（消息系统），后面还会不断接入更多的事件源。如果要想监听对应的事件源，需要在KNative中部署一个 source adaptor 的 pod，它负责从外部的系统中读取事件。读取后的事件，会根据用户配置的 Feed 对象（里面包括了事件源和 channel 的对应关系），找到对应的 channel，然后把消息发送到这个channel 中（channel 的消息最终是存储在后端的 bus 系统里的）。然后，KNative会根据 subscription 的配置，不断从 channel 中读取事件，然后把事件作为参数调用对应的函数，从而完成了整个事件的流程。

三、OpenWhisk

OpenWhisk（https://openwhisk.apache.org）是一个开源的Serverless FaaS平台。这个源于IBM的Serverless平台目前由Apache基金会进行孵化和管理。OpenWhisk是一个功能完备的FaaS平台，包含事件驱动及函数执行时等核心组件。OpenWhisk可以运行在不同的基础架构上，包括各类物理机、虚拟机、容器平台（如Kubernetes）、PaaS（如OpenShift）、公有云（如AWS和Azure等）和私有云（如Open-Stack）环境中.

四、Kubeless

和 Fission相似，Kubeless也是运行在 Kubernetes平台之上的 FaaS。 Kubeless官方强调其是 Kubernetes原生（ Kubernetes native）的 Serverless实现。 Kubeless在设计之初就引用了许多 Kubernetes原生的组件，如 Service、 Ingress、 HPA（ Horizontal Pod Autoscaler）等。
目前 Kubeless支持的编程语言有 Python、 Ruby、 Node.js和 PHP。用户可以通过定制容器镜像来自定义函数的执行环境​.

Fission和Kubeless都倾向于向用户隐藏底层容器技术的细节。在 OpenFaaS中函数是以容器的形式定义的，容器对用户而言并不是抽象的，用户在定义函数时将指定具体的容器镜像。这对于一些容器技术爱好者而言是一个优点.

OpenFaaS项目还维护了一个应用市场 OpenFaaS Store，用户可以从这个软件市场上查找和快速部署社区验证过的函数应用​.

五、Fn

• 是 IronFunctions团队成员加盟 Oracle后的产物。 Fn项目的特点是基于容器技术（ Container native），支持多个不同的容器编排平台，
  包括 Kubernetes、 Docker Swarm及 Mesosphere，支持在不同的私有云和公有云平台上进行部署
• Fn可以兼容 AWS Lambda的函数代码，用户可以将 AWS Lambda的代码导入 Fn中运行。不难想象，当 Oracle在其云服务 Oracle Cloud上提供以 Fn为基础
  的 FaaS服务时，用户可以更容易地将他们的 Serverless应用从 AWS Lambda上迁移到 Oracle Cloud
• 容器技术已成为当前云计算的一个重要基石，也是 Serverless实现的一个重要技术手段。通过容器，用户可以很方便地打包各种编程语言的运行环境。通过容器编
  排， Serverless平台可以很快速地将其部署到庞大的计算集群中去.

六、小结

容器技术已成为当前云计算的一个重要基石，也是 Serverless实现的一个重要技术手段。通过容器，用户可以很方便地打包各种编程语言的运行环境。通过容器编排，
Serverless平台可以很快速地将其部署到庞大的计算集群中去.

联系

• 本文作者： zouyee
• 本文链接： https://ustack.io/2020-06-01-Serverless开源对比.html
• 版权声明： 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明出处！

# CLOUDNATIVE # SERVERLESS

文章来源: blog.csdn.net，作者：隔壁老瓦，版权归原作者所有，如需转载，请联系作者。

原文链接：blog.csdn.net/wxb880114/article/details/122995473