> Photo by Raquel Martínez on Unsplash

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

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

> quarkus official performance stats

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

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

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

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

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

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

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

场景

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

> the database

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

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

> the apache benchmark command

Golang服务

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

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

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

构建本机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示例&＃xff0c;大致遵循quarkus反应式MySql扩展指南。

> datasource configuration

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

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

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

构建Java本机可执行文件

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

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

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

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

强调服务

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

不适使用&＃xff1a;

MacBook Pro(15英寸&＃xff0c;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空闲

· 引导时间

· 响应潜伏时间平均值/最大值

· 吞吐量(每秒请求数)

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

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

quarkus jvm热点— 100MB / 0.5 CPU

· 闲置CPU使用率0.25&＃xff05;

· 空闲ram使用情况66MB

· 自举时间6s

> CPU usage during bootstrap. ( a spike , probably jit &＃43; launching JVM )

第一轮压力测试(Cold JVM)

令人惊讶的是&＃xff0c;没有失败的请求。

> CPU usage during stress.

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

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

quarkus jvm热点— 200MB / 1个CPU

· 闲置CPU使用率0.13&＃xff05;

· 空闲ram使用情况66MB

· 引导时间3s

> CPU usage during bootstrap. ( a spike again )

第一轮压力测试(Cold JVM)

> CPU / RAM usage under stress

> 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

> 142 mb ram was sufficient

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

现在&＃xff0c;让我们看看本地图像将如何执行。

quarkus Java Native — 100MB / 0.5 CPU

· 引导时间&＃xff1a;0.125s。 (!!!)

· 启动时没有CPU高峰

> cpu / ram during bootstrap

压力测试结果

> CPU reached 0.5 limit as expected

> Good ram usage, 19MB active memory. WOW

quarkus Java Native — 200MB / 1个CPU

· 即时引导(0.0125s)

· 4空闲ram用法

· 在压力下使用19种内存

· 100&＃xff05;的CPU使用率

· 启动时没有CPU高峰

检测结果

quarkus Java Native — 300MB / 2 CPU

没提升。

golang — 100MB / 0.5 CPU

· 空闲CPU 0

· 闲置内存2.3MB(不错)

· 引导时间&＃xff1a;几分之一秒

· 启动时没有CPU高峰

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

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

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

golang — 200MB / 1个CPU

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

压力下的CPU / RAM使用率

> cpu utilization during stress

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

golang — 300MB / 2个CPU

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

摘要

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

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

延迟和吞吐量

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

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

CPU利用率

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

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

RAM使用

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

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

引导时间

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

开发经验

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

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

结论

Java成为云原生&＃xff0c;Golang并没有像JVM那样过度地执行它&＃xff0c;这是非常好的。 我相信它将来会被广泛使用。 但是golang绝对可以打架。

因此&＃xff0c;请谨慎选择&＃xff01;

而且不要忘了给仙人掌浇水

(本文翻译自Igor Domrev的文章《Cloud-Native Java vs Golang》&＃xff0c;参考&＃xff1a;https://medium.com/swlh/cloud-native-java-vs-golang-2a72c0531b05)