LOADING

Follow me

Serverless开源对比
6月 01 2020|

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的外壳(通过创建子进程,写入子进程的标准输入,然后从子进程标准输出接受响应数据)

watchdog

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

workflow


二、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实现的网络管理功能。

arch

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

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

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

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

serving

  • 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

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

EVENT

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)环境中.

OpenWhisk


四、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 wechat

微信扫一扫
关注该公众号

0%