埋点日志解决方案——Golang+Gin+Sarama VS Java+SpringCloudGateway+ReactorKafka

这篇具有很好参考价值的文章主要介绍了埋点日志解决方案——Golang+Gin+Sarama VS Java+SpringCloudGateway+ReactorKafka。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

埋点日志最终解决方案——Golang+Gin+Sarama VS Java+SpringWebFlux+ReactorKafka

之前我就写过几篇OpenResty+lua-kafka-client将埋点数据写入Kafka的文章,如下:

Lua将Nginx请求数据写入Kafka——埋点日志解决方案

python定时任务执行shell脚本切割Nginx日志-慎用

nginx+lua写入kafka报buffered messages send to kafka err: not found broker

关于OpenResty+doujiang24/lua-resty-kafka写入kafka故障转移模拟测试

以上一步一个坑,有些是自己能力不够踩的,有些是为了解决某个问题踩的,最后终于消停的一阵。但又出现新问题了,这次问题没那么紧急,但比较重要。
按照一般的剧本,上面的坑都踩完,基本上也就不会怎么去改这个服务,但新的问题还是出现了,就是容器化部署基础镜像要升级,从原来的debian10升级成了debian11,当然这是大版本,小版本几乎没周都会升级,升级时也不会通知项目组测试,运维直接升。在debian10升级debian11的时候,出现了一个问题细思极恐,就是zlib升级其中一个方法签名变了,导致我们lua脚本报错了,我们发现了这个问题,由此引出来一个担忧:运维升级小版本的时候会不会升级到某个我们用到的运行库导致线上出问题。评估下来发现非常有可能,因为运维升级镜像是基于一个镜像扫描软件,这个软件经常会扫描出诸如openssl这种组件的问题,要求运维在一个月内升级完成。这就很有可能影响到我们。并且,我们在升级kafka server的时候发现doujiang24出品的kafka-client很难像社区一样保持活跃更新,支持一些kafka新特性,并且有问题也难以求助(虽然上次得到他本人的回复,但一个人总比一群人回复问题滞后一些)。

解决思路

思路1

运维升级的时候通知到对操作系统组件敏感的我们,由我们评估是否需要跳过本次升级。这个比较难判断,因为我们项目组也无法精确的判断哪些组件一定会影响到我们,考虑不使用

思路2

将底层可能影响我们的组件进行后置,比如gzip和aes,放在kafka后面的flink去做,而不是在Nginx这里就处理掉。这个思路能避免底层升级带来的大部分影响,但是kafka驱动升级问题无法避免,考虑不使用

思路3

我们还有其它服务都是用Java做的,正式因为有JVM这一层的存在,我们才不怕操作系统的升级,是不是可以用Java实现,从而避免此问题。这个思路能解决上面的担忧,但是性能需要做测试,即使用NIO,想要达到目前的TPS,还是需要一定资源的,因为OpenResty和Java,达到同样的TPS,内存使用量差距还是很大的。这个思路保留,做进一步测试。

思路4

可不可以保持低资源高性能,又用一个中间层屏蔽操作系统组件升级带来的影响呢?这时我想到了golang。这个思路保留,做进一步测试。

思路5

这个项目本来的架构式OpenResty+Apache Flumed,是不是可以还原到这个架构,把OpenResty中的组件后置到Flumed中?这个也被否决的,原因有以下几点:

  1. 如果把OpenResty和Flumed部署到同一个容器中,因为公司标准的监控只能监控其中一个进程,如果某个进程挂了,可能无法监测到,这个问题在之前遇到过,一个容器内起了一个OpenResty和5个Flumed进程,其中某个Flumed进程挂了好久才知道
  2. 如果OpenResty和Flumed分开部署,在不同的容器中,需要挂载网络磁盘,这个网络磁盘并不可靠且会受网路带宽限制,性能较差
  3. 这个思路还有个问题就是Flumed设置多少条数据进行保存读取位点,设置的大了,容器重启会丢数据,设置小了性能不够,找这个平衡点要耗费大量的时间和资源
    这个思路因为OpenResty和Flumed在一个容器和不在一个容器都有一些问题,考虑不使用

尝试

尝试golang实现
go 1.20.10
gin 1.9.1
sarama 1.41.3

我花了几天的时间将其实现,初步性能测试结果如下:
1个CPU核心,1G内存,100并发,每个请求发5个埋点,TPS是731
最终CPU使用率47%,内存使用0.93G
本思路一开始和架构师讨论的时候只是说理论上可行,尝试一下,但谁心里都没底。在收集资料的时候偶然遇到了知乎大佬又拍云的文章【实战分享】使用 Go 重构流式日志网关,有此思路的成功上线的先例,信心大增。

尝试Java实现
Spring Boot 3.x(SpringWebFlux版本非SpringMVC版本)
Reactor Kafka 2.x(主要是和kakfa-server对应)

1个CPU核心,2G内存,100并发,每个请求5个埋点,TPS是430
最终CPU使用率60%,内存使用1.2G

结论

OpenResty+lua实现的测试结果是
1个CPU核心,1G内存,100并发,每个请求5个埋点,TPS是421
最终CPU使用率60%,内存使用0.6G

根据OpenResty方案来看,Golang和Java实现差距不是特别大,Golang展现的明显的性能优势,但是公司对Golang项目的配套做的并不好,比如实时监控,基础镜像,Golang工程师等。对Java项目比较齐全。目前初步综合考量两个项目均进入UAT环境使用专用压测机进行压测。

压完我再来补充结果。

-----------------------------------20231101分割线 start-----------------------------------
补充测试结果:
1C1G 10w数据

并发数 TPS-Java实现 TPS-Go实现 CPU使用率-Java实现 CPU使用率-Go实现 内存-Java实现 内存-Go实现
100-首次 706 1016 峰值100% 峰值100% <500M <35M
100-二次 1021 1015 峰值100% 峰值100% <500M <35M
50 954 933 峰值90% 峰值90% <500M <30M
75 1004 973 峰值84% 峰值90% <500M <30M

总的来看TPS差距不大,CPU使用率上Go的略高,内存上Go实现比Java实现少一个数量级,确实省内存。
综合考虑编排发布,公司内部的技术栈深度,监控,日志等周边配套,我们选了Java实现。
如果内存资源比较紧张,或者有Golang的技术深度,可以选择Golang的实现。
如果内存资源尚可,又是以Java为主的技术栈和周边配套,可以选择Java的实现。
-----------------------------------20231101分割线 end-----------------------------------

以下log一下Sarama向Kafka发消息代码:文章来源地址https://www.toymoban.com/news/detail-716699.html

var KafkaProduce sarama.AsyncProducer

func InitKafkaConfig() error {
	config := sarama.NewConfig()
	// 配置
	// 等待服务器成功后的响应
	config.Producer.RequiredAcks = sarama.WaitForLocal
	// 随机向partition发送消息
	config.Producer.Partitioner = sarama.NewRandomPartitioner
	// 是否等待成功和失败后的响应,只有上面的RequireAcks设置不是NoReponse这里才有用
	config.Producer.Return.Successes = true
	config.Producer.Return.Errors = true
	// KafkaClientIpList是[]string类型 值为kafka地址+端口号 一般是3个
	client, err := sarama.NewClient(KafkaClientIpList, config)
	if err != nil {
		return err
	}

	producer, err := sarama.NewAsyncProducerFromClient(client)
	if err != nil {
		return err
	}
	//这个一定要有,不然kafka消息发上一定数量直接就发不动了 
	//原因是你往 KafkaProduce.Input()发消息 会存在本地 不会真正发送到kafka
	//本地开的内存空间用完了 就卡住了
	go func() {
		for {
			select {
			case _ = <-producer.Successes():
			case er := <-producer.Errors():
				if er != nil {
					AccessLogger.Errorf("Produced message failure: %s", er)
				}
			}
		}
	}()
	KafkaProduce = producer
	return nil
}

func DestroyKafkaProducer() {
	if KafkaProduce != nil {
		KafkaProduce.Close()
	}
}

//消息发送
func SendKafkaAsyncMessage(msg string, topic string) {

	//写入kafka
	KafkaProduce.Input() <- &sarama.ProducerMessage{Topic: topic, Key: nil, Value: sarama.StringEncoder(msg)}
}

到了这里,关于埋点日志解决方案——Golang+Gin+Sarama VS Java+SpringCloudGateway+ReactorKafka的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • VS2022 全局查找 整个解决方案失效

    问题现象: 在VS2022中 Ctrl+F 整个解决方案中无法查找到,但是在当前文档可以查找到。VS2015 VS2017 VS2019均可以全局查找到。 解决方案: 网上查询过程中尝试了3种方案: 重启 VS2022、重启Windows ; 删除解决方案所在文件目录的 .vs 文件夹; 删除 \\\"【VS2022安装目录】C

    2024年02月11日
    浏览(44)
  • VS解决方案、命名空间和项目的关系

    ∥例二 /∥在脚本前面输出了一些字符?php namespace Article;? 为什么要说第一个命名空间呢?因为同一脚本文件中可以创建多个命名空间。 下面我创建了两个命名空间,顺便为这两个空间各自添加了一个Comment类元素:复制代码代 码如下:?php /∥创建一个名为\\\'Article\\\'的命名空间

    2024年02月05日
    浏览(32)
  • 在CSDN学Golang场景化解决方案(微服务架构设计)

    在Golang微服务架构设计中,聚合器(Aggregator)微服务设计模式是一种常见的应用程序体系结构模式。该模式旨在简化客户端与后端微服务之间的通信,并支持更高级别的操作,例如聚合多个后端服务的数据。以下是一个简单的示例: 首先定义一个聚合器微服务: 在main函数中

    2024年02月14日
    浏览(36)
  • vs code调试rust乱码问题解决方案

    在terminal中 用chcp 65001 修改一下字符集,就行了。有的博主推荐 修改 区域中的设置,这会引来很大的问题。千万不要修改如下设置:

    2024年02月09日
    浏览(40)
  • 一种轻量级日志采集解决方案

    前言 目前各大公司生产部署很多都是采用的集群+微服务的部署方式,如果让日志散落在各个主机上,查询起来会非常的困难,所以目前我了解到的都是采用的日志中心来统一收集管控日志,日志中心的实现方案大多基于ELK(即Elasticsearch、Logstash和Kibana三个开源软件的缩写),

    2024年02月07日
    浏览(103)
  • VS2013+QT5.5 中文乱码问题 解决方案

    最近使用VS2013+QT5.5 创建了一个项目,它的菜单是由代码创建的、   发现运行之后全部是乱码

    2024年02月13日
    浏览(43)
  • IDEA 控制台日志中文乱码解决方案

    老白新学JAVA,初用IDEA,控制台打印中文总是乱码,网上找了好多解决方法,都不好用,下面记录解决过程。 1.修改idea64.exe.vmoptions ,打开最后一行增加如下代码 idea快捷方式右键-属性-打开文件所有位置,找到idea的安装位置 2.设置IDEA编码格式, 依次打开file-setting-editor-file e

    2023年04月08日
    浏览(60)
  • VS2022迁移VS2019项目遇到的.Net Framework 引用程序集问题解决方案

    在GitHub上发现TrafficMonitor的开源代码,想要自己过一遍这个项目 在VS2022上面打开出现了MSB3644错误,打开微软 “找不到项目所请求 .NET 版本的 .NET 引用程序集时,会发生此错误。 发生此问题的原因可能是项目文件存在问题,它所请求的版本无法识别或未安装;也可能是安装问

    2024年02月06日
    浏览(94)
  • 在CSDN学Golang场景化解决方案(OAuth2.0授权登录)

    OAuth 2.0 是一种用于授权的开放标准,可以让用户授权第三方应用程序访问他们存储在另一个服务提供商上的资源,例如图片、文本等。下面是 OAuth 2.0 协议的流程: 第三方应用程序向认证服务器请求授权。 认证服务器验证用户身份并生成一个访问令牌。 第三方应用程序使用

    2024年02月15日
    浏览(35)
  • SQL Server 事务日志文件过大 解决方案

    事务日志文件(Transaction Log File)是用来记录数据库更新情况的文件,扩展名为ldf。当出现以下情况时,就会报“ 事务日志已满 ”的错误: 日志文件没有设置了自动增长,当记录超过初始大小; 日志文件设置了自动增长,“最大文件大小”设置了具体的大小(如2000M),当

    2024年02月10日
    浏览(57)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包