对 IBM 推出的事件驱动编程服务 Bluemix OpenWhisk 的问答

紧随其他各大云平台供应商的脚步，IBM 也期望在逐渐成长的无服务器计算（serverless computing）方面有所作为。因此，IBM 为他们的 Bluemix 平台推出了一个全新的事件驱动编程服务，名为 OpenWhisk 。今年三月，IBM 公司于拉斯维加斯举办了 InterConnect 2016 大会，在会上宣布推出 OpenWhisk 这项服务。该服务的设计目标是在发生某些外部事件，例如在收到传感器数据时执行用户自定义的代码，作为对这些事件的响应。

InfoQ 与 Bluemix 的架构师之一 Michael M Behrendt 进行了一次访谈，内容涵盖了对这次会议的感想、以及与 OpenWhisk 和 Bluemix 相关的一些问题。

InfoQ：让我们直奔主题吧。能否请你从事件驱动应用以及虚拟机（VM）这两方面为我们描述一下 Bluemix 平台上的计算模型？

Michael M Behrendt：我们在 Bluemix 平台上提供了一系列不同的计算模型。最底层的抽象模型是 VM，在其之上是容器以及 Cloud Foundry 应用，最上层的抽象模型则是通过 OpenWhisk 实现的事件驱动应用。需要指出的是，这些模型不存在“好”与“坏”的区别，因为在我看来，每种模型都有各自最适应的场景。从 VM 直至事件驱动应用模型，其内置的管理能力也有所上升，这使开发者能够摆脱一些繁重的任务，但随着控制粒度的下降，对于流程执行控制的灵活性也随之下降。

Bluemix 中所提供的容器服务属于后一个层面的抽象模型，它允许开发者设置 Docker 容器，而无需关心底层的操作系统。这种方式的限制在于开发者需要受到容器 host 所使用操作系统的约束。

Cloud Foundry 应用是比容器服务再高一个层面的抽象模型。在这种模型中，开发者只需专注于应用的代码，并将代码推送至 Cloud Foundry 平台。该平台将负责设置用于托管应用实例的容器、自动配置负载均衡层，以及健康管理等等。与容器服务相似，开发者受限于 Cloud Foundry 所使用的操作系统，以及对应用程序特征的特定假设。

最后一种抽象模型 OpenWhisk 同样能够让开发者专注于应用程序本身的代码，但这种方式对于应用代码的架构会进行更多的假设。OpenWhisk 的优点在于它是一种非常粗粒度的执行模型，并且内置了扩展与冗余能力。如果系统不存在任何事件或是需要进行处理的请求，则在内存中不会运行任何代码。随着事件的不断传入，将有越来越多的行为开始执行。在这种模型中，开发者无需考虑如何运行多个进程以实现冗余能力。

InfoQ：Bluemix 主要是基于 Cloud Foundry 所打造的，但它的模型已经发生了变化。这是否意味着这个平台无法兼容不同的提供商？

Michael M Behrendt：并非如此。正如之前所说，我们的目标是为用户提供选择的自由，让他们选择最适合自身需求的方案。也就是说，用户可以同时使用 OpenWhisk、Cloud Foundry、Docker 容器与 VM，并且这些技术之间不会互相干扰。不过，我们仍然为这些不同的模型提供了某些一致性，以实现某些基础的功能，例如 Common ID，这是一种通用的路由层，可实现通用的服务调用功能。

InfoQ：你能否介绍一些关于 IBM Bluemix OpenWhisk 的更多技术细节？

Michael M Behrendt：OpenWhisk 中主要包括三个关键的概念：触发器（Trigger）、规则（Rule）与行为（Action）。触发器代表你需要进行响应的任意场景，例如数据库中的一条新记录、GitHub 中的一次提交、或是某台移动设备进入了某个地理围栏（geofence）。

行为则是或大或小的代码片段，用户需要在 OpenWhisk 中注册这些行为。可以通过 Node、Swift 或 Java 等语言编写行为，也可以由 Docker 容器中的任意二进制文件进行定义。当某个行为被调用时，相应的代码会立刻被部署至一个容器中，并在执行后立即销毁。行为的调用越多，行为的部署次数也相应地增加，以此实现系统的可伸缩性。OpenWhisk 将负责管理部署文件，并以智能地方式对容器进行缓存（这一点对于最小化部署时间至关重要）等等。行为既可以通过 HTTP 调用直接执行，也可以是在 OpenWhisk 平台上由某个触发器通过某种规则所执行的行为。当触发器启动时，相应的行为就会直接被调用。在实现 OpenWhisk 引擎时，我们使用了 Scala、Kafka、Docker 以及其他各种技术和库。Scala 用于实现 OpenWhisk 本身的核心引擎，Kafka 则用于在执行行为时用于 OpenWhisk 内部的消息处理。我们还使用了 Docker 作为执行行为的底层容器机制，并且保证了这些行为的隔离性。

InfoQ：OpenWhisk 是否实现了开源？Java 开发者是否能够在 OpenWhisk 平台上进行开发？

Michael M Behrendt：是的，OpenWhisk 已经完全开源了，它的项目托管在 GitHub 上，基于 Apache 2 许可。并且我们已经收到了来自外部的 pull request（热情欢迎每一位的参与:-）。我们目前为 Node 与 Swift 提供了原生的支持，并且正致力于实现对 Java 的支持（编辑提示：OpenWhisk 现在已经提供了对 Java 的支持），并且在未来将支持更多的语言。此外，我们还支持将 OpenWhisk 中所运行的 Docker 容器作为行为，这为开发者提供了非常高的灵活性，因为只要是能够在 Docker 容器中运行的任意二进制文件都可以作为行为使用。

InfoQ：Bluemix 预期中的使用者是哪种类型的组织？是创业公司还是大型企业呢？

Michael M Behrendt：如果组织希望在云计算平台上构建、运行以及维护现有的产品以及新开拓的产品，那么 Bluemix 就是一种合适的选择。在我看来，无论是创业公司还是大型企业，这种需求已经成为了一种共识。开发者在这两种环境中的表现、他们的工作方式、所使用或准备使用的技术都已经具备了很大的共通性。

我认为，大型企业会有一些额外的特定需求。举例来说，出于法律或数据存储位置的原因，他们需要对于应用程序的部署地点具有灵活的选择。我们将通过一些不同的部署模型，即专用 Bluemix 与本地 Bluemix 实现这种灵活性。此外，大型企业往往需要访问现有的应用程序与数据，因此我们在 Bluemix 中提供了大量的集成功能。

InfoQ：让我们讨论一下 Docker，或者说容器技术与平台即服务（PaaS）这两者之间的比较吧。你认为这两种技术是互斥的还是互补的呢？

Michael M Behrendt：从最底层的角度来说，容器是一种具有极高通用目的的技术，它允许你对任何功能进行打包并运行。因此，容器可支持大量现有的工具与软件，并支持各种不同类型的协议，例如在集群中使用的内部协议以及各种外部协议。在我看来，容器是 PaaS 构建的一种核心元素，但 PaaS 还提供了一些额外的、预先集成的功能，例如负载均衡以及健康状况管理。PaaS 同时遵循某些应用程序架构，例如 12 要素原则。因此，如果你从使用原始的容器这种做法转变为使用 PaaS，那么你将能够利用各种预先集成的功能，从而得以专注于你自己的代码，但也因此失去了某些对细节的控制能力。这种比较最终是一种在内置的管理功能与可控制能力之间的权衡。在我看来，不能简单地说你的某种选择是对是错，答案取决于你所运行的产品类型。

从技术的角度上说，我认为整个行业需要确保从原始的容器到 PaaS，乃至事件驱动计算这样的路线对于用户应当尽量做到无缝地衔接。现在来看，我认为这些领域中还存在着太多的技术壁垒，这一方面使我们这个社区无法实现理想中的高效率，同时也使得用户的选型与实施变得更加困难。

InfoQ：最后，让我们来讨论一下 IBM Interconnect 大会吧。以架构师、开发者或 DevOps 的角度来说，从这次大会中能够学到些什么？此外，你能否谈论一下 Bluemix 的未来？

Michael M Behrendt：在我看来，这次大会所强调的重要信号在于 IBM 既关注于将现有的产品迁移至云计算平台，同时也致力于在创建新应用程序方面的创新。举例来说，IBM 与 VMware 的合作以及 Cloud
Connect 这个服务的宣布就属于对现有产品的支持，而对于 OpenWhisk 的宣布以及我们与 Apple 共同开发的服务端 Swift 等服务就更专注于新应用的开发。

今后，我们将继续推动 Bluemix 的发展，这与我们在过去几年中所设立的技术策略相一致。我们将继续专注于提供最全面的、高度一致的计算模型选择，以及数据、分析、集成、认知以及移动等方面的服务。此外，我们将以开放的形式发布这些服务，为客户提供更自由的选择，使他们能够在这三种集成交付模型中进行选择，即公开、专用以及本地模型。

在 Interconnect 网站上可以下载 Michael M Behrendt 的演讲内容，以及其他各场演讲的内容。

查看英文原文： Q&A with Michael Behrendt on IBM’s Event-driven Programming Service Bluemix OpenWhisk