微服务性能调优01

近期遇到一些技术问题,记录如下:

1、kafka并发处理量上不去
数据流:
数据生产服务-》kafka-》数据消费服务
表现:
数据消费服务加了很多个实例,但总感觉多数实例不工作
原因:
分析后发现,原来开发小伙伴把所有消息都扔到了同一个topic中,而分区只有3,消费者再多这并发量也上不去啊
解决:
按不同业务,拆分topic,同时增加分区数
同时,建议把一堆操作拆分为多个步骤进行,不要都放到一个方法里全部做掉,宁可多流转几次各司其职

2、数据上报并发处理量上不去
数据流:
DB-》轮询-》HTTP提交数据到数据上报网站【ZF】
表现:
要求4小时上传60W,实际1小时上传5K
原因:
问题很多,主要有两个,一是每次只上传一条数据,二是没有做并发
解决:
一开始准备做很大的调整,但后面项目组怕把开并发把数据上报网站压挂,最后没敢使用
最后,只是改造为批量上传数据,轮询时根据id做了一下简单的并发
数据上报网站,各地接口及要求各不一样,也是各种不容易吧

3、莫名奇妙的403
数据流:
浏览器-》网关-》鉴权服务
表现:
网关偶尔返回403
原因:
一开始日志输出太少,都没有定位到哪里的问题,只能临时在网关补充了一些日志【建议加了开关,定位问题后关闭】
加日志后,发现是一段上古代码,使用信号量进行了并发控制,超出了并发就获取不到用户权限。
而这个Bug暴漏出来,据反馈,居然是升级组件导致的。
遗留系统都是坑啊。
解决:
优化鉴权服务,定位到问题,问题也就解决了

4、无法提升的微服务性能
数据流:
浏览器-》网关-》N个服务来回调用
表现:
服务性能差,有时要几十秒才返回,一堆告警邮件
原因:
微服务拆分粒度太细,形成环状调用链路
开发同学无脑调用微服务,能调用一次的,居然会循环调用N次
解决:
重构,按业务领域合并微服务,微服务数量少了60%,同时干掉环状调用链
评审,找到不合理的循环调用,抓典型,整改

5、批量导出
数据流:
浏览器-》网关-》导出服务-》DB
表现:
批量查询、批量导出性能很差,要按分钟返回的,一堆告警邮件
原因:
数据量太大,DB拉取速度慢,数据回传也慢
解决:
根据业务情况,部分批量查询功能改到只读库查询,大批量导出功能迁移到了数据中台

6、数据批量下发
数据流:
数据中台-》kafka-》数据下发接收服务
表现:
数据中台下发数据,无法更新到下游业务系统
原因:
因安全需求,上游业务系统批量刷新数据库,导致数据中台下发大量数据,数据下发服务处理不及时,积累了大量数据待处理
下游业务系统把一堆业务逻辑放到了接收服务中,处理单条业务数据要按秒计算,数据越积越多
你没想错,kafka并发上不去,和之前原因一样一样的
解决:
接收服务简化,拆分不必要的业务逻辑,服务性能提高了几百倍
优化kafka配置
制定了批量刷新数据库的相关流程,都是泪
历史数据咋处理?和上游系统沟通后,99.9%的数据不必处理,于是忽略了历史积累数据,晚上将0.1%的数据进行了重推,解决了问题

7、Kafka卡顿
数据流:
系统A-》kafka-》系统B
表现:
kafka在半夜性能下降明显,从日志上看,就是工作2分钟,卡5分钟
原因:
kafka的消费者每次取了太多消息去消费,半夜为业务高峰期,部分消费者获取消息无法及时处理完毕,导致kafka会出发rebalance,你懂的
解决:
每次少取一些数据

8、HTTPS通讯失败
数据流:
前置系统A-》云-》云上系统B
表现:
有两家用户的数据无法连通云服务,HTTPS通讯失败
原因:
前置服务的服务器器时间错误,数据包被云的安全策略直接丢弃,被当成重放攻击了
解决:
开启前置服务自动时间同步服务

9、组件升级导致服务性能下降
表现:
系统组件升级后,系统整体服务性能下降,会有部分请求阻塞5S以上
CPU、内存、IO看起来都比较正常
生产环境才有问题,测试环境下无法复现
原因:
通过打印线程信息,发现存在大量网络IO阻塞
后定位到了一个可疑的点,日志同时输出到log文件和命令行时,命令行也发送到了log文件,会有阻塞
解决:
只输出到命令行,有待观察

整体经验:
1、微服务粒度不能太细,也不能一个服务啥都干,最好按业务领域进行拆分。业务量小的领域可以适当合并,业务逻辑复杂的考虑拆分。
2、微服务也应该分层次,不要出现环状调用链路
3、日志要足够判断问题所在,太多影响性能,太少没啥用
4、中间件不能熟练配置,不要随便上生产
5、批量操作要用特殊处理方式,没事别刷库

Leave a Reply

Your email address will not be published. Required fields are marked *

*