13518219792
这篇文章主要讲解了“Java微服务是否可以和Go一样快”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Java微服务是否可以和Go一样快”吧！
创新互联来电联系：18980820575，为您提供成都网站建设网页设计及定制高端网站建设服务，创新互联网页制作领域10多年，包括搬家公司等多个方面拥有丰富建站经验，选择创新互联，为企业保驾护航！
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一样快这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！
