Apache OpenWhisk

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

Apache OpenWhisk是一个事件驱动型代码执行的Faas平台，同时该项目也是一个云优先的、分布式的的编程服务。建立在开源软件之上的它，为用户提供了一个编程模型，可将事件处理程序上传到云服务并注册该处理程序来响应各种事件。

工作原理

由于Apache OpenWhisk使用容器构建组件，因此很容易在本地和云基础设施中支持许多部署选项。选项包括许多当今流行的容器框架，如Kubernetes和OpenShift、Mesos和Compose。一般来说，社区支持使用Helm charts在Kubernetes上部署，因为它为开发人员和操作人员提供了许多简单方便的实现方法。除此之外，OpenWhisk所支持的Runtime也是非常丰富的，一方面有相对标准的语言环境，如NodeJS、Go、Java、Scala、PHP、Python、Ruby和Swift、. net和Rust等语言，另一方面也有一些相对定制化的Runtime，例如以Python语言为例，其Action包括Python2Action、Python3AiAction、PythonAction以及pythonActionLoop等。Python2Action使用的是2.7版本，内置了flask、bs、以及kafka_python、scrapy、requests等多种常用的依赖。Python3AiAction则基于Python3，内置了Tensoflow、Pytorch等众多人工智能所需要的框架等。另外OpenWhisk还是一个“建立在开源项目之上的项目”，OpenWhisk与多种流行服务集成，一方面是该项目内部集成了众多开源产品，例如Nginx，Kafka等，这些主流的开源框架集成，一方面保证了产品功能的完整性，另一方面也保证了产品功能组成可以更好的被使用者理解；通过不同开源框架和产品的融合，OpenWhisk形成了一套独有且完整的Serverless解决方案，除了容易调用和函数管理，Openwhisk还包括了身份验证/鉴权、函数异步触发等功能。另一方面，该项目可以在用户使用的过程中集成各类流行服务，例如其原文中的描述： Packages offer integrations with general services such as Kafka message queues, databases including Cloudant, Push Notifications from mobile applications, Slack messaging, and RSS feeds. Development pipelines can take advantage of integrations with GitHub, JIRA, or easily connect with custom data services from IBM Watson for Translation or Speech-to-Text, as well as the Weather company. 除此之外OpenWhisk具有极强的拓展性，在OpenWhisk官网中，有这样的描述：Run your action ten thousand times in a fraction of a second, or once a week. Action instances scale to meet demand as needed, then disappear. Enjoy optimal utilization where you don't pay for idle resources. 我们可以看到OpenWhisk是具有一定的自动伸缩能力（即自动扩缩容能力），可以非常节约资源的面临小规模请求，也可以比较高性能的面临大规模并发请求。

在OpenWhisk的整体流程图中可以看到其包括了Nginx， Controller以及CouchDB，Consul以及Kafka，Invoker等组件。其中Nginx的作用是暴露HTTP/HTTPS接口给客户端。Controller 充当系统的守门员、系统的协调者，它将决定请求即将流转的路径。CouchDB 主要是管理系统的状态。Consul 作为系统每个组件可访问的单一数据源。同时，Consul还提供服务发现功能，使Controller发现调用操作的实体。Kafka 用于构建实时数据管道和流应用程序。Invoker 使用 Scala语言实现，它是处理执行过程的最后阶段。整个项目的流程大致可以简化为：

（1）Nginx Openwhisk面向用户的API完全基于HTTP/HTTPS，遵循Restful设计，因此，通过wsk-cli发送的命令本质上是向其发送HTTP/HTTPS请求，上面的命令大致可以翻译为：

POST /api/v1/namespaces/$userNamespace/actions/myAction

Host: $openwhiskEndpoint

 此处的Nginx主要用于接受HTTP/HTTPS请求，并将处理后的HTTP/HTTPS请求直接转发给Controller

（2）控制器：Controller Controller是真正开始处理请求的地方。Controller使用Scala语言实现，并提供了对应的Rest API，接受Nginx转发的请求。Controller分析请求内容，进行下一步处理。下面的很多个步骤都会和其有关系。

（3）身份验证和鉴权：CouchDB 用户发出的Post请求后，Controller首先需要验证用户的身份和权限。用户的身份信息（Credentials）保存在CouchDB的用户身份数据库中，验证无误后，Controller进行下一步处理。

（4）再次CouchDB，得到对应的Action的代码及配置 身份验证通过后，Controller需要从CouchDB中加载此操作。操作和记录主要要执行的代码和要传递给操作的默认参数，并与实际调用请求中包含的参数合并。除此之外，其还包含执行时对其施加的资源限制，例如允许使用的内存等。

（5）Consul和负载均衡 到了这一步，Controller已经有了触发函数所需要的全部信息，在将数据发送给触发器（Invoker）之前，Controller需要和 Consul 确认，从 Consul 获取处于空闲状态的Invoker的地址。Consul 是一个开源的服务注册/发现系统，在 OpenWhisk 中 Consul 负责记录跟踪所有Invoker的状态信息。当Controller向 Consul 发出请求，Consul 从后台随机选取一个空闲的Invoker信息，并返回。值得注意的是：无论是同步还是异步触发模式，Controller都不会直接调用触发器API，所有触发请求都会通过 Kafka 传递。

（6）发送请求进Kafka 考虑使用Kafka主要是担心发生以下两种状况：

• 系统崩溃，丢失调用请求
• 系统可能处于繁重的负载之下，调用需要等待其它调用首先完成。

Openwhisk考虑到异步情况的发生，考虑异步触发的情况，当Controller得到 Kafka收到请求消息的的确认后，会直接向发出请求的用户返回一个 ActivationId，当用户收到确认的 ActivationId，即可认为请求已经成功存入到 Kafka 队列中。用户可以稍后通过 ActivationId 索取函数运行的结果。Kafka通常用于构建实时数据管道和流应用程序。它支持高可靠、高速数据摄取的生产工作负载。OpenWhisk利用Kafka连接Controller和调用者。Kafka缓存由Controller发送的消息，然后再将这些消息传递给上节的Consul的调用者。当Kafka确认消息被传递时，Controller立即用激活ID进行响应。这种无状态架构使OpenWhisk具有高度可扩展性。 ZooKeeper维护和管理Kafka集群。Zookeeper的主要工作是跟踪Kafka群集中存在的节点的状态，并跟踪主题、消息和配额。

（7）Invoker运行用户的代码 Invoker从对应的Kafka Topic中接受Controller传来的请求，会生成一个Docker容器，注入动作代码，使用传递给他的参数执行它，获取结果，最后销毁容器。这一部分也通常是对整个项目优化的重点，例如通过大量性能优化以减少开销，或者通过池化等操作降低冷启动率，进而降低延时。

（8）CouchDB存储请求结果 Invoker的执行结果最终会被保存在CouchDB的whisk数据库中，格式如下所示：

{

   "activationId":"31809ddca6f64cfc9de2937ebd44fbb9",

   "response":{

       "statusCode":0,

       "result":{

           "hello":"world"

       }

   },

   "end":1474459415621,

   "logs":[

       "2016-09-21T12:03:35.619234386Z stdout: Hello World"

   ],

   "start":1474459415595

}

保存的结果中包括用户函数的返回值，及日志记录。对异步触发用户，可以通过步骤6中返回的 ActivationID 取回函数运行结果。同步触发的的结果和异步触发一样保存在 CouchDB 里，Controller在得到触发结束的确认后，从 CouchDB 中取得运行结果，直接返回给用户。

关于自动扩缩部分，在官方文档中并没有详细说明，但是在IBM团队的博客中，却追溯到了自动扩所容的影子。该标题是《验证 OpenWhisk 的自动伸缩特性 (Autoscale)》，文章内容是说，当创建 Action之后，再构造Web请求，当Web请求数为1时，OpenWhisk 启动了一个Container来处理；同时构造10个请求时，OpenWhisk 也会创建更多的 Container 来处理请求；并且文章最后表述OpenWhisk 通过自动申缩（AutoScale）功能可以很好的解决性能瓶颈。

功能与策略

冷启动

当对OpenWhisk源代码进行分析，对Invoker部分进行源代码的阅读，可以看到该过程分为：Uninitialized、Starting、Started、Running、Paused、Removing等几个部分。其中Uninitialized部分可能会有两个事件，分别是Start和Run，对于Start的描述为Pre warm a container (creates a stem cell container)，对于Run的描述为Cold start (no container to reuse or available stem cell container)，同时在源代码中也可以看到这样的描述：

A pool managing containers to run actions on. This pool fulfills the other half of the ContainerProxy contract. Only one job (either Start or Run) is sent to a child-actor at any given time. The pool then waits for a response of that container, indicating the container is done with the job. Only then will the pool send another request to that container.

Upon actor creation, the pool will start to prewarm containers according to the provided prewarmConfig, iff set. Those containers will **not** be part of the poolsize calculation, which is capped by the poolSize parameter. Prewarm containers are only used, if they have matching arguments (kind, memory) and there is space in the pool.

实际中OpenWhisk的启动过程可以粗略看为三部分：通过Docker run启动容器，并通过Docker inspect获取容器的IP地址。通过POST/init等操作初始化容器。通过POST/runDocker执行运行操作，启动新容器以运行操作。这个流程通过流程表示如下：

在整个策略中，有一个值得注意的事情是，OpenWhisk团队曾说，在第一次启动时，一定是冷启动，之后会通过温启动或者预热等操作进行函数调用，少了容器拉起的部分。

存储相关

CouchDb主要包括三个部分，Subjects、Whisks和Activations。Subjects主要存储用户验证信息等，Whisks存储了命名空间，Rules，Actions等信息，Activations存储了Activations等信息。KeyValue Store主要存储了Invoker等信息，包括服务和状态。

应用场景

官方给的OpenWhisk操作的事件触发器的一些示例包括：

• 记录在数据库中的一次更改
• 一个超出了某个温度的 IoT 传感器，GitHub 中的一次代码变更
• 或者甚至是一个来自 Web 或移动应用程序的简单 HTTP 请求

非常适合 OpenWhisk 执行模型的一些用例包括：

• 将应用程序分解为微服务：OpenWhisk 操作的可扩展模块化，使得它们能够有效地将负载密集型、可能很麻烦的（后台）任务从前端代码转移到云后端。
• 移动后端：因为移动开发人员通常没有管理服务器端逻辑的经验，而只专注于在设备上运行的代码，所以 OpenWhisk 操作链很适合用作移动后端。
• 数据处理：由于目前可用的数据过多，通常需要能够采用一种或另一种方式处理和应对新数据。这包括存储在记录中的结构化数据，以及文档、图像或视频处理。
• 物联网：从很大程度上讲，物联网（IoT）场景实质上是传感器驱动的。例如，OpenWhisk 操作能够有效地响应超出特定温度的传感器。