云原生时代,Java还是Go?

Java曾经著名的座右铭:"一次编写,到处运行",已经很过时了,因为现在我们只想在容器里运行代码。在容器里,一个 "Just in time "的编译器意义不大。

出于这个原因,可能为了更好地适应计算,Java生态系统正处于转型之中。Oracle 的GraalVm允许将字节码编译成Linux可执行文件(ELF),而Rad Heat的Quarkus以及其他框架,则立志让响应式服务这件事变得更简单。Quarkus以Netty和Vertx.x为核心,可以用来构建非常高效的响应式Web服务。

云原生时代,Java还是Go?



Java编译成可执行二进制文件,以毫秒级的速度启动,内存占用很小。这样就可以利用Java生态系统,甚至可以用其他JVM语言(如Scala和Kotlin)编写。你可以用online项目生成器玩玩Quarkus,或者用maven插件在本地生成一个项目。

而Golang则是为云而生的,在容器中运行时,没有遗留负担。它被认为是云端的编程语言。生成的二进制可执行文件很小,快速启动,内存占用也很小,而且这是从Go诞生之初就具备的特性。Golang的流行对 Java 世界形成了严峻的挑战。

Java有机会吗,也许只有时间才会告诉我们最终答案。然而,出于好奇,我想从性能和开发体验方面比较一下 Java 和 Golang 的云原生服务。

在这篇文章中,我将使用两种语言来写同样的服务。比较它们的CPU使用率、RAM、延迟和运行速度。这些服务将在容器中启动,资源分配相同,使用ab来测试

对于我的案例来说,这是一个 "足够好 "的基准,因为我不假设找到最好/最差的基准结果,而是在同一环境下执行运行两个基准测试进行比较。


场景

这两个服务将连接到在另一个容器中运行的MySQL数据库,有一个表和三行数据

云原生时代,Java还是Go?



每一个服务都会获取所有记录,将它们转化为对象,然后输出JSON数组。

ab将发出10K请求,并发级别为100,quarkus JVM版本运行两次(用于测试 "冷"/"暖 "JVM)。

云原生时代,Java还是Go?


Go语言版本

Go语言版本使用gin框架。

# the service

package main


import (

"database/sql"

"fmt"

"github.com/gin-gonic/gin"

_ "github.com/go-sql-driver/mysql"

"net/http"

)


type Fruit struct {

Id int `json:"id"`

Name string `json:"name"`

}


var con *sql.DB


func init(){

//opening a mysql connection pool with another container

db, err := sql.Open("mysql", "root:password@tcp(host.docker.internal:3306)/payments")

if err != nil {

panic("failed to open a mysql connection")

}

con = db

}


func main() {

r := gin.Default()

r.GET("/fruits", fruits)

r.Run() //server up on 8080

}


// THE REQUEST HANDLER

func fruits(c *gin.Context) {

fruits := getFruits()

c.JSON(http.StatusOK, fruits)

}


func getFruits() []Fruit {

rows, _ := con.Query("SELECT * FROM fruits")

fruits := []Fruit{}

for rows.Next() {

var r Fruit

rows.Scan(&r.Id, &r.Name)

fruits = append(fruits, r)

}

return fruits

}

Golang的MySQL驱动的使用go-sql-driver。
golang的代码风格是非常明确的。
一种一切都在眼前态度。
主函数启动服务器配置请求处理程序,打开DB连接。


编译本地可执行文件

云原生时代,Java还是Go?

Kotlin版本

package org.acme

import io.vertx.core.json.JsonArray

import io.vertx.core.json.JsonObject

import io.vertx.mutiny.mysqlclient.MySQLPool

import io.vertx.mutiny.sqlclient.Row

import io.vertx.mutiny.sqlclient.RowSet

import java.util.concurrent.CompletionStage

import javax.inject.Inject

import javax.ws.rs.GET

import javax.ws.rs.Path

import javax.ws.rs.Produces

import javax.ws.rs.core.MediaType


@Path("/fruits")

class FruitResource {

@field:Inject

lateinit var client: MySQLPool



@GET

@Produces(MediaType.APPLICATION_JSON)

fun listFruits(): CompletionStage<JsonArray> {

return client.query("SELECT * FROM fruits").execute()

.map { rows: RowSet<Row> ->

rows.fold(JsonArray()) { array, row ->

array.add(JsonObject()

.put("id", row.getLong("id"))

.put("name", row.getString("name")))

}

}.subscribeAsCompletionStage()

}

}

数据库连接使用Quarkus React Mysql 扩展。

云原生时代,Java还是Go?



与Go版本相比,代码有很大不同,比如CDI依赖注入,使用javax注释的声明式路由,自动配置解析,以及数据源/连接创建/服务器引导。这是使用框架的代价,它为你完成了繁重的工作,并决定了做事方式。不过,它比go版本代码要简短很多。

这里使用Netty响应式web服务器,由Vert.x多事件循环包装,还有一个Vert.x响应式MySQL驱动,这样可以用一个线程处理多个DB连接。

另外,我可以使用Kotlin的集合库的fold函数,这种函数还没有通用的Go版本。

编译Java版本的可执行文件

云原生时代,Java还是Go?



我已经弄清楚构建过程中发生了什么,其核心是SubstrateVM。它被设计在AOT过程中的可嵌入虚拟机,它会链接到我们的代码,并作为一个单元进行编译。然而根据Oracle的说法,SubstrateVM的优化比HotSpot Vm少,垃圾收集器也比较简单。

该AOT编译器被称为 "Graal",它是语言不相关的。java字节码需要被翻译成一种中间表示法(Truffle语言)。这在这篇文章【1】中可以找到关于Graal和Truffle的相关论述。

构建一个 Java 本地可执行文件看起来更复杂,编译得更慢,它产生的二进制文件几乎是Go版本两倍大小。然而一个35M的可执行二进制文件和Java FatJar相比,还是小D多了。35MB甚至可以让你使用aws lambda运行。

压力测试

我在本机运行所有测试,设置如下。

  • MacBook Pro(15英寸,2017年

  • 2
    .9 GHz英特尔酷睿i7(8个核心)。

  • 16 GB 2133 MHz LPDDR3

使用cAdvisor的工具来监控容器的统计数据。

场景


  • Quarkus JVM hotspot

  • Quarkus Java native 

  • Golang

上述的每种情况都在以下三种配置上测试

  • 100MB / 0.5 CPU | 200MB / 1 CPU | 300MB / 2 CPU

我主要关注:

  • cpu/ram利用率(多核的利用率)

  • cpu/ram峰值

  • cpu/ram空余

  • 启动时间

  • 响应延迟avg/max

  • 吞吐量(每秒请求数)

测试结果

云原生时代,Java还是Go?



看起来Quarkus已经为生产环境做好准备了,它允许简单的JVM/原生发布/开发 模式,并允许在本地运行原生测试。只要你不使用反射或JNI,根据GraalVM的配置就是可行的。否则,你将不得不自己配置graal编译器,然而现在也有解决方案。

延迟和吞吐量

Golang 和原生 Java 的测试结果比较接近,虽然平均来说 Golang 版本的测试结果略好一些。不过,Java Native版本的测试结果更稳定。Golang服务有时在1.25μs内完成响应,也有一部分需要7s才能完成。

"预热 "后的JVM版本结果也不差,但比Native或Go版本稍逊一筹。

CPU利用率

使用0.5核的时候,Go和native-java在负载下似乎都表现不佳,而用2核启动时,也没有明显改善。这可能是因为工作负载的瓶颈是IO。或者是因为gin/Netty的默认配置没有考虑到多核的问题。

而JVM版本则利用了所有给定的核心,并在各个维度上提升了性能。

内存使用率

在压力下,Java native 使用40MB,Golang 使用24MB。两种情况下都还不错,虽然Golang版本使用的内存几乎少了一倍。

JVM使用了140MB。和Quarkus官方的统计完全一样。对于JVM来说还不错,但比Golang版本多了近6倍。

启动时间

Golang和cloud-native java都能立即启动,然而JVM版本需要几秒钟(取决于分配的CPU),并且在启动时产生CPU峰值。如果配置不当,会导致k8s HPA发飙,并增加pods。

开发体验

这与其说是一个实际问题,不如说是一个宗教问题。Quarkus 使用了在 Java 世界中很常见的抽象(比如基于注解的DI)。它为你启动服务并创建连接池。它可以使用丰富的集合标准库和generics。然而,这可能感觉有点像黑魔法,一旦有些组件不工作,你会感觉很无助。此外,将 Java 代码编译成原生二进制并不是那么简单,有一些限制和注意事项是你必须知道的,并非每个Java库都能兼容原生编译。一旦使用一个不兼容的库(比如Guice),你就需要自己配置Graal VM。

Quarkus 和 Graal VM "相对 "较新。所以可能会有一些问题。但由于双模式(JVM或原生)。在原生版本的某些组件停止工作的情况下,总是有一个后备方案,这对任何新问题来说都是很好的变通方法。

另一方面,Golang 在成立10年后才承认它需要generics。而且它肯定不喜欢框架使用很多魔法操作。这在很多方面既是好事也是坏事。此外,尽管 Go 社区做的非常好,然而可用的工具和库还是相对较少。然而它的编译和构建过程更快/更简单。而且兼容每个Golang的包,没有java-native平台带来的限制。

结论

Java已经为云原生做好了准备,Golang并没有大幅度领先。相信未来Cloud Native Java会被大规模使用。


https://medium.com/swlh/cloud-native-java-vs-golang-2a72c0531b05

译者注:翻译过程去掉了中间关于测试过程记录,因为测试结果在表格中已经记录了,测试的细节过于冗长。

活动预告

云原生时代,Java还是Go?

GIAC 全球互联网架构大会 2020 将于 8 月 14 – 15 日在深圳举行

,本届 GIAC 议题共设置有 24 个专题,覆盖各类架构热点领域,每个主题由业内知名架构师、技术负责人等专家担任出品人,负责议题选取和质量把控。
本届 GIAC 专场包含 Java 专场和 Go 专场(彩蛋:来自红帽子的讲师将会深入介绍本文中使用的 
Quarkus


,对本次大会感兴趣的同学,点击阅读原文可查看 GIAC 详细日程。

参考阅读:

  • 如何保留优秀的程序员

  • 如何低成本的完成一个副业项目

  • WebRTC,音视频会议底层支撑技术解读

  • Slack的512宕机故障分析:负载均衡策略的失误

  • 双子座(Gemini)协议:Web 协议最简单的一种替换

  • 十年以上程序员才懂的一些 coding 心得

本文由高可用架构翻译,技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。


高可用架构


改变互联网的构建方式



云原生时代,Java还是Go?


长按二维码 关注「高可用架构」公众号

原文 

http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=2653552714&idx=1&sn=f8f32e843b08a4eb0daec398273477a2

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 云原生时代,Java还是Go?

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址