使用 Java、Javalin 和 GraalVM 构建 22 MB 的微服务

2022/11/3 1:24:51

本文主要是介绍使用 Java、Javalin 和 GraalVM 构建 22 MB 的微服务,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

使用 Java、Javalin 和 GraalVM 构建 22 MB 的微服务

Oracle的GraalVM允许提前(AOT)编译JVM应用程序。这意味着,编译器不会运行 JVM 进程来执行应用程序,而是构建本机二进制文件。它是如何工作的?在非常高的层次上,基本运行时(称为SubstrateVM)被编译到二进制文件以及实际应用程序中。听起来有点像Go,它还包括一个小的运行时,例如垃圾收集。
在本文中,我将展示如何使用 GraalVM 本机编译构建一个小示例 restful Web 服务。示例应用程序是用 Java 编写的。
为什么有人甚至会对JVM应用程序的本机编译感兴趣?遗憾的是,在E.ON的日常工作中,我仍然需要大量使用Java应用程序。我们的技术堆栈完全是云原生的 - 我们几乎在 Kubernetes 上运行所有内容。我们的应用程序是“典型的”12 因素应用程序。在这样的 dockerized 环境中,我认为原生编译会很有趣有三个主要原因。

应用程序启动时间
这可能不完全是Java的错。我们正在使用Spring Boot,启动速度非常慢。我通常必须调整我的 Kubernetes 就绪探测,使其在启动 Pod 后不要早于 20 秒进行检查。这适用于一个非常小的应用程序 - 500 行代码。

内存占用
根据我的经验,您不希望为Spring Boot应用程序提供少于512MB的内存。否则,可能需要几分钟才能启动。虽然Java,尤其是JVM开销是罪魁祸首,但这也是一个框架问题。众所周知,春天非常臃肿,并且使用了很多反射。

应用程序大小
Java 应用程序容器的大小是另一个问题。这很烦人,但并不重要。我能找到的最小的JRE是~65MB大(基于阿尔卑斯山的openJDK)。如果你使用 Spring Boot,你至少会有一个 ~40MB 的大胖罐子用于你的应用程序。如果你的应用更大,它显然会更多。每个容器至少为 100MB。请注意,Docker 映像的 JRE 层可能会被多个 Docker 映像重用,因此对于应用的每个映像,它并不是真正的 100MB+。虽然我认为在 2018 年拥有 100MB+ 大型 hello world 应用程序肯定是可以忍受的,但如果我可以拥有一个 6MB 的 Go 二进制文件,那就太弱了。

GraalVM AOT 编译可能会改善这种情况。我希望启动时间几乎是即时的,不需要JVM,并且应用程序大小会大大减小。GraalVM 有一些严重的局限性,因为 JVM 的几个功能不能很好地与静态编译配合使用。
完整列表可以在这里找到。文档在这里非常清楚:动态类加载是受支持,将来也不会受支持。相反,编译器会分析代码并将所有必需的类编译到二进制文件中。结合反思,这成为当前Java生态系统的噩梦。许多库和框架使用反射来动态实例化类。GraalVM 不能很好地处理这个问题,在许多情况下,必须提供额外的编译器配置。其中一个原因是,对 Class.forName() 的调用可能基于运行时信息。一个非常简单的例子:
if (someVariable) {
    Class.forName("SomeClazz")
    ...
}
由于someVariable的值在编译时是未知的,编译器无法知道是否包含“SomeClazz”。更不用说它只是一个字符串,编译器必须在编译时在类路径上搜索这个类。如果编译器决定包含此类,它将这样做,并在找不到该类时抛出错误。那很好。但是,这只是尽力而为。不能保证在编译时包含所有必需的类 - 这意味着类可能会丢失,并且在实例化时会引发运行时错误。还有更多的限制,要完整参考,请转到GraalVM的文档。
作为概念证明,我正在寻找一个没有过度使用 反射的休息库。显然这不是弹簧靴——我选择了 javalin.io。它只是码头顶部的一个休息图书馆,仅此而已。

这篇关于使用 Java、Javalin 和 GraalVM 构建 22 MB 的微服务的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程