转载

对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

原文 http://www.infoq.com/cn/news/2016/05/bluemix-ibm-interconnect

正文到此结束