Java微服务是否可以和Go一样快

这篇文章主要讲解了“Java微服务是否可以和Go一样快”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Java微服务是否可以和Go一样快”吧！

Java的历史

Java由Sun Microsystems开发，后来被Oracle收购。  其1.0版本于1996年发布，最新版本是2020年的Java15。主要设计目标是Java虚拟机和字节码的可移植性以及带有垃圾回收的内存管理。  它仍然是最流行的语言之一(根据StackOverflow和TIOBE之类的来源)，它是在开源中开发的。

让我们谈谈" Java问题"。

多年来，Java有许多不同的垃圾收集算法，包括串行，并行，并发标记/清除，G1和新的ZGC垃圾收集器。  现代垃圾收集器旨在最大程度地减少垃圾收集"停止世界"暂停的时间。

Oracle实验室开发了一种新的名为GraalVM的Java虚拟机，该Java虚拟机用Java编写，具有新的编译器和一些令人兴奋的新功能，例如能够将Java字节码转换为无需Java  VM即可运行的本机映像。

Go的历史

Go由Google的Robert Griesemer，Rob Pike和Ken Thomson创建。

Go受C，Python，Javascript和C的影响。 它被设计为用于高性能网络和多处理的最佳语言。

在我们演讲时，StackOverflow有27,872个被" Go"标记的问题，而Java则为1,702,730。

Go是一种静态类型的编译语言。

Go是许多CNCF项目的首选语言，例如Kubernetes，Istio，Prometheus和Grafana都(大部分)用Go编写。

它旨在具有快速的构建时间和快速的执行。

Go(与Java相比)有什么好处-根据我的经验，这是我的个人看法：

• 容易实现功能模式，例如合成，纯函数，不可变状态。

• 样板代码少得多(但仍然太多)。

• 它仍然处于生命周期的早期，因此它不具有向后兼容的沉重负担-他们仍然可以打破现状来改进它。

• 它可以编译成本地静态链接的二进制文件-无虚拟机层-二进制文件具有运行程序所需的一切，这对于" FROM scratch"容器非常有用。

• 它具有体积小，启动快和执行快的特点。

• 没有OOP，继承，泛型，断言，指针算术。

• 括号较少，例如

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

那么，Go的"问题"是什么?

• 工具生态系统还不成熟，尤其是依赖管理-有多种选择，没有一个是完美的，特别是对于非开源开发而言;

• 建立具有新/更新依赖关系的代码非常慢(例如Maven著名的"下载Internet"问题。

• 导入会将代码绑定到存储库，这使代码在噩梦中移动。

• IDE非常适合编程，文档查找，自动完成等。

• 指针!

• 没有Java风格的try / catch异常(如果err!=  nil的使用频率太高，您最终会写出来)，没有功能风格的原语，例如列表，映射函数等。

• 由于它尚不可用，您通常会最终实现一些基本算法。 最近，我写了一些代码，由sloe进行了两个字符串(列表)的比较，并进行了转换。  用一种功能语言，我本可以使用诸如map这样的内置函数来做到这一点。

• 没有动态链接! (您问"谁在乎?"。)如果您要使用带有"感染"静态链接代码的GPL许可证的代码，这可能是一个真正的问题。

• 调节执行或垃圾收集，配置文件执行或优化算法的旋钮并不多-Java具有数百种垃圾收集调整选项，而Go具有一个-启用或禁用。

负载测试方法

我们使用JMeter进行负载测试。 测试多次调用服务，并收集有关响应时间，吞吐量(每秒事务)和内存使用情况的数据。  对于Go，我们收集常驻集大小;对于Java，我们跟踪本机内存。

在许多测试中，我们将JMeter与被测应用程序在同一台计算机上运行。  如果我们在另一台机器上运行JMeter，结果似乎没有任何干扰或差异，因此可以简化设置。  当我们以后将应用程序部署到Kubernetes中时，JMeter在集群外部的远程计算机上运行。

在进行测量之前，我们使用了1,000次服务调用来预热了应用程序。

第一轮测试

在第一轮中，我们在"小型"计算机上进行了测试，在这种情况下，该计算机是2.5GHz双核Intel Core i7笔记本电脑，具有16GB  RAM，运行macOS。

结果如下：

我们宣布Go成为第一轮的获胜者!

以下是我们根据这些结果得出的观察结果：

• 日志记录似乎是主要的性能问题，尤其是java.util.logging。 因此，我们在进行日志记录和不进行日志记录的情况下都进行了测试。  我们还注意到，日志记录是Go应用程序性能好的重要因素。

• Java版本具有显著的更大的内存占用空间，即使对于如此小的简单应用程序也是如此

• 预热对JVM产生了很大的影响-我们知道JVM在运行时会进行优化，因此这很有意义

• 在此测试中，我们正在比较不同的执行模型-Go应用程序被编译为本地可执行二进制文件，而Java应用程序被编译为字节代码，然后在虚拟机上运行。

GraalVM本机映像

GraalVM具有本机映像功能，可让您采用Java应用程序并将其本质上编译为本机可执行代码。

该可执行文件包括应用程序类，其依赖项中的类，运行时库类以及JDK中的静态链接本机代码。

这是再次添加GraalVM本机图像测试(使用GraalVM EE 20.1.1-JDK 11构建的本地图像)的第一轮结果：

在这种情况下，与在JVM上运行应用程序相比，使用GraalVM本机映像没有看到吞吐量或响应时间的任何显着改善，但是内存占用空间较小。

以下是一些测试的响应时间的图表：

> Response time graphs for round one

请注意，在所有这三种Java变体中，第一个请求的响应时间要长得多(请在与左轴相对的右上方寻找那条蓝线)。

第二轮

接下来，我们决定在更大的计算机上运行测试。

与第一轮一样，我们使用了100个线程，每个线程10,000个循环，10秒的启动时间以及相同版本的Go，Java，Helidon和GraalVM。

结果如下：

我们宣布GraalVM本机映像是第二轮的赢家!

以下是这些测试的响应时间图：

> Response times for test runs with logging enabled but no warmup

> Response times for test runs with no logging and no warmup

> Response times for test runs with warmup but no logging

第二轮的一些观察：

• 在此测试中，Java变体的性能要好得多，并且在不使用日志记录的情况下，其性能要比Go好很多

• Java似乎更有能力使用硬件提供的多个内核和执行线程(与Go相比)–这是有一定道理的，因为Go旨在作为一种系统和网络编程语言，并且它是一种较年轻的语言，因此

• 有趣的是，Java是在多核处理器不常见的时候设计的，而Go是在多核处理器不是通用的时候设计的。

• 特别是，似乎Java日志记录已成功卸载到其他线程/内核，并且对性能的影响要小得多。

• 这一轮的最佳性能来自GraalVM本机映像，平均响应时间为0.25毫秒，每秒处理82,426个事务，而Go的最佳结果为1.59毫秒和39,227  tps，但这是以增加两个数量级的内存为代价的用法!

• Java变体的响应时间似乎更加一致，但是出现了更多的峰值-我们认为这意味着Go在做更多，更小的垃圾回收

第三轮-Kubernetes

在第三轮中，我们决定在Kubernetes集群中运行应用程序—您可能会说，这是微服务的更自然的运行时环境。

在这一轮中，我们使用了具有三个工作节点的Kubernetes  1.16.8集群，每个工作节点都有两个内核(每个都有两个执行线程)，14GB的RAM和Oracle Linux 7.8。  在某些测试中，我们为每个变体运行了一个Pod，在其他测试中运行了100个Pod。

应用程序访问是通过Traefik入口控制器进行的，其中JMeter在Kubernetes集群外部运行，以进行某些测试，对于其他测试，我们使用ClusterIP并在集群中运行JMeter。

与之前的测试一样，我们使用了100个线程，每个线程10,000个循环，以及10秒的启动时间。

以下是每个变体的容器大小：

• 继续11.6MB

• Java / Helidon 1.41GB

• Java / Helidon JLinked 150MB

• 本机图像25.2MB

结果如下：

以下是一些响应时间表：

> Response times from Kubernetes tests

在这一轮中，我们观察到Go有时会更快，而GraalVM本地映像有时会更快，但是两者之间的差异很小(通常小于5%)

那我们学到了什么?

我们对所有这些测试和结果进行了反思，以下是一些结论：

• Kubernetes似乎没有迅速扩展

• Java似乎比Go更擅长使用所有可用的内核/线程-我们发现Java测试期间CPU利用率更高

• 在具有更多内核和内存的机器上，Java性能更好;在较小/功能较弱的机器上，Go性能更好。

• Go的性能总体上更加一致-可能是由于Java的垃圾回收

• 在"生产规模"的计算机上，Java的运行速度与Go一样快，甚至更快

• 日志记录似乎是我们在Go和Java中遇到的主要瓶颈

• Java的现代版本以及诸如Helidon之类的新框架在消除/减少Java的一些众所周知且长期存在的问题(例如冗长程度，GC性能，启动时间等)的痛苦方面取得了长足的进步。

接下来是什么?

这是一个非常有趣的练习，我们打算继续努力，特别是：

• 我们想通过Kubernetes自动扩展做更多的工作-我们可能需要更复杂的微服务或更高的负载才能看到性能上的差异

• 我们希望研究更复杂的微服务，多种服务以及电路中断等模式，并观察网络如何影响性能以及如何调整微服务网络

• 还想看一下日志记录问题，看看该怎么做才能消除瓶颈

• 我们想看一下目标代码并比较正在执行的实际指令，看看是否可以在代码路径中做一些进一步的优化。

• 我们想知道JMeter是否可以在不成为瓶颈的情况下产生足够的负载，但是我们的测试表明这根本不是一个因素，它可以轻松跟上Go和Java实现。

• 想要对容器启动时间，内存占用量等进行更详细的测量。

感谢各位的阅读，以上就是“Java微服务是否可以和Go一样快”的内容了，经过本文的学习后，相信大家对Java微服务是否可以和Go一样快这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！