近期遇到一些技术问题，记录如下：
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、批量操作要用特殊处理方式，没事别刷库