Apache OpenWhisk架构概述

本文讲的是Apache OpenWhisk架构概述【编者的话】Apache OpenWhisk是一个开源FaaS平台。现在,AWS Lambda是FaaS最流行的实现。 在开源组件的选择中,OpenWhisk是最好的选择。OpenWhisk是一个健壮的、可扩展的平台,支持数千并发触发器和调用。这篇文章将探索OpenWhisk设计和架构,识别各种组件及其作用,可以帮助我们更好的了解分布式系统和serverless平台。

【3 天烧脑式 Docker 训练营 | 上海站】随着Docker技术被越来越多的人所认可,其应用的范围也越来越广泛。本次培训我们理论结合实践,从Docker应该场景、持续部署与交付、如何提升测试效率、存储、网络、监控、安全等角度进行。

Apache OpenWhisk是一个由IBM和Adobe驱动的开源项目,它是一个健壮的FaaS平台,可以部署在云或数据中心内。相比其他serverless项目,OpenWhisk是一个健壮的、可扩展的平台,支持数千并发触发器和调用。

你可以使用Bluemix托管版本的OpenWhisk或在自己的开发机器上部署基于Vagrant的OpenWhisk环境。在本文中,我们将探索OpenWhisk的设计和架构,识别各种组件及其作用。

要获得最佳的指南,建议在自己的机器上部署基于Vagrant的OpenWhisk环境。OpenWhisk的CLI,wsk应该配置本地的设置。

架构的快速回顾

Apache OpenWhisk旨在作为异步和松耦合的执行环境,可以基于外部触发器运行功能。开发人员编写独立的功能,作为操作上传,完全独立于事件源。事件源通过必不可少的正确的参数集调用操作。 

一旦操作就位,开发人员就可以创建触发器。触发器是事件源显式调用端点,事件源如:数据库、流处理引擎、文件系统和业务应用程序等。一个操作独立于触发器,这意味着触发器可能或可能没有任何操作绑定。当事件源触发一个触发器时,可能不知道被调用的操作。绑定到触发器的操作集只在运行时被发现和执行。

但是,开发人员如何使用触发器绑定操作?这就出现了规则。规则作为触发器和操作之间的粘合,在触发器和操作之间创建松耦合的关联。该设计模式使得相同的操作可以被不同的触发器调用。

这种松耦合的架构使OpenWhisk成为可扩展、可靠和强大的无服务器平台。 执行的每个层都被设计成独立扩展。

操作、规则和触发器可以通过REST端点创建和管理。 事件源调用一个操作所需要做的就是调用触发器的REST API。

下面是演示的工作流程,突出了创建和调用代码的简单而强大的机制:

$ cat > hello.js << EOF

function main() {

console.log('Hello World');

return {msg: 'Hello World'};

}

EOF

$ wsk -i action create helloAction hello.js

ok: created action helloAction

$ wsk -i trigger create helloTrigger

ok: created trigger helloTrigger

$ wsk -i rule create helloRule helloTrigger helloAction

ok: created rule helloRule

$ wsk -i trigger fire helloTrigger

ok: triggered /guest/helloTrigger with id 350364de139547ba8c95113ef0908911

OpenWhisk的构建模块

现在来看看OpenWhisk的核心组件。

下图描绘了OpenWhisk的架构。 从Nginx到Kafka到Docker,这个serverless平台使用多种技术。

通过访问Vagrant Box,使用SSH去检查运行的Docker容器和拉取的图像:

$ docker ps --format "{{.Names}} - {{.Image}}"

wsk0_425_warmJsContainer_20170202T014345371Z - whisk/nodejs6action:latest

wsk0_424_warmJsContainer_20170202T014153330Z - whisk/nodejs6action:latest

nginx - nginx:1.11

invoker0 - whisk/invoker:latest

controller - whisk/controller:latest

kafka - ches/kafka:0.10.0.1

zookeeper - zookeeper:3.4

registrator - gliderlabs/registrator

consul - consul:0.7.0

couchdb - couchdb:1.6

前两个容器代表最近被调用的操作,而其他容器则直接映射到核心组件。下面让我们了解每个组件的作用。

Nginx

这个开源Web服务器暴露HTTP(S)端点给客户端。它主要用做API的反向代理以及终止SSL连接。每个进入OpenWhisk基础架构的请求,包括那些源自wsk CLI的请求,都通过该层。由于它是完全无状态的,所以Nginx层可以轻松扩展。

控制器

在通过反向代理的请求之后,会触发控制器,该控制器充当系统的守门员。在Scala中,该组件负责OpenWhisk API的实际实现。在将控件交给下一个组件之前,它会执行每个请求的身份验证和授权。控制器被认为是系统的协调者,它将决定请求最终采取的路径。

CouchDB

系统的状态在CouchDB(一个开源JSON数据存储)中进行维护和管理。凭证、元数据、命名空间以及操作、触发器和规则的定义存储在CouchDB中。控制器根据存储在此数据库中的凭证识别凭证。

可以通过访问http://192.168.33.13:5984/_utils/(链接仅在开发者机器上使用)从浏览器访问数据库。

查看创建的初始的操作、触发器和规则集http://192.168.33.13:5984/_uti ... hisks

helloAction的源代码也保留在CouchDB中,包括操作的定义、默认参数和所分配的资源配额:

OpenWhisk中的每次调用都会导致一个激活,它包含Action的输出。 例如,以下命令异步调用helloAction导致新的激活ID:

$ wsk -i action invoke helloAction

ok: invoked /guest/helloAction with id 8004746e06f147b99c1e8b0be875ec64

The output of this invocation can be retrieved through the following command.

$ wsk -i activation get --summary 8004746e06f147b99c1e8b0be875ec64

activation result for /guest/helloAction (success at 2017-02-02 08:01:46 +0530 IST)

{

"msg": "Hello World"

}    

如下是存储在CouchDB中的输出。

Consul

OpenWhisk、Kubernetes和Swarm这样的现代分布式计算平台依靠分布式键/值存储进行状态管理。 OpenWhisk使用Consul作为系统每个组件可访问的单一数据源。 同时,consul还提供服务发现功能,使控制器发现调用操作的实体。 这些实体被称为调用者(Invokers),它们直接负责执行代码。 Consul拥有可用的调用者及其健康状况清单。

Consul支持注册者Registrator,注册者可以观看新的Docker容器,并检查他们,决定他们提供的服务。 当Docker引擎创建一个新的容器时,注册者会收到被推入Consul的事件。

当Controller需要将操作委派给调用者时,它会在Consul列表中查找合适的候选人。

Consul的UIhttp://192.168.33.13:8500/ui/#/dc1/services

查看可用的调用者:http://192.168.33.13:8500/ui/#/dc1/kv/invokers/

Kafka

Apache Kafka通常用于构建实时数据管道和流应用程序。它支持需要可靠、高速数据摄取的生产工作负载。 OpenWhisk利用Kafka连接控制器和调用者。

kafka缓存由控制器发送的消息,然后再将它们传递给上节的Consul的调用者。当kafka确认消息被传递时,控制器立即用激活ID进行响应。这种无状态架构使OpenWhisk具有高度可扩展性。

Apache ZooKeeper维护和管理Kafka集群。 Zookeeper的主要工作是跟踪Kafka群集中存在的节点的状态,并跟踪主题、消息和配额。

调用者(Invoker)

调用者使用Scala实现,调用者是处理执行过程的最后阶段。基于运行时的要求和配额分配,会自动创建一个新的Docker容器,作为所选操作的执行单位。 调用者从CouchDB复制源代码,并将其注入Docker容器。一旦执行完成,它将激活的结果存储在CouchDB中,以便将来检索。 调用者决定重新使用现有的“热”容器,或启动一个暂停的“暖”容器,或启动一个新的“冷”容器进行新的调用。它会查询Conusl的容器状态以进行适合的调用。

可能有多个调用者取决于平台的负载和利用率。

根据元数据,调用者会选择要使用的容器图像。以下是调用helloAction的两个容器。

$ docker ps --format "{{.Names}} - {{.Image}}"| grep "JsContainer"

wsk0_457_warmJsContainer_20170202T035154330Z - whisk/nodejs6action:latest

wsk0_456_warmJsContainer_20170202T035037341Z - whisk/nodejs6action:latest   

Docker

Apache OpenWhisk建立在一些开源技术基础上,Docker起着非常重要的作用。 几乎所有的OpenWhisk组件都打包和部署为容器。 从Nginx到kafka到consul,平台运行都是容器。可以通过Docker hub查询OpenWhisk镜像列表。

即将到来:API网关

虽然没有完全集成,OpenWhisk也有一个内置的API网关负责暴露操为HTTP端点。 基于Openresty的Nginx,此项目是由Adobe维护的开源项目。 目前这种能力是可用的实验功能,以下命令显示了可能的选项:

$ wsk -i api-experimental

work with APIs

Usage:

wsk api-experimental [command]

Available Commands:

create      create a new API

get         get API details

delete      delete an API

list        list APIs

总结

OpenWhisk是一个吸引人的项目去了解分布式系统和serverless平台。 感谢IBM和Adobe捐赠到Apache基金会,鼓励社区参与。 最近,尽管许多开源serverless平台如雨后春笋般涌现,而OpenWhisk以健壮的架构和设计的脱颖而出。

在开源组件的选择中,OpenWhisk是最好的选择,贡献总体成功的平台。 希望看到在未来几个月增加采用OpenWhisk。 并关注整合OpenWhisk与流行的数据库、存储引擎和API网关。

原文链接:An Architectural View of Apache OpenWhisk(翻译:范彬)

===============================================================

译者介绍:范彬,从事微服务、Docker和Kubernetes容器技术等方面的工作。可以关注译者的微信公众号:范范米饭。

原文发布时间为:2017-06-08

本文作者:范彬

本文来自合作伙伴Dockerone.io,了解相关信息可以关注Dockerone.io。

原文标题:Apache OpenWhisk架构概述

时间: 2024-09-09 13:37:35

Apache OpenWhisk架构概述的相关文章

《数据中心设计与运营实战》——1.6 WSC的架构概述

1.6 WSC的架构概述 每个WSC的硬件部署与其他的都千差万别.即使在像Google这样的单一组织中,不同的年代也使用不同的基本组件进行系统部署,这也反映了行业的硬件演进.然而,这些WSC系统的架构在过去的几年里已经相对稳定,因此,描述这个通用的架构有助于为后续的讨论做个铺垫. 图1.1描述了WSC的顶层构建.一组低端服务器,典型的是1U1服务器或刀片服务器形式,安装到机架,使用以太网交换机进行内部互联.这些机架级别的交换机,支持1-10Gbit/s连接,有多个上行链路连接到一个或多个集群级(

Apache Sentry架构介绍

介绍 Apache Sentry是Cloudera公司发布的一个Hadoop开源组件,截止目前还是Apache的孵化项目,它提供了细粒度级.基于角色的授权以及多租户的管理模式.Sentry当前可以和Hive/Hcatalog.Apache Solr 和Cloudera Impala集成,未来会扩展到其他的Hadoop组件,例如HDFS和HBase. 特性 Apache Sentry为Hadoop使用者提供了以下便利: 能够在Hadoop中存储更敏感的数据 使更多的终端用户拥有Hadoop数据访问

Solr集群架构概述及delta-import详细配置

背景 由于项目原因,重新熟悉了下Solr,版本为3.6,搭建了主从Solr服务,并使用DIH从RDBMS数据源增量更新索引. 其实也没什么技术含量,就是简单做个总结,分别从部署架构和增量更新两个方面说明下. Solr Replication solr的主从其实是他的replication集群,从本质上说是通过ReplicationHandler来实现的,除了solr server之间可以互相同步之外,每个solr实例内部的core之间也是可以实现同步的,而能自身同步自身的实例称为Repeater

Apache rewrite使用概述

1.开启rewrite sudo a2enmod rewrite 2.停用rewrite sudo a2dismod rewrite 3.服务器环境变量 Apache提供给rewirte模块的环境变量大概分成5个类型. 第一部分: HTTP headers 部分参数 参数名称: HTTP_USER_AGENT 样例参考值: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.0.8) Gecko/2009032609 Firefox/3.

MySQL的体系架构概述

做DBA三年多,接触过很多主流数据库产品,但唯独没机会碰触MySQL,今天开始决定自学MySQL,给自己 冲冲电,先从MySQL的体系架构开始学起. MySQL数据库的体系架构如下图所示: 从上 图中可以看出,MySQL主要分为以下几个组件: 连接池组件 管理服务和工具组件 SQL接口组件 分析器组件 优化器组件 缓冲组件 插件式存储引擎 物理文件 有其它数据库基础的人可以马上发现,MySQL最大的特色是其可插拔的插件式存储引擎,存储引擎是底层 物理架构的实现,每个存储引擎开发者都可以按照自己的

Apache调优概述

建立WEB服务器,在实际的站点运行中,也许服务器的性能表现会不尽如人意,这就需要分析具体的服务器性能瓶颈并找到解决办法,从而达到一个理想的负载状态,apache硬件以外的调优就要考虑他的工作模式.加载的模块.系统内核参数.以及连接请求等等,在此只做一些常用且简单的调优介绍 apache的调优应从以下几点考虑: l模块:由于模块会占用一定的内存资源,所以无用的模块建议不装. l连接状态:由于连接的建立和保持都需要消耗硬件资源,所以为保证硬件性能和访问数相协调,需要对一下数值优化 /proc/sys

CICS Transaction Server的应用架构概述

IBM CICS Transaction Server是一个交易处理服务器,主要运行在基于IBM z/OS 的IBM System z 大型机上.它控制应用程序和用户(从较小的用户数量到成千上万)之间的交互.CICS应用程序提供了高可靠性和可伸缩性.CICS应用程序非常灵活,可使用多种不同的客户接口:从终端,web浏览器到web服务. 正如IBM红皮书解决方案指南介绍,CICS应用程序体系架构有一些业务和技术优势. 有关主题的相关信息,请参阅下面的IBM红皮书: Architect's Guid

WinCE Boot方式及Bootloader架构概述

Bootloader的概念就是一个用于引导的loader,在系统上电的时候最先被运行,然后对硬件平台做最基本的初始化,最后把操作系统加载起来.不同的嵌入式操作系统都有自己的Bootloader,但是本质功能都是一样的. 在WinCE中用的最多的就是EBOOT,是一个基于网络的Bootloader,而且可以根据需要带有命令行菜单功能,网络调试功能以及文件系统的相关功能.在这里我只谈ARM平台的引导,因为其他架构的CPU我没用过,就不吹牛了.一般基于不同的硬件设计,会有不同的引导方式: NORFla

Android 应用架构概述

通常一个App的成长过程都是这样的: 第一阶:先用最少的成本和时间快速把东西做出来. 第二阶段:积累一定用户量之后再小步快跑的迭代功能. 第三阶段:性能和体验上逐步求精. 我发现好多项目在第二阶段和第三阶段耗费了好多本来不应该浪费的人力成本.时间成本.究其原因就是因为前期忽略了合理的架构,我甚至经历过因为前期的设计不合理导致后期技术债务太多项目濒临死掉.整个项目组全员换掉重造锅炉的境地.所以,我们为什么不既能使用最简洁的方式实现功又能要保证后期灵活的扩展能力呢?下面是本人最近项目实践的一些整理,