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

本文主要是介绍埋点日志解决方案——Golang+Gin+Sarama VS Java+SpringCloudGateway+ReactorKafka,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

埋点日志解决方案——Golang+Gin+Sarama VS Java+SpringCloudGateway+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 Cloud Gateway 3.x
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环境使用专用压测机进行压测。

压完我再来补充结果。

以下log一下Sarama向Kafka发消息:

var KafkaProduce sarama.AsyncProducerfunc InitKafkaConfig() error {config := sarama.NewConfig()// 配置// 等待服务器成功后的响应config.Producer.RequiredAcks = sarama.WaitForLocal// 随机向partition发送消息config.Producer.Partitioner = sarama.NewRandomPartitioner// 是否等待成功和失败后的响应,只有上面的RequireAcks设置不是NoReponse这里才有用config.Producer.Return.Successes = trueconfig.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(producer sarama.AsyncProducer) {errors := producer.Errors()success := producer.Successes()for {select {case er := <-errors:if er != nil {log.Errorf("Produced message failure: %s", er)}case msg := <-success:log.Infof("Produced message success topic: %s", msg.Topic)}}}(producer)KafkaProduce = producerreturn nil
}func DestroyKafkaProducer() {if KafkaProduce != nil {KafkaProduce.Close()}
}//消息发送
func SendKafkaAsyncMessage(msg string, topic string) {//写入kafkaKafkaProduce.Input() <- &sarama.ProducerMessage{Topic: topic, Key: nil, Value: sarama.StringEncoder(msg)}
}

这篇关于埋点日志解决方案——Golang+Gin+Sarama VS Java+SpringCloudGateway+ReactorKafka的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/285233

相关文章

JVM 的类初始化机制

前言 当你在 Java 程序中new对象时,有没有考虑过 JVM 是如何把静态的字节码(byte code)转化为运行时对象的呢,这个问题看似简单,但清楚的同学相信也不会太多,这篇文章首先介绍 JVM 类初始化的机制,然后给出几个易出错的实例来分析,帮助大家更好理解这个知识点。 JVM 将字节码转化为运行时对象分为三个阶段,分别是:loading 、Linking、initialization

Spring Security 基于表达式的权限控制

前言 spring security 3.0已经可以使用spring el表达式来控制授权,允许在表达式中使用复杂的布尔逻辑来控制访问的权限。 常见的表达式 Spring Security可用表达式对象的基类是SecurityExpressionRoot。 表达式描述hasRole([role])用户拥有制定的角色时返回true (Spring security默认会带有ROLE_前缀),去

浅析Spring Security认证过程

类图 为了方便理解Spring Security认证流程,特意画了如下的类图,包含相关的核心认证类 概述 核心验证器 AuthenticationManager 该对象提供了认证方法的入口,接收一个Authentiaton对象作为参数; public interface AuthenticationManager {Authentication authenticate(Authenti

Spring Security--Architecture Overview

1 核心组件 这一节主要介绍一些在Spring Security中常见且核心的Java类,它们之间的依赖,构建起了整个框架。想要理解整个架构,最起码得对这些类眼熟。 1.1 SecurityContextHolder SecurityContextHolder用于存储安全上下文(security context)的信息。当前操作的用户是谁,该用户是否已经被认证,他拥有哪些角色权限…这些都被保

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明(认真看哦) AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证,则会调用 #attemptAuthentica

Spring Security 从入门到进阶系列教程

Spring Security 入门系列 《保护 Web 应用的安全》 《Spring-Security-入门(一):登录与退出》 《Spring-Security-入门(二):基于数据库验证》 《Spring-Security-入门(三):密码加密》 《Spring-Security-入门(四):自定义-Filter》 《Spring-Security-入门(五):在 Sprin

Java架构师知识体认识

源码分析 常用设计模式 Proxy代理模式Factory工厂模式Singleton单例模式Delegate委派模式Strategy策略模式Prototype原型模式Template模板模式 Spring5 beans 接口实例化代理Bean操作 Context Ioc容器设计原理及高级特性Aop设计原理Factorybean与Beanfactory Transaction 声明式事物

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

Java进阶13讲__第12讲_1/2

多线程、线程池 1.  线程概念 1.1  什么是线程 1.2  线程的好处 2.   创建线程的三种方式 注意事项 2.1  继承Thread类 2.1.1 认识  2.1.2  编码实现  package cn.hdc.oop10.Thread;import org.slf4j.Logger;import org.slf4j.LoggerFactory

JAVA智听未来一站式有声阅读平台听书系统小程序源码

智听未来,一站式有声阅读平台听书系统 🌟&nbsp;开篇:遇见未来,从“智听”开始 在这个快节奏的时代,你是否渴望在忙碌的间隙,找到一片属于自己的宁静角落?是否梦想着能随时随地,沉浸在知识的海洋,或是故事的奇幻世界里?今天,就让我带你一起探索“智听未来”——这一站式有声阅读平台听书系统,它正悄悄改变着我们的阅读方式,让未来触手可及! 📚&nbsp;第一站:海量资源,应有尽有 走进“智听