Serverless开源框架对比

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

一、Openfass

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

优点：

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

Openfaas概述

Watchdog

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

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

gateway

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

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

命令行

容器中的任何实例都可以是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

Serverless开源框架对比相关推荐

Everything is Serverless，从开源框架对比说起
摘要:Everything is Serverless. 在众多云计算解决方案中,Serverless 逐渐崭露头角,受到了很多关注并且发展迅猛,今天就关于serverless 开源框架细说二三. 什 ...
python web框架对比_Python六大开源框架对比
Python 是一门动态.面向对象语言.其最初就是作为一门面向对象语言设计的,并且在后期又加入了一些更高级的特性.除了语言本身的设计目的之外,Python标准库也是值得大家称赞的,Python甚至还 ...
系统学习深度学习（七）--主流深度学习开源框架对比
转自:http://blog.csdn.net/u010167269/article/details/51810613,本文做了相关修改. 参考论文:<Comparative Study of ...
开源框架_跨平台开源框架对比介绍
知识库夕阳下你的背影轻轻嗅探你诱人的气息幻想远方的你就在身边这的空气也已不再污浊若隐若现知识库主要记录生活,工作不断归纳总结的经验,能时刻指导我不断清空自我,处于空杯状态去面对未来和过去 ...
Python六大开源框架对比：Web2py略胜一筹
Python是一门动态.面向对象语言.其最初就是作为一门面向对象语言设计的,并且在后期又加入了一些更高级的特性.除了语言本身的设计目的之外,Python标准库也是值得大家称赞的,Python甚至还自带 ...
python企业级框架_Python六大开源框架对比：Web2py略胜一筹
Python是一门动态.面向对象语言.其最初就是作为一门面向对象语言设计的,并且在后期又加入了一些更高级的特性.除了语言本身的设计目的之外,Python标准库也是值得大家称赞的,Python甚至还自带 ...
python企业级框架_Python六大开源框架对比：Web2py略胜一筹(转)
Python是一门动态.面向对象语言.其最初就是作为一门面向对象语言设计的,并且在后期又加入了一些更高级的特性.除了语言本身的设计目的之外,Python标准库也是值得大家称赞的,Python甚至还自带 ...
WebGIS开发四大开源框架对比
目录四个不同的框架的对比: 二维地图框架与GIS的关系前端地图框架: WebGIS二维地图框架: Layer图层分为三大类: 之前给大家介绍了webgis常用的地图框架,点这里回顾一下. 本篇文章 ...
【Python】六大开源框架对比：Web2py略胜一筹
Python是一门动态.面向对象语言.其最初就是作为一门面向对象语言设计的,并且在后期又加入了一些更高级的特性.除了语言本身的设计目的之外,Python标准库也是值得大家称赞的,Python甚至还自带 ...

Serverless开源框架对比

Serverless开源框架对比相关推荐

最新文章

热门文章