DZone>Java专区>Kotlin和FaaS，一个不可能的联盟？

Kotlin和FaaS，一个不可能的联盟？

在这篇文章中，我想首先解释一下为什么JVM平台对FaaS来说是个坏主意。然后，我将继续提出使用Kotlin的替代方案。

语义学

在做任何事情之前，我们首先应该解决FaaS和无服务器的语义问题。虽然这两个术语有时可以互换使用，但我将在本帖的范围内使用以下定义。在任何情况下，看一看维基百科上人们的共识总是有好处的。

无服务器计算是一种云计算执行模式，其中云提供商运行服务器，并动态地管理机器资源的分配。定价是基于应用程序实际消耗的资源量，而不是基于预先购买的容量单位。

--无服务器计算

功能即服务（FaaS）是一类云计算服务，它提供了一个平台，允许客户开发、运行和管理应用程序的功能，而不需要建立和维护通常与开发和启动应用程序有关的基础设施的复杂性。

--功能即服务

从上面的定义来看。

• 无服务器是指对资源的管理。

  你需要动态地处理它，其属性是弹性。

• FaaS是关于代码的大小。

  大小的演变从一个成熟的应用到微服务再到一个功能。原文中提到了这一点。

Ergo，FaaS意味着无服务器。

JVM和FaaS

JVM平台是一项优秀的技术。特别是，抽象层允许JVM将字节码编译为适应工作负载的本地代码。这就是为什么即使C/C++编译的应用程序更接近于裸机，JVM也能在性能上与之竞争--甚至是获胜的原因。

然而，这种优化是有代价的：JVM需要时间来预热，例如，将类加载到内存中。这就是为什么JVM的性能测试需要几轮热身。由于这个原因，JVM非常适用于长期运行的进程，在这种情况下，启动时间与整个进程的寿命相比是可以忽略不计的。应用服务器是这种用例的典型代表：一旦启动，应该运行很长时间，比如说几天，非常保守。在这方面，一分钟的启动时间毫无意义。

现在是FaaS：在JVM的上下文中，FaaS意味着JVM启动，函数运行，然后一切都被丢弃。在这种情况下，启动时间对整个执行时间有很大影响。此外，JVM没有时间将字节码编译为本地代码：它一直处于 "冷 "状态。

有些人建议保持JVM的状态，以便事后重复使用，从而避免支付启动时间的费用。要实现这一点很简单：只要向函数发送请求的速度快于FaaS提供商丢弃底层JVM的速度。然而，这只是违背了无服务器的目的，因为现在弹性属性已经消失了。

这适用于Kotlin、Java、Scala、Groovy、Clojure以及其他所有运行在JVM之上的语言。尽管我喜欢Kotlin，但这是不可能的：任何告诉我不需要FaaS方法所提供的弹性的人--或者更糟糕的是，没有任何头绪。在大多数情况下，这就类似于建立一个微服务架构。YAGNI。

两个世界的精华

然而，所有的希望并没有消失。有一些方法可以使用Kotlin，并且仍然能够从FaaS中获益。既然FaaS的问题是JVM，为什么不把它去掉呢？有两种简单的方法来实现这一点。

• 使用Graal的本地镜像。

  GraalVM是一个不同技术的集合体。其中有SubstrateVM：它允许将JAR（或类）转化为本地可执行文件。然后，你可以将生成的应用程序包装成一个Docker容器，该容器必须与你选择的FaaS框架兼容。下面是这种方法的一个例子。

• 转译为JavaScript。

  另一个选择是将Kotlin转译成JavaScript。JavaScript不需要JVM平台来运行。然后，代码可以像上面那样被包装成一个容器，或者直接打包成一个ZIP档案。后一种选择可以在专有的基础设施上运行，比如AWS Functions。

这两种方法都需要一个坚实的构建管道，从Kotlin开始，最后得到一个Docker容器（或ZIP）。与最初的设计一样，它们都需要单元测试来测试代码的正确性，也需要集成测试来测试最终的工件是否符合预期。

结论

人们需要意识到大多数技术的背景。你（可能）不需要微服务、FaaS或任何现在正在流行的炒作曲线。然而，通过了解这些技术的优点和缺点，当时机成熟时，你就能利用它们。

就目前而言，将JVM用于FaaS是不明智的。这并不意味着你完全不能使用Kotlin。