开源无服务器软件全览：Fission，Fn，Kubeless以及OpenWhisk

“无服务器”一词是一个极具诱惑力的流行语，因为再也没有什么比服务器更让人痛苦的了。难道说所有的安全漏洞补丁都在你的收件箱里用上百万个电子邮件中数不清的词语描述的？设想一下你如果能够摆脱服务器，你可以不去想这些补丁。难道说防火墙上的所有端口你都得时刻记着他们是否处于关闭状态？这些问题再也不会使你苦恼了。无服务器的世界将使你重获自由。无论如何，这个词是如此承诺的。

无服务器的世界看起来很无拘无束，并且充分利用时间为你的每一个正当使命效忠：你告诉它的它应该是什么样的。但同时也不要被欺骗了。你也将为从苦恼中获取自由而付出一定代价，那就是牺牲这份自由去进行迁移。亚马逊，微软和谷歌云中的无服务器平台通过专有接口施展他们的魔力，每当你将一些苦恼转移到他们的一直等待着的手中时，你就会慢慢上瘾。特别是被像谷歌的大规模集群管理工具Borg这样的工具所吸收。“拥有”这个词太强大了，强大到你可能会发现很难从它手中逃脱。

程序员很反感这种束缚，这也就是为什么许多程序员尝试着开发开源软件包，而这些软件包提供基于云的无服务器平台的一些甚至大部分功能，但是却可以在任何地方使用一大堆代码。这不仅可以使调试和测试变得更加容易进行，而且可以让您的整个配套元件和媒体播放器价格上涨，并且有更好反应时间或其余好处。你甚至可以把它带回家，放在你曾经打电话给服务器机房的带空调的储藏室里。

为了了解这个迅速发展的开放源代码无服务架构的世界，我启动了几台机器并编写了一些简单的逻辑。现在就得出任何确定的结论还为时过早，因为这些项目喜欢说称自己是“预览版”，但是将我们从束缚中解放还是很有希望的。

下面让我们来看看为此所做出的努力的四大软件 - Fission, Fn, Kubeless, 和OpenWhisk.。当然，之后会很快出现更多的软件加入他们的行列。

Fission

一个来自九号平台的开源无服务器对策，Fission将使用一些配有动态装载器的标准容器把Kubernetes与内部容器联系在一起。所使用的功能将被放置于适当的标准容器中，并被加载以回答来自已在容器内的Web服务器的查询。

标准环境包括主要模型（Node.js，Python和Go）以及一些老派的解决方案，如PHP，.Net，Ruby甚至Perl。当然，你也可以用你喜欢的任何语言翻阅你自己的语言，只要你制作一个可以回应HTTP请求的二进制文件即可。

对于任何想通过容器编排提供的自动缩放选项直接跳到Kubernetes级别的人来说，Fission可能是最有用的。他们可以使用Kubectl，Helm和Tiller等标准工具在Kubernetes集群内运行Fission。

一个使用Fission的指令行界面将简单功能转换为运行容器的快速五项示例。

如果你不能依靠HTTP来调用这些函数，Fission可以通过Crontab或来自两个得到支持的排队工具之一的信息（Azure队列存储或NATS流）触发它们。还可以选择在YAML文件中定义“工作流”，以便按顺序运行多个任务。

Fission提供的最大服务是维护动态加载代码的一组标准容器。这些容器基本上是预先配置好的，为您节省添加必不可少的代码以便在群集中正确运行的麻烦。

Fn项目

Fn意味着甲骨文公司涉足无服务器空间，将一些模板，主要语言的标准构建例程和一些标准的开源的应用容器引擎Docker粘合在一起。 Fn比其他应用软件更加以Java为中心，当您考虑甲骨文公司拥有Java时，这并不令人意外。 Fn需要使用多种语言的结合体，并且以Docker为基础就可以构建例程。有些甲骨文公司的资料写道“一个依赖：Docker”。

其中一个更有趣的功能是一套包装器，它可以让您在甲骨文公司的本地堆栈中运行您的亚马逊云服务匿名代码而不是您的代码。使用这些包装器的核心功能是相对而言更容易了解其信息，但这往往只是图片的一部分。大多数人使用匿名代码作为其他亚马逊云服务的粘合代码。这些包装器只能帮助您自己获取匿名代码本身，因此您必须找出其他解决方案来解决亚马逊云服务应用程序编程接口API所带来的繁重工作。这些包装器很棒，但它们的实用性取决于您设计架构的方式以及您的代码运用在多少亚马逊服务上。

与所有这一类工具一样，Fn的接口都是命令行。您输入fn，然后添加命令以创建新模板，生成结果代码或最终部署它。你编写一个简单的函数即一个单独的文件，然后fn会将它与合适的模板进行绑定，以便它可以在某个Docker容器中运行。

Go，Java，Python，Ruby和Node.js的预建模板都捆绑为Fn开发工具包（FDK），但您无需集中时间在它们身上。他们都会要求你建立一个函数，并将一个字符串作为参数，最后返回一个字符串作为结果。没什么比这更容易操作了。

Fn中的这个实验性用户界面展示了如何将多个不同的功能链接到一起进入工作流程。

当您部署代码时，Fn会将其连接到一个HTTP触发器，该触发器捆绑了所有的参数并将它们提供给在Docker容器中运行的函数。差不多剩下所有的事情都是对你的梦想和设计敞开大门的。是的，Fn可以让你免于为所有的部署而头痛，但是你仍然需要在该函数中编写所有的代码。

你可以用Fn内部的机制来略微变动一下。管家信息存储在一个基本数据库（SQL3）中，用于跟踪路线和其他部署信息，但您可以打破传统，直接使用MySQL或Postgres。消息队列还有一个可配置的选项，可以帮助不同版本的Fn进行协调工作。你可能对他们无动于衷，但如果你想要得到更多的话，那么选项就在那里。

Fn经过一番设计后非常轻巧，简单。它需要一些标准的构建工具和一些标准的Docker模板并将它们连接在一起，这样编写一段代码并观测它在其中一个Docker容器中运行起来会更容易。

Kubeless

Kubeless源于Bitnami，是帮助我们用多种不同类型的手持产品提取云的所有功能的公司之一。同Fission一样，Kubeless的设计宗旨也是将无服务器的所有乐趣带给Kubernetes群集。这个名字有点令人发笑，因为这项技术是没有Kubernetes的。如果要说有的话，那就是利用Kubernetes的内置功能来打造快速无服务器的基础架构。

Kubeless将您的功能转变为自定义资源，这是Kubernetes根据需要创建和扩展的功能被设计出来的一点。开发人员似乎偏爱Python，因为这些例子大部分都是写在里面的，但也有Node.js，Ruby，PHP，Go和.Net的运行时间。尽管文档的某些部分缺少Java 1.8，但根据所安装的版本，它已包含在可用运行时间表中。

这个框架的基本功能比其他框架更为复杂。您编写的每个函数都将使用两个参数，一个是参与事件的对象，另一个是参与某个元数据或上下文的对象，与只传递字符串到函数的方法相比，这个框架允许有更复杂一点的自我感知编程模型。最后，你必须返回一个字符串，该字符串将返回任何HTTP请求启动一切的滚动。（在一些堆栈中有一些更好的帮助函数，其中在Node.js运行时间内接受一个对象并对其进行序列化。）

Kubeless有一个用户界面，可以让你编辑你的功能，然后点击进行部署。

如果您不想从HTTP请求中触发功能，则可以将Kubeless配置为在特定时间响应Kafka或NAT消息或预定的调用。您还可以通过为事件创建自定义资源来扩展此功能。

对于已经完全接受Kubernetes的人来说，Kubeless所采用的方式是非常有吸引力的，并且可以让人在集群和自动缩放的世界中感到自在。Kubeless主要是一个快速将一些基本代码转换为回应请求的Kubernetes集群的工具。

OpenWhisk

OpenWhisk是IBM在IBM Cloud中构建云功能的官方工具。它也是由Apache软件基金会带领的一个开源项目（仍处于孵化状态）。 OpenWhisk实际上是几个流行的Apache项目的综合体，这些项目被拼接在一起以占用几行代码，然后将它们包装在Docker容器中，并通过REST API唤醒它们的执行。这些请求由Nginx发起，转化为Kafka信息，然后传递到容器中。身份验证和管理信息存储在CouchDB中。就像一个Apache基金会再度联合。

代码本身可以用JavaScript，Java，Python，PHP，Go等编写，要明白，即使是Swift对那些花时间写iPhone应用程序的人也是如此。当然你可以使用几乎任何你可以绑定到Docker容器中的东西，只要函数参数可以被stdin接受并且结果通过stdout输出。

OpenWhisk开发人员基本上为每种主要语言都构建了一系列标准框架，这些框架将采用一些预先配置的语库来进行一些文本输入并吐出一些文本输出。当你编写你的简要功能时，OpenWhisk会将它粘贴到这个标准容器中，并且一切开始工作 - 前提是你已经按照说明书正确书写了你的功能。

总会有窍门的。 Java代码希望Google GSON库是可用的。 Swift代码的容器将运行Swift的开源版本，因此可能会也可能不会有代码与iOS世界中的经历完全相同的时刻。 JavaScript可能是所有人倾心的选项，并且您的JavaScript代码将在节点6或节点8内运行，这是很好理解和被预测的。

OpenWhisk请求的路径。请求到达HTTP网关后，它将通过Kafka传播到正确的Docker包裹里。

但是，在IBM精心设计的云平台中使用OpenWhisk和在我自己的机器中运行OpenWhisk两者之间存在巨大差异。 IBM的Web界面使得编写几行代码变得简单易懂并且可观测它们成功运行。我却花了半个小时才从无到有在IBM Cloudant数据库中存储文本中看到正在运行的界面。

当我尝试做类似于开源发行版的事情时，在经历过配置API主机之类的障碍之后，我还是一直遇到障碍。这些文档远不如应有的那么完整。有几个不同的快速启动路径的指针，你会尝试着去猜测和填补漏洞。

然而很快就可以清楚的知道，在你自己的机器上运行它们所有的配置有相当多的布局。打包Swift函数的说明是几行代码采用大量配置和脚本来运行的好示例。

无服务器vs. 简易性

这四个项目都在一个很狭窄的细分市场中。“无服务器”这个词没有像预期的一样被广泛使用，还有很多其他的选择可以在没有“无服务器”的时髦词汇的情况下提供很大的灵活性和自由度。数据库通常被认为是最初的无服务器选项，许多像WordPress，Drupal和Magento这样的开源系统都是无服务器的。您可以通过添加适合于大框架的PHP模块来扩展它们。调用插件或模块的内容也某种程度上说是“无服务器”。

在这种情况下，这些工具都不像任何一代技术那样无忧无虑地运行。这四个无服务器平台更是接近Kubernetes或Docker集群的增强型管理器。它们更像是一种管理工具，可以简化所有需要设置和运行这些集群的配置。或者像自动生成工具一样，可以包装你的功能并让它在群集上运行。

他们所扮演的角色是受限于他们的架构。工具创建者的目标是提供最大的灵活性。而他们都有一长串支持的语言，但是他们说支持所有符合输入输出标准的二进制数据。所以他们所能做的就是将零件粘合在一起并吐出一个容器。

事实证明，将容器内的零件正确组合是一个很大的挑战。所有的资料都会说，你可以通过编写一个函数来执行这些任务或动作。但是这个函数能具有有什么样的功能呢？此时你被困在处理容器内的所有工作上。在交出控制权之前，您必须先正确处理容器里的二进制和代码。然后处理所有其他部分，如数据库和API。

这最终要比为亚马逊云服务Lambda，IBM Cloud Functions或微软Azure和谷歌云上的相同功能编写代码要难做的多。当所有的东西就绪，云的数据存储或API服务将提供您所需的持久性和分析。这时你真的只需编写一些简单的函数来编码一些业务逻辑，就完成了。剩下的就是云在那里继续这项工作。

持久性、API集成和云的其他组件都为开源项目带来了一些挑战。所有这些项目都很好地发挥功能并使其运行。但是他们没有解决所有其他事情，这意味着你也必须重复所有这些其他事情。如果您迈着步子逃离主要的云提供商，您会感觉到像个孩子背着一个装满了果酱馅饼的背包走出家门，然后发现家不仅仅是食物。而是一张床，一台洗衣机，一台电视机，一间浴室，一只狗等。

一点想法

在这一点上，开源项目对云本身来说是非常好的营销策略。在初步了解了这些开源项目之后，我很快就开始各种问题，这让在舒适的、被锁定的云环境之外生存变得更加困难。不过随着平台的成熟和程序员推动“无服务器”这个词的含义，这可能会有所改变。

一开始，我认为无服务器主要是云的一种外壳脚本，这种方法只需添加一些逻辑来更平滑进出IBM Cloudant或Amazon S3等大型服务的数据流。现在人们正在接受这个简单的想法，然后在无服务器框架内转向去编写令人难以置信的复杂功能。一些更为大胆的程序员也正在将相当复杂的代码转换，机器学习或计算工作，放在无服务器调用中，这些调用在时间和内存限制基本能完成工作。

开放源代码工具包对这种更大更宏观的无服务器前景做了很好的铺垫。如果您将要完成一项功能中的几乎所有工作，那么这些工具立马会帮助您开始运行。

但这也有个困难，无服务器对于许多人来说可能更便宜的原因是因为只有在运行代码时才需要支付服务器费用。在你有足够大的工作量来保证一台服务器全速运行之前，在云中运行你的函数应该会更便宜，因为这将帮你与其他一些函数共享硬件。如果你的函数只能产生10％的负载，支付10%的负载蜂拥当然是便宜的，而这时云服务器的价格你需要支付100%，花在服务器的90%资金是浪费的。

这种成本组成是很容易让人迷惑的，涉及电力成本，房地产成本和硬件成本。如果你够聪明，便可以大大节省开支。这些开源项目使您可以在自己的服务器场上复制无服务器的魔法，但这也意味着您必须自己找到正确的方法来处理所有的经济问题和部署复杂性。好消息是，他们在处理将函数转换为运行的容器这个工作方面还是做得非常好的。如果，这是唯一的任务的话。