关于java:Java微服务-vs-Go微服务究竟谁更强

前言

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工具生态系统还不成熟,尤其是依赖关系治理——有几个选项,没有一个是完满的,特地是对于非开源开发;依然存在兼容性挑战。
  • 构建具备新的/更新的依赖项的代码十分慢(比方Maven驰名的“下载Internet”问题)
  • 导入将代码绑定到存储库,这使得在存储库中挪动代码成为一场噩梦。
  • 调试、评测等依然是一个挑战
  • 用到了指针
  • 须要实现一些根本的算法
  • 没有动静链接
  • 没有太多旋钮来调优执行或垃圾收集、概要文件执行或优化算法。

较量开始

应用JMeter来运行负载测试。这些测试屡次调用这些服务,并收集无关响应工夫、吞吐量(每秒事务数)和内存应用状况的数据。对于Go,收集驻留集大小;对于Java,跟踪本机内存。

在测量之前,应用1000次服务调用对应用程序进行预热。

应用程序自身的源代码以及负载测试的定义都在这个GitHub存储库中:https://github.com/markxnelso…

第一回合

在第一轮测试中,在一台“小型”机器上进行了测试,是一台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/ca…

欢送关注我的公众号:程序猿DD,取得独家整顿的收费学习资源助力你的Java学习之路!另每周赠书不停哦~

【腾讯云】轻量 2核2G4M,首年65元

阿里云限时活动-云数据库 RDS MySQL  1核2G配置 1.88/月 速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据