为什么JVM平台对于无服务器FaaS来说是个坏主意？ - frankel

JVM平台是一个很好的技术产品。特别是，抽象层允许 JVM 将字节码编译为适合工作负载的本机代码。这就是为什么即使 C/C++ 编译的应用程序更接近裸机，JVM 也能够在性能方面与它们竞争 - 甚至获胜的原因。

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

现在FaaS来了 。

在做任何事情之前，我们应该首先解决 FaaS 和 Serverless 的定义。

查看维基百科上的人都同意的内容：

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

函数即服务 (FaaS) 是一种云计算服务，它提供了一个平台，允许客户开发、运行和管理应用程序函数，而无需构建和维护通常与开发和启动应用程序相关的基础设施的复杂性。

从上面的定义来看：

无服务器是关于资源的管理

您需要动态处理它，属性是弹性

FaaS 是关于代码的大小

规模的演变从成熟的应用程序到微服务再到函数。

因此，FaaS 意味着无服务器。

在 JVM 上下文中，FaaS 意味着 JVM 启动、函数运行、然后一切都被丢弃。在这种情况下，启动时间对整体执行时间有重大影响。此外，JVM 没有时间将字节码编译为本机代码：它还处于“冷态”。

一些人建议在 JVM 运行之后一直保持它，这样避免支付启动时间的成本。实现这一点非常简单：只需比 FaaS底层销毁JVM速度更快地速度向函数发送请求（一直保持请求活跃，类似缓存击中率）。然而，它违背了无服务器的目的，因为弹性属性现在已经消失了。

这一分析适用于 Kotlin、Java、Scala、Groovy、Clojure 以及在 JVM 之上运行的所有其他语言。即使我喜欢 Kotlin，这也是行不通的：除非没有人需要 FaaS 方法提供的弹性。

两全其美的方法有吗？

然而，并没有失去所有希望。有很多方法可以使用 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。