JavaVSGo，微服务究竟谁更快？

作者 | 程序猿DD   责编 | 张文

头图 | CSDN 下载自视觉中国

Java 微服务能像 Go 微服务一样快吗&＃xff1f;这是我最近一直在思索的一个问题。

去年 8 月份的 the Oracle Groundbreakers Tour 2020 LATAM 大会上&＃xff0c;Mark Nelson 和 Peter Nagy 就做过一系列基础的的测试用以比较两者。接下来就给大家介绍下。

在程序员圈子里&＃xff0c;普遍的看法是 Java 老、慢、无聊 &＃xff0c;而 Go 是快、新、酷。

为了尽可能的进行一个相对公平的测试&＃xff0c;他们使用了一个非常简单的微服务&＃xff0c;没有外部依赖关系&＃xff08;比如数据库&＃xff09;&＃xff0c;代码路径非常短&＃xff08;只是操纵字符串&＃xff09;&＃xff0c;使用了小型的、轻量级的框架&＃xff08;Helidon for Java 和 Go 工具包 for Go&＃xff09;&＃xff0c;试验了不同版本的 Java 和不同的 jvm。

对决双雄

我们先来看下擂台两边的选手&＃xff1a;

• 身穿深色战服的选手是 JAVA

Java 是由被甲骨文收购的 Sun Microsystems 开发的。它的 1.0 版本是 1996 年发布的&＃xff0c;最新的版本是 2020 年的 Java15。主要的设计目标是 Java 虚拟机和字节码的可移植性&＃xff0c;以及带有垃圾收集的内存管理。它是全世界最流行的语言之一&＃xff0c;在开源环境下开发。

我们先看下 JAVA 的问题&＃xff0c;大家普遍认为它最大的问题就是速度慢&＃xff0c;已经慢到让人觉得不再是合理的&＃xff0c;而是更具历史意义的。不过这么多年来&＃xff0c;Java 诞生了很多不同的垃圾收集算法用来加快它运行的速度。

Oracle 实验室最近已经开发了一个新的 Java 虚拟机 GraalVM&＃xff0c;它有一个新的编译器和一些令人兴奋的新特性&＃xff0c;比如能够将 Java 字节码转换成一个本机映像&＃xff0c;可以在没有 javavm 的情况下运行等。

• 而它的对手就是年轻充满活力的 GO

GO 是由谷歌的罗伯特·格里默、罗伯·派克和肯·汤姆森创建的。他们对 UNIX、B、C、Plan9、UNIX 窗口系统等做出了重大贡献。GO 是开源的&＃xff0c;在 2012 年发布了 1.0 版本&＃xff08;比 JAVA 晚了 16 年&＃xff09;&＃xff0c;在 2020 年发布了 1.15 版本。无论是在采用方面&＃xff0c;还是在语言和工具生态系统本身方面&＃xff0c;它都在快速增长。

GO 受 C、Python、Javascript 和 C&＃43;&＃43;等多种语言的影响。被设计成高性能网络和多处理的最佳语言。

StackOverflow 有 27872 个带“Go”的问题&＃xff0c;而 Java 只有 1702730个。足见长江后浪推前浪。

Go 是一种静态类型的编译语言。它有称为 goroutines 的轻量级进程&＃xff08;这些不是 OS 线程&＃xff09;&＃xff0c;它们之间有独特的通信通道&＃xff08;类型化的&＃xff0c;FIFO&＃xff09;。Go 是许多 CNCF 项目的首选语言&＃xff0c;例如 Kubernetes、Istio、Prometheus 和 Grafana

赛前对比

从个人感觉来说&＃xff0c;Go 相比 JAVA 来说&＃xff0c;优点在于&＃xff1a;

• Go 更容易实现复合、纯函数、不变状态等功能模式。

• Go 处于生命周期的早期&＃xff0c;因此它没有向后兼容性的沉重负担—Go 仍然可以轻易打破某些限制来改进。

• Go 编译成一个本机静态链接的二进制文件-没有虚拟机层-二进制文件拥有运行程序所需的一切&＃xff0c;这对于“从头开始”的容器来说非常好。

• Go 体积小、启动快、执行快&＃xff08;目前是的&＃xff09;

• Go 没有 OOP&＃xff0c;继承&＃xff0c;泛型&＃xff0c;断言&＃xff0c;指针算法

• Go 写法上较少的括号

• Go 没有循环依赖、没有未使用的变量或导入、没有隐式类型转换的强制

• Go 样板代码少得多

缺点是&＃xff1a;

• Go 工具生态系统还不成熟&＃xff0c;尤其是依赖关系管理——有几个选项&＃xff0c;没有一个是完美的&＃xff0c;特别是对于非开源开发&＃xff1b;仍然存在兼容性挑战。

• 构建具有新的/更新的依赖项的代码非常慢&＃xff08;比如 Maven 著名的“下载Internet”问题&＃xff09;

• 导入将代码绑定到存储库&＃xff0c;这使得在存储库中移动代码成为一场噩梦。

• 调试、评测等仍然是一个挑战

• 用到了指针

• 需要实现一些基本的算法

• 没有动态链接

• 没有太多旋钮来调优执行或垃圾收集、概要文件执行或优化算法。

比赛开始

使用 JMeter 来运行负载测试。这些测试多次调用这些服务&＃xff0c;并收集有关响应时间、吞吐量&＃xff08;每秒事务数&＃xff09;和内存使用情况的数据。对于 Go&＃xff0c;收集驻留集大小&＃xff1b;对于 Java&＃xff0c;跟踪本机内存。

在测量之前&＃xff0c;使用 1000 次服务调用对应用程序进行预热。

应用程序本身的源代码以及负载测试的定义都在这个 GitHub 存储库中&＃xff1a;https://github.com/markxnelson/go-java-go

第一回合

在第一轮测试中&＃xff0c;在一台“小型”机器上进行了测试&＃xff0c;是一台 2.5GHz 双核 Intel core i7 笔记本电脑&＃xff0c;16GB 内存运行 macOS。测试运行了 100 个线程&＃xff0c;每个线程有 10000 个循环&＃xff0c;上升时间为 10 秒。Java 应用程序运行在 JDK11 和 Helidon2.0.1上。使用 Go 1.13.3 编译的 Go 应用程序。

结果如下:

可以看出&＃xff0c;第一回合是 Go 赢了&＃xff01;

JAVA 占的内存太多了&＃xff1b;预热对 JVM 有很大的影响—我们知道 JVM 在运行时会进行优化&＃xff0c;所以这是有意义的

在第一回合的基础上&＃xff0c;意犹未尽的又引入 GraalVM 映像以使 Java 应用程序的执行环境更接近于 Go 应用程序的环境&＃xff0c;添加了 GraalVM 映像测试(用  GraalVM EE 20.1.1ー JDK 11 构建的本机映像)的结果是&＃xff1a;

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

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

第二回合

在第二轮测试中&＃xff0c;使用一台更大的机器上运行测试。36 核&＃xff08;每个核两个线程&＃xff09;、256GB 内存、运行 oraclelinux7.8 的机器。

和第一轮类似&＃xff0c;使用了 100 个线程&＃xff0c;每个线程使用了 10,000 个循环&＃xff0c;10 秒的加速时间&＃xff0c;以及相同版本的 Go&＃xff0c;Java&＃xff0c;Helidon 和 GraalVM。

结果如下&＃xff1a;

这一回合是 GraalVM 映像赢了&＃xff01;

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

在这个测试中&＃xff0c;Java 变体的表现要好得多&＃xff0c;并且在没有使用 Java 日志记录的情况下&＃xff0c;它的性能大大超过了 Go。Java 似乎更能使用硬件提供的多核和执行线程&＃xff08;与 Go 相比&＃xff09;。

这一轮的最佳表现来自 GraalVM native image&＃xff0c;平均响应时间为 0.25 毫秒&＃xff0c;每秒事务数为 82426 个&＃xff0c;而 Go 的最佳结果为 1.59 毫秒和 39227 个 tps&＃xff0c;然而这是以多占用两个数量级的内存为代价的&＃xff01;

GraalVM 映像比在 jvm 上运行的同一应用程序快大约 30–40%&＃xff01;

第三回合

这次&＃xff0c;比赛在 Kubernetes 集群中运行这些应用程序&＃xff0c;这是一个更自然的微服务运行时环境。

这次使用了一个 Kubernetes 1.16.8 集群&＃xff0c;它有三个工作节点&＃xff0c;每个节点有两个内核&＃xff08;每个内核有两个执行线程&＃xff09;、14GB 的 RAM 和 oraclelinux7.8。

应用程序访问是通过 Traefik 入口控制器进行的&＃xff0c;JMeter 在 Kubernetes 集群外运行&＃xff0c;用于一些测试&＃xff0c;而对于其他测试&＃xff0c;使用 ClusterIP 并在集群中运行 JMeter。

与前面的测试一样&＃xff0c;使用了 100 个线程&＃xff0c;每个线程使用了 10,000 个循环&＃xff0c;以及 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

结果如下&＃xff1a;

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

在这一轮中&＃xff0c;我们观察到 Go 有时更快&＃xff0c;GraalVM 映像有时更快&＃xff0c;但这两者之间的差别很小(通常小于 5%)。

Java 似乎比 Go 更善于使用所有可用的内核/线程—在 Java 测试中看到了更好的 CPU 利用率。Java 性能在拥有更多内核和内存的机器上更好&＃xff0c;Go 性能在较小/功能较弱的机器上更好。在一台“生产规模”的机器上&＃xff0c;Java 很容易就和 Go 一样快&＃xff0c;或者更快。

最后

接下来会做更多的测试比赛&＃xff0c;来看一看究竟谁更好&＃xff01;

有兴趣的你也可以自己试一试&＃xff0c;记得告诉我们结果哦&＃xff01;

参考链接&＃xff1a;https://medium.com/helidon/can-java-microservices-be-as-fast-as-go-5ceb9a45d673

程序员如何避免陷入“内卷”、选择什么技术最有前景&＃xff0c;中国开发者现状与技术趋势究竟是什么样&＃xff1f;快来参与「2020 中国开发者大调查」&＃xff0c;更有丰富奖品送不停&＃xff01;

更多精彩推荐
☞突发&＃xff01;小米被美国政府“拉黑”&＃xff1b;联发科每名员工获 10 万大红包&＃xff1b;腾讯 7 款 APP 遭责令整改 | 极客头条☞放弃 PHP&＃xff0c;选择 Node.JS 的 8 个理由&＃xff01;
☞程序员求生指南&＃xff1a;告别大小周&＃xff0c;摆脱监视&＃xff0c;直奔年终奖&＃xff01;☞1.6 万亿参数你怕了吗&＃xff1f;谷歌大脑语言模型速度是 T5 速度的 7 倍☞2020 ACM Fellows 名单出炉&＃xff0c;13 名华人入选&＃xff0c;7 名来自国内&＃xff01;
☞再次被替代&＃xff1f;六成应用开发不需要程序员点分享点收藏点点赞点在看


戳”阅读原文“&＃xff0c;