最好的网站代运营公司,女装网站源码 带支付接口,重庆付费网站推广,2018年企业网站优化如何做埋点日志解决方案——GolangGinSarama VS JavaSpringCloudGatewayReactorKafka
之前我就写过几篇OpenRestylua-kafka-client将埋点数据写入Kafka的文章#xff0c;如下#xff1a;
Lua将Nginx请求数据写入Kafka——埋点日志解决方案
python定时任务执行shell脚本切割Nginx…埋点日志解决方案——GolangGinSarama VS JavaSpringCloudGatewayReactorKafka
之前我就写过几篇OpenRestylua-kafka-client将埋点数据写入Kafka的文章如下
Lua将Nginx请求数据写入Kafka——埋点日志解决方案
python定时任务执行shell脚本切割Nginx日志-慎用
nginxlua写入kafka报buffered messages send to kafka err: not found broker
关于OpenRestydoujiang24/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
这个项目本来的架构式OpenRestyApache Flumed是不是可以还原到这个架构把OpenResty中的组件后置到Flumed中这个也被否决的原因有以下几点
如果把OpenResty和Flumed部署到同一个容器中因为公司标准的监控只能监控其中一个进程如果某个进程挂了可能无法监测到这个问题在之前遇到过一个容器内起了一个OpenResty和5个Flumed进程其中某个Flumed进程挂了好久才知道如果OpenResty和Flumed分开部署在不同的容器中需要挂载网络磁盘这个网络磁盘并不可靠且会受网路带宽限制性能较差这个思路还有个问题就是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
结论
OpenRestylua实现的测试结果是 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)}
}
