Java微服务 vs Go微服务，究竟谁更强？( 二 ) _微服务

文章插图

可以看出，第一回合是Go赢了！
JAVA占的内存太多了；预热对JVM有很大的影响—我们知道JVM在运行时会进行优化，所以这是有意义的
在第一回合的基础上，意犹未尽的又引入GraalVM映像以使 Java 应用程序的执行环境更接近于 Go 应用程序的环境，添加了 GraalVM 映像测试(用 GraalVM EE 20.1.1ー JDK 11构建的本机映像)的结果是：

文章插图

文章插图

通过使用 GraalVM 映像在 JVM 上运行应用程序，我们没有看到吞吐量或响应时间方面的任何实质性改进，但是内存占用的确变小了。
下面是一些测试的响应时间图:

文章插图

第二回合在第二轮测试中，使用一台更大的机器上运行测试。36核（每个核两个线程）、256GB内存、运行oraclelinux7.8的机器。
和第一轮类似，使用了100个线程，每个线程使用了10,000个循环，10秒的加速时间，以及相同版本的 Go，Java，Helidon 和 GraalVM 。
结果如下：

文章插图

这一回合是GraalVM 映像赢了！
下面是一些测试的响应时间图:

文章插图

文章插图

在这个测试中，Java变体的表现要好得多，并且在没有使用Java日志记录的情况下，它的性能大大超过了Go 。Java似乎更能使用硬件提供的多核和执行线程（与Go相比）。
这一轮的最佳表现来自GraalVM native image，平均响应时间为0.25毫秒，每秒事务数为82426个，而Go的最佳结果为1.59毫秒和39227个tps，然而这是以多占用两个数量级的内存为代价的！
GraalVM映像比在jvm上运行的同一应用程序快大约30–40%！
第三回合这次，比赛在Kubernetes集群中运行这些应用程序，这是一个更自然的微服务运行时环境。
这次使用了一个Kubernetes 1.16.8集群，它有三个工作节点，每个节点有两个内核（每个内核有两个执行线程）、14GB的RAM和oraclelinux7.8 。
应用程序访问是通过Traefik入口控制器进行的，JMeter在Kubernetes集群外运行，用于一些测试，而对于其他测试，使用ClusterIP并在集群中运行JMeter 。
与前面的测试一样，我们使用了100个线程，每个线程使用了10,000个循环，以及10秒的加速时间。
下面是各种不同容器的大小:
Go 11.6MB 11.6 MB
Java/Helidon 1.41GB 1.41 GB
Java/Helidon JLinked 150MB 150mb
【Java微服务 vs Go微服务，究竟谁更强？】Native image 25.2MB 25.2 MB
结果如下：

文章插图

下面是一些测试的响应时间图:

文章插图

在这一轮中，我们观察到 Go 有时更快，GraalVM 映像有时更快，但这两者之间的差别很小(通常小于5%) 。
Java似乎比Go更善于使用所有可用的内核/线程—我们在Java测试中看到了更好的CPU利用率。Java性能在拥有更多内核和内存的机器上更好，Go性能在较小/功能较弱的机器上更好。在一台“生产规模”的机器上，Java很容易就和Go一样快，或者更快