转载

云原生的 Java与Golang

Java曾经著名的座右铭："一次编写并在任何地方运行"如今已经过时了，我们想要运行代码的唯一地方是在容器内。 "及时"编译器没有任何意义。

由于这个原因，Java生态系统可能正处于其转型之中，以便更好地适应云。 Oracle的GraalVm允许将字节代码编译为Linux可执行文件(ELF)和Rad Heat的Quarkus以及其他框架，以使其像引导一个反应应用程序一样容易。 Quarkus还以Netty和Vertx.x为核心来构建非常有效的响应式Web服务。

> quarkus official performance stats

Java编译为可执行的二进制文件，可在毫秒内启动，并且占用的内存很小。这可以利用Java生态系统，甚至可以用其他JVM语言(例如Scala和Kotlin)编写!

听起来好得令人难以置信……

如果您不相信，可以使用在线项目生成器或通过使用maven插件在本地生成项目来玩Quarkus。

另一方面，Golang诞生于云中，当在容器中运行时，没有留下任何负担。它被认为是云的编程语言。从第一天开始，小型二进制文件，快速启动程序，较小的内存占用量就可以了。并且被广泛采用。对Java世界的严峻挑战。

Java有机会吗? 只有时间证明一切。但是，出于好奇，我想将Java云原生服务与golang同类服务在性能和开发经验方面进行比较。

在这篇文章中，我将强调两项服务。比较他们的CPU，RAM，延迟和正常运行时间。这些服务将在具有相同资源分配的容器中启动，并且Apache基准测试将使他们汗流sweat背。

对于我的案例研究来说，这是一个"足够好"的基准，因为我不认为找到最佳/最差的基准结果，而是比较在相同环境下执行的两个基准。

场景

两种服务都将连接到在另一个容器中运行的MySQL数据库，该容器具有一个表和三行。

> the database

每个服务将获取所有三行，将其转换为域对象，然后编写JSON数组响应。

Apache基准测试将运行10K请求，并发级别为100，这是quarkus JVM版本的两倍(还用于测试"冷" /"热" JVM))

> the apache benchmark command

Golang服务

使用称为gin的流行的反应式Web框架，该框架具有出色的基准。

在寻找golang非阻塞MySQL驱动程序时，我一无所获，互联网上建议同时使用go-sql-driver，这就是我要使用的。

golang样式非常明确。一个在你脸上的态度。主要功能启动服务器，配置请求处理程序，并打开数据库连接。

构建本机go可执行文件

> Easy and fast build process. The only tool I had to use was the go compiler. No hustle at all.

Kotlin Cloud本机服务— Quarkus

这是一个Kotlin示例，大致遵循quarkus反应式MySql扩展指南。

> datasource configuration

与go版本相比，存在一些隐式东西，CDI依赖注入，使用javax注释的声明性路由，自动配置解析以及数据源/连接创建/服务器引导程序。但这是使用框架的代价，它为您带来繁重的工作，并决定了它的工作方式。但是，它比go版本要短得多，只要我不介意黑魔法就行!

底层有一个Netty反应式Web服务器，由Vert.x多事件循环包装，而Vert.x反应式MySQL驱动程序可以通过一个线程处理多个数据库连接。

另外，我可以使用Kotlin令人惊叹的收藏库来折叠一个列表，其中go版本还没有泛型(但即将推出)，也没有丰富的标准收藏库，我不得不手动编写或生成它。

构建Java本机可执行文件

> It took 4 minutes, partly because Gradle executes the native image compilation inside a Linux Graa

基本上，我能够弄清楚构建本机可执行文件的容器中发生的事情是SubstrateVM。设计为可提前编译的可嵌入虚拟机链接到我们的代码，并作为一个单元进行编译。甲骨文表示，这是惊人的，但并非没有代价，SubstrateVM的优化次数少于HotSpot Vm，并且垃圾回收器更简单。

执行此操作的编译器称为" Graal"，它与语言无关，在使用Java字节码之前，需要先将其翻译为中间表示形式，即Truffle语言。这非常有趣，可以在这篇文章中找到有关Graal和Truffle的详尽解释。

构建Java本机图像看起来更加复杂，速度较慢，并且生成的二进制文件几乎是文件的两倍。但这有效! 与一个Java Uber(胖)Jar相比，35M可执行二进制文件实际上是什么，它可以轻松地大十倍。 35MB甚至可以放在aws lambda中。

强调服务

我正在使用以下设置在本地计算机上运行所有测试：

不适使用：

MacBook Pro(15英寸，2017年)
2.9 GHz Intel Core i7(8核)
16 GB 2133 MHz LPDDR3

不适使用名为cAdvisor的工具来监视我的容器的状态。

场景

quarkus jvm热点容器
quarkus java本机容器
golang容器

每个都分配了以下资源

100MB / 0.5 CPU | 200MB / 1个CPU | 300MB / 2个CPU

我对……感兴趣

cpu / ram利用率(多核的利用率)
cpu / ram峰值
cpu / ram空闲
引导时间
响应潜伏时间平均值/最大值
吞吐量(每秒请求数)

现在，我将运行许多基准测试，并为每个基准收集许多数据点。如果有太多信息，请随时跳至摘要结尾

github repo以及该实验的所有代码都可以在这里找到

quarkus jvm热点— 100MB / 0.5 CPU

闲置CPU使用率0.25%
空闲ram使用情况66MB
自举时间6s

> CPU usage during bootstrap. ( a spike , probably jit + launching JVM )

第一轮压力测试(Cold JVM)

令人惊讶的是，没有失败的请求。

> CPU usage during stress. 云原生的 Java与Golang

> RAM launched from 60 to almost 100 MB (limit) and stayed there.

第2轮压力测试(温暖的JVM)

quarkus jvm热点— 200MB / 1个CPU

闲置CPU使用率0.13%
空闲ram使用情况66MB
引导时间3s

> CPU usage during bootstrap. ( a spike again )

第一轮压力测试(Cold JVM)

> CPU / RAM usage under stress 云原生的 Java与Golang

> Surprisingly the JVM did not eat all the allocated 200MB and 140MB was sufficient

第2轮压力测试(温暖的JVM)

quarkus jvm热点— 300MB / 2 CPU

空闲cpu / ram与以前的方案相同
引导时间1.1s(NICE)

> CPU usage during bootstrap, a spike again.

第一轮压力测试(Cold JVM)

> Good CPU utilzation 云原生的 Java与Golang

> 142 mb ram was sufficient

第2轮压力测试(温暖的JVM)

现在，让我们看看本地图像将如何执行。

quarkus Java Native — 100MB / 0.5 CPU

引导时间：0.125s。 (!!!)
启动时没有CPU高峰

> cpu / ram during bootstrap

压力测试结果

> CPU reached 0.5 limit as expected 云原生的 Java与Golang

> Good ram usage, 19MB active memory. WOW

quarkus Java Native — 200MB / 1个CPU

即时引导(0.0125s)
4空闲ram用法
在压力下使用19种内存
100%的CPU使用率
启动时没有CPU高峰

检测结果

quarkus Java Native — 300MB / 2 CPU

没提升。

golang — 100MB / 0.5 CPU

空闲CPU 0
闲置内存2.3MB(不错)
引导时间：几分之一秒
启动时没有CPU高峰

结果有点歪斜。由于某种原因，一小部分请求需要大约7秒钟才能完成。

当再次尝试运行测试以查看偏斜结果是否能够再现测试时，实际上是否已将其压碎!

运行时错误：无效的内存地址或nil指针取消引用。嗯…可能是我做错了什么? 似乎go-sql库中存在错误。如文档所述，从表中读取的代码是100%，并且99%的时间都可以工作。这不应该发生。

golang — 200MB / 1个CPU

我不断收到运行时错误。可疑总是在测试结束时。但是，go-mysql驱动程序的校正不是主要问题，因此在完成90%的请求后手动终止测试。

压力下的CPU / RAM使用率

> cpu utilization during stress 云原生的 Java与Golang

> RAM usage during stress. 12.27MB, very nice.

golang — 300MB / 2个CPU

没有明显的改善，所有统计数据几乎相同。 CPU利用率低于1.0。我不知道为什么go不能充分利用更多的内核，有趣的是……可能是因为该过程受IO约束，或者可能是杜松子酒需要手动配置才能更好地利用多个内核。

摘要

> aggregated stats ( warm jvm/native image | golang )

似乎Quarkus已准备好投入生产，它允许简单的JVM /本机发行版/开发模式，并允许在本地运行本机测试。而且，只要您不使用反射或JNI，就可以安全地配置GraalVM。否则，您将必须自己配置graal编译器，并且也有针对此的现有解决方案。

延迟和吞吐量

golang和云原生Java均产生了相似的结果，尽管平均而言稍微偏爱golang服务。但是，java本机结果更加稳定。 Golang服务有时会在1.25µs内做出响应，而很少在7s内做出响应。

"预热"后的JVM产生了良好的结果，但比本机或go版本差。

CPU利用率

当给定的内核少于单核时，go和native-java在负载下均表现不佳，而在使用2个内核启动时，它们并没有表现出明显的改进。可能是因为工作负载受IO限制。或者因为gin / Netty的默认配置没有考虑多个内核。

另一方面，JVM利用了赋予它的所有内核，并在各个方面提高了性能。

RAM使用

压力很大，java本机为40MB，golang服务为24MB。两种情况都不错，尽管golang版本使用的ram几乎少了两倍。

JVM在压力下使用了140MB。完全是官方的quarkus统计信息。对于JVM来说一点都不差，但是几乎是golang版本的6倍。

引导时间

golang和云原生Java均会立即启动，而JVM版本则需要几秒钟(取决于分配的CPU)，并在启动时产生CPU峰值。

开发经验

这更是一个宗教问题，而不是一个实际问题。如此病态，请谨慎回答。 Quarkus创建Java世界中非常熟悉的抽象(例如基于注释的DI)。它为您启动服务并创建连接池。可以使用丰富的收藏标准库和泛型。但是，这种感觉有点像黑魔法，一旦停止工作，您会感到无助。此外，将Java代码编译为本地二进制文件并不是那么简单，您必须意识到其中的局限性和注意事项，尽管Red Hat在扩展方面取得了很大的进步，但并非每个Java库都将与本地编译兼容。。 (预先配置为本地编译的Java库)。使用与本机编译不兼容的库(例如Guice)将需要您手动配置Graal VM。这是可能的，但并非像使用广口瓶那样直接。 Quarkus和Graal VM也"相对"新。因此，有许多冒险等待着。但由于是双模式(JVM或本机)。万一本机版本停止工作，总会有一个退路，这是解决任何新出现问题的好方法。

另一方面，Golang仅在现在(存在10年后)才承认需要泛型。当然，它不喜欢隐性事件的继续。从很多方面来说，这都是好事。另外，尽管go社区在追赶方面确实做得很好，但是可用的工具和库却更少(例如，只有一个流行的阻塞MySQL驱动程序)。另一方面，它的编译和构建过程非常快速/简单。每个golang软件包都将为您工作，而不受Java本地平台引入的限制。