共计 5251 个字符，预计需要花费 14 分钟才能阅读完成。
本文章转自：乐字节文章
次要解说：Java 微服务
获取更多 Java 相干常识能够关注公众号《乐字节》发送：999
背景介绍
咱们心愿通过试验理解 Java 微服务在运行速度上是否达到 Go 微服务的程度。目前，软件行业普遍认为 Java 曾经过于古老、迟缓且无聊。而 Go 则成了疾速、簇新以及酷炫的代名词。真是这样吗？咱们想从数据的角度看看这样的印象是否站得住脚。
咱们心愿建设一个偏心的测试，因而创立了一项非常简单的微服务，其中不含内部依赖项（例如数据库），而且代码门路十分短（仅解决字符串）。咱们在其中蕴含有指标及日志记录，因为仿佛所有微服务都或多或少蕴含这些内容。另外，咱们应用了小型、轻量化的框架（Helidon for Java 以及 Go-Kit for Go），两袖清风尝试了 Java 的纯 JAX-RS。咱们也尝试了不同版本的 Java 与不同 JVM。咱们对堆大小及垃圾收集机制做出根本调整，并在测试运行前对微服务进行了预热。
2Java 的倒退历史
Java 由 Sun Microsystems 公司开发，后被甲骨文所收买。其 1.0 版本公布于 1996 年，目前的最新版本是 2020 年的 Java 15。Java 以后的次要设计指标，在于实现 Java 虚拟机及字节码的可移植性，外加带有垃圾回收的内存管理机制。时至今日，Java 作为一种开源语言仍是寰球最受欢迎的语言选项之一（依据 StackOverflow 及 TIOBE 等起源）。
上面来聊聊“Java 问题”。人们对于它速度迟缓的印象其实更多是种固有观点，而不再适应当下的事实。现在的 Java 甚至领有不少性能敏感区，包含存储对象数据堆、用于治理堆的垃圾收集器，外加准时化（JIT）编译器。
多年以来，Java 曾先后应用多种不同的垃圾收集算法，包含串行、并行、并发标记 / 革除、G1 以及最新的 ZGC 垃圾收集器。古代垃圾收集器旨在尽可能减少垃圾收集造成的暂停时长。
甲骨文实验室开发出一款名为 GraalVM 的 Java 虚拟机，其应用 Java 编写而成，具备新的编译器外加一系列令人兴奋的新性能，包含能够将 Java 字节码转换为无需 Java 虚拟机即可运行的原生镜像等。
3Go 的倒退历史
Go 语言由谷歌的 Robert Griesemer、Rob Pike 以及 Ken Thomson 开发而成。他们几位也是 UNIX、B、C、Plan9 以及 UNIX 视窗零碎等我的项目的次要贡献者。作为一种开源语言，Go 的 1.0 版本公布于 2012 年，2020 年最新版本为 1.15。Go 语言的本体、采纳速度以及工具生态系统的倒退都相当迅猛。
Go 语言受到 C、Python、JavaScript 以及 C++ 的影响，曾经成为一种现实的高性能网络与多解决语言。
截至咱们公布主题演讲时，StackOverflow 上共有 27872 个带有“Go”标签的问题，Java 则为 1702730 个。
Go 是一种动态类型的编译语言，其语法相似于 C，且领有内存平安、垃圾回收、结构化类型以及 CSP 款式并发（通信程序过程）等性能个性。Go 还应用名为 goroutine 的轻量级过程（并非操作系统线程），外加各过程间用于通信的通道（类型化，FIFO）。Go 语言不提供竞态条件爱护。
Go 是泛滥 CNCF 我的项目的首选语言，例如 Kubernetes、Istio、Prometheus 以及 Grafana 等皆是由 Go 语言编写而成（或者大部分是）。
Go 语言在设计上强调疾速构建与疾速执行。到底是两个空格还是四个空格？Go 语言示意不必麻烦，无所谓。
与 Java 相比，我将集体领会到的 Go 语言劣势整顿如下：
• 更易于实现函数模式，例如复合、纯函数、不可变状态等。
• 样板代码少得多（但主观上依然太多）。
• Go 语言仍处于生命周期晚期，因而没什么向下兼容压力——改良路线较为平坦。
• Go 代码可编译为原生动态链接的二进制文件——无虚拟机层——二进制文件中蕴含程序运行所须要的所有，因而更适宜“从零开始”的容器。
• 体积更小、启动速度快、执行速度快。
• 无 OOP、继承、泛型、断言、指针算术。
• 括号较少，例如能够实现为 if x > 3 {whatever}
• 强制执行，没有循环依赖性，不存在未应用的变量或导入，没有隐式类型转换。
但 Go 当然也不完满。与 Java 相比，我认为 Go 存在以下问题：
• 工具生态系统还不成熟，特地是依赖项治理方面虽有多种抉择，但还都不完满。在非开源开发方面，Go 模块在依赖项治理上劣势显著，但因为存在某些兼容性问题，其采用率仍不算特地高。
• 构建具备新的 / 更新依赖项的代码时十分迟缓（例如 Maven 著称的「下载互联网」问题）。
• 导入会将代码绑定至 repo，导致代码移动十分艰难。
• IDE 非常适合编程、文档查找与主动补全等性能，但却难以进行调试及概要剖析等。
• 指针！我认为二十一世纪之前就能够辞别这货色了，但 Go 外面还有！好在至多曾经没有指针算法了。
• 没有 Java 那样的 try/catch 异样（最终总是要用到 if err != nil），也没有列表、映射函数等函数格调的原语。
• 某些根本算法依然缺失，所以用户往往只能自行编写。最近我就编写了一些代码，用 sloe 对两个字符串（列表）进行比拟以及转换。在函数语言中，咱们齐全能够应用 map 等内置算法实现。
• 没有动静链接！如果要在动态链接代码当中应用 GPL 等许可，就会很不不便。
• 用于调整执行、垃圾收集、概要剖析或者优化算法的选项很少。Java 领有数百种垃圾收集调整选项，相比之下，Go 只有一项。
4 负载测试方法
咱们应用 JMeter 进行负载测试。测试屡次调用服务，并收集对于响应工夫、吞吐量（每秒事务）以及内存应用状况的数据。在 Go 方面，咱们次要收集常驻集大小，Java 方面则次要跟踪原生内存。
在多项测试中，咱们都将 JMeter 与被测应用程序搁置在同一台计算机上运行。通过比照，咱们发现在其余机器上运行 JMeter 简直不会对后果造成任何影响。后续在将应用程序部署到 Kubernetes 中时，咱们会思考将 JMeter 运行在集群之外的近程计算机之上。
在进行测试之前，咱们应用 1000 项服务调用对应用程序进行了预热。
5 首轮测试
在第一轮测试中，咱们在小型机器上运行测试，搭载了 2.5 GHz 双核英特尔酷睿 i7 的笔记本电脑，具备 16 GB 内存并运行 MacOS。咱们运行了 100 个线程，每个线程 10000 个循环，再额定加个 10 秒的启动工夫。Java 利用程序运行在 JDK 11 与 Helidon 2.0.1 之上。Go 应用程序则应用 Go 1.13.3 进行编译。
测试后果如下：
咱们发表，Go 成为首轮测试的获胜者！
以下为依据这些后果得出的察看论断：
• 日志记录仿佛是影响性能的次要问题，特地是 java.util.logging。因而，咱们在启用与禁用日志记录两种条件下进行了测试。咱们还留神到，Go 应用程序性能次要受到日志记录的影响。
• 即便对于如此简略的小型应用程序，Java 版本的内存占用量也显著更大。
• 预热对 JVM 产生了很大影响——咱们晓得 JVM 在运行过程中会进行优化，因而预热对 Java 应用程序特地重要。
• 在此测试中，咱们还比拟了不同的执行模型——Go 应用程序被编译为原生可执行二进制文件，而 Java 应用程序被编译为字节码，而后虚拟机上运行。咱们还决定引入 GraalVM 原生镜像，保障 Java 应用程序的执行环境更靠近 Go 应用程序。
6GraalVM 原生镜像
GraalVM 提供原生镜像性能，使您可能应用 Java 应用程序并在本质上将其编译为原生可执行代码。依据 GraalVM 我的项目网站的介绍：
该可执行文件蕴含应用程序类、依赖项中的类、运行时库类以及 JDK 中的动态链接原生代码。其并非运行在 Java 虚拟机之上，而是蕴含必要组件，例如来自不同运行时零碎（也被称为「基层虚拟机」）的内存治理、线程调度等性能。基层虚拟机代表的是各运行时组件（例如反优化器、垃圾收集器、线程调度等）。
在增加 GraalVM 原生镜像（原生镜像由 GraalVM EE 20.1.1——JDK 11 构建而成）之后，首轮测试后果如下：
在这种状况下，与运行在 JVM 上的应用程序相比，咱们发现应用 GraalVM 原生镜像并不会在吞吐量或者响应工夫等层面带来任何实质性的改善，但内存占用量的确有所缩小。
以下是测试期间的响应工夫图表：
首轮响应工夫图
请留神，在所有三种 Java 变体当中，第一批申请的响应工夫要长得多（蓝线相较于左轴的高度）而且在各项测试中，咱们还看到一些峰值，其可能是由垃圾收集或优化所引起。
7 第二轮测试
接下来，咱们决定在更大的计算机上运行测试。在本轮中，咱们应用台具备 36 个外围（每外围双线程）、256 GB 内存的计算机，并配合 Oracle Linux 7.8 操作系统。
与第一轮一样，咱们依然应用 100 个线程、每线程 10000 个循环，10 秒启动工夫以及雷同版本的 Go、Java、Helidon 以及 GraalVM。
上面来看后果：
咱们发表，GraalVM 原生镜像成为第二轮测试的赢家！
上面来看本轮测试的响应工夫图：
启用日志记录，但未经预热的测试运行响应工夫
不应用日志记录也未经预热的测试运行响应工夫
通过预热，但未应用日志记录的测试运行响应工夫
第二轮的察看后果：
• Java 变体在本轮测试中的性能体现大幅晋升，而且在不应用日志记录的状况下性能远优于 Go。
• 与 Go 相比，Java 仿佛更善于应用硬件上的多个外围与执行线程——这是因为 Go 自身次要作为零碎及网络编程语言存在，而且倒退周期绝对较短，因而在成熟度及优化程度上不迭 Java 也很失常。
• 乏味的是，Java 诞生之时多外围处理器并不常见，而 Go 诞生时多核处理器曾经成为行业标准。
• 具体来看，Java 仿佛胜利将日志记录移交给其余线程 / 外围，因而极大削弱了其对性能的影响。
• 本轮最佳性能来自 GraalVM 原生镜像，其均匀响应工夫为 0.25 毫秒，每秒可执行 82426 项事务；Go 的最佳后果为 1.59 毫秒外加每秒 39227 项事务，而其内存占用量比前者高出两个数量级！
• GraalVM 原生镜像变体的速度要比运行在 JVM 上的同一应用程序快 30% 到 40%。
• Java 变体的响应工夫更为稳固，但呈现的峰值更多——咱们猜想这是因为 Go 会把垃圾回收分成更多更小的批次来执行。
8 第三轮测试：Kubernetes
在第三轮中，咱们决定在 Kubernetes 集群上运行应用程序，借此模仿更为天然的微服务运行时环境。
在本轮中，咱们应用蕴含三个工作节点的 Kubernets 1.16.8 集群，每个工作节点中蕴含两个外围（各对应两个线程）、14 GB 内存以及 Oracle Linux 7.8。在某些测试中，咱们在变体上运行一个 Pod；在其余一些测试中，咱们则运行一百个 Pod。
应用程序拜访通过 Traefik 入口控制器实现，其中 JMeter 运行在 Kubernetes 集群之外。在某些测试中，咱们也会尝试应用 ClusterIP 并在集群内运行 JMeter。
与之前的测试一样，咱们应用 100 个线程、每线程 10000 个循环，外加 10 秒启动工夫。
以下是各个变体的容器大小：
• Go 11.6MB
• Java/Helidon 1.41GB
• Java/Helidon JLinked 150MB
• 原生镜像 25.2MB
以下为本轮测试后果：
响应工夫图表：
Kubernetes 测试中的响应工夫
在本轮中，能够看到 Go 有时更快，而 GraalVM 原生镜像也常常获得当先，但二者的差别很小（个别低于 5%）。
9 测试论断
纵观几轮测试与后果，咱们得出了以下论断：
• Kubernetes 仿佛没有疾速横向扩大。
• Java 仿佛比 Go 更对于利用全副可用外围 / 线程，咱们发现 Java 测试期间 CPU 的利用率更高。
• 在外围及内存容量更高的计算机上，Java 性能更好；在较小 / 性能较弱的计算机上，Go 性能更好。
• Go 的性能总体上更加统一，这可能是因为 Java 中的垃圾回收机制所致。
• 在“生产规模”计算机上，Java 的运行速度与 Go 根本相当、甚至更快一点。
• 日志记录仿佛成为 Go 及 Java 中的次要性能瓶颈。
• Java 的古代版本以及 Helidon 等新型框架在打消 / 加重 Java 长期存在的某些重大问题（例如简短、GC 性能、启动工夫等）领有良好的体现。
10 将来瞻望
通过这轮乏味的测试，咱们打算持续摸索，特地是：
• 咱们打算通过 Kubernetes 主动扩大做更多工作，包含引入更简单的微服务或更高的负载以凸显出性能上的差别。
• 咱们心愿钻研更简单的微服务、多种服务类型以及模式，察看网络如何影响性能，以及应如何对微服务网络进行调优。
• 咱们还打算深挖日志记录问题，理解解决此瓶颈的办法。
• 咱们心愿查看指标代码并比拟以后正在执行的理论指令，看看是否在代码门路中做出进一步优化。
• 咱们心愿理解 JMeter 是否在不成为瓶颈的同时产生足够多的负载，但此次测试结果表明 JMeter 并不形成影响，而是可能轻松跟上 Go 与 Java 实现的运行步调。
• 咱们打算对容器启动工夫、内存占用量等指标做出更具体的测量。
感激大家的认同与反对，小编会继续转发《乐字节》优质文章
