以下文章来源于程序猿 DD ，作者 DD 编辑部
作者 | 程序猿 DD 责编 | 张文
Java 微服务能像 Go 微服务一样快吗？这是我最近一直在思索的一个问题。
去年 8 月份的 the Oracle Groundbreakers Tour 2020 LATAM 大会上，Mark Nelson 和 Peter Nagy 就做过一系列基础的的测试用以比较两者。接下来就给大家介绍下。
在程序员圈子里，普遍的看法是 Java 老、慢、无聊 ，而 Go 是快、新、酷。
为了尽可能的进行一个相对公平的测试，他们使用了一个非常简单的微服务，没有外部依赖关系(比如数据库)，代码路径非常短(只是操纵字符串)，使用了小型的、轻量级的框架(Helidon for Java 和 Go 工具包 for Go)，试验了不同版本的 Java 和不同的 jvm。
对决双雄
我们先来看下擂台两边的选手：
身穿深色战服的选手是 JAVA
Java 是由被甲骨文收购的 Sun Microsystems 开发的。它的 1.0 版本是 1996 年发布的，最新的版本是 2020 年的 Java15。主要的设计目标是 Java 虚拟机和字节码的可移植性，以及带有垃圾收集的内存管理。它是全世界最流行的语言之一，在开源环境下开发。
我们先看下 JAVA 的问题，大家普遍认为它最大的问题就是速度慢，已经慢到让人觉得不再是合理的，而是更具历史意义的。不过这么多年来，Java 诞生了很多不同的垃圾收集算法用来加快它运行的速度。
Oracle 实验室最近已经开发了一个新的 Java 虚拟机 GraalVM，它有一个新的编译器和一些令人兴奋的新特性，比如能够将 Java 字节码转换成一个本机映像，可以在没有 javavm 的情况下运行等。
而它的对手就是年轻充满活力的 GO
GO 是由谷歌的罗伯特 · 格里默、罗伯 · 派克和肯 · 汤姆森创建的。他们对 UNIX、B、C、Plan9、UNIX 窗口系统等做出了重大贡献。GO 是开源的，在 2012 年发布了 1.0 版本(比 JAVA 晚了 16 年)，在 2020 年发布了 1.15 版本。无论是在采用方面，还是在语言和工具生态系统本身方面，它都在快速增长。
GO 受 C、Python、JavaScript 和 C++ 等多种语言的影响。被设计成高性能网络和多处理的最佳语言。
StackOverflow 有 27872 个带 "Go" 的问题，而 Java 只有 1702730 个。足见长江后浪推前浪。
Go 是一种静态类型的编译语言。它有称为 goroutines 的轻量级进程(这些不是 OS 线程)，它们之间有独特的通信通道(类型化的，FIFO)。Go 是许多 CNCF 项目的首选语言，例如 Kubernetes、Istio、Prometheus 和 Grafana
赛前对比
从个人感觉来说，Go 相比 JAVA 来说，优点在于：
Go 更容易实现复合、纯函数、不变状态等功能模式。
Go 处于生命周期的早期，因此它没有向后兼容性的沉重负担— Go 仍然可以轻易打破某些限制来改进。
Go 编译成一个本机静态链接的二进制文件 - 没有虚拟机层 - 二进制文件拥有运行程序所需的一切，这对于 " 从头开始 " 的容器来说非常好。
Go 体积小、启动快、执行快(目前是的)
Go 没有 OOP，继承，泛型，断言，指针算法
Go 写法上较少的括号
Go 没有循环依赖、没有未使用的变量或导入、没有隐式类型转换的强制
Go 样板代码少得多
缺点是：
Go 工具生态系统还不成熟，尤其是依赖关系管理——有几个选项，没有一个是完美的，特别是对于非开源开发；仍然存在兼容性挑战。
导入将代码绑定到存储库，这使得在存储库中移动代码成为一场噩梦。
调试、评测等仍然是一个挑战
用到了指针
需要实现一些基本的算法
没有动态链接
没有太多旋钮来调优执行或垃圾收集、概要文件执行或优化算法。
比赛开始
使用 JMeter 来运行负载测试。这些测试多次调用这些服务，并收集有关响应时间、吞吐量(每秒事务数)和内存使用情况的数据。对于 Go，收集驻留集大小；对于 Java，跟踪本机内存。
在测量之前，使用 1000 次服务调用对应用程序进行预热。
应用程序本身的源代码以及负载测试的定义都在这个 GitHub 存储库中：https://github.com/markxnelson/go-java-go
第一回合
在第一轮测试中，在一台 " 小型 " 机器上进行了测试，是一台 2.5GHz 双核 Intel core i7 笔记本电脑，16GB 内存运行 macOS。测试运行了 100 个线程，每个线程有 10000 个循环，上升时间为 10 秒。Java 应用程序运行在 JDK11 和 Helidon2.0.1 上。使用 Go 1.13.3 编译的 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
Native image 25.2MB 25.2 MB
结果如下：
下面是一些测试的响应时间图 :
在这一轮中，我们观察到 Go 有时更快，GraalVM 映像有时更快，但这两者之间的差别很小 ( 通常小于 5% ) 。
Java 似乎比 Go 更善于使用所有可用的内核 / 线程—在 Java 测试中看到了更好的 CPU 利用率。Java 性能在拥有更多内核和内存的机器上更好，Go 性能在较小 / 功能较弱的机器上更好。在一台 " 生产规模 " 的机器上，Java 很容易就和 Go 一样快，或者更快。
最后
接下来会做更多的测试比赛，来看一看究竟谁更好！
有兴趣的你也可以自己试一试，记得告诉我们结果哦！
参考链接：https://medium.com/helidon/can-java-microservices-be-as-fast-as-go-5ceb9a45d673
程序员如何避免陷入 " 内卷 "、选择什么技术最有前景，中国开发者现状与技术趋势究竟是什么样？快来参与「2020 中国开发者大调查」，更有丰富奖品送不停！
扫一扫
1464
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
