MyBatis版本升级引发的线上告警回顾及原理分析-美团技术团队.pdf

大强3008

163

15页

1次

2023-02-18

5墨值下载

2023/2/17 10:32

MyBatis版本升级引发的线上告警回顾及原理分析

https://mp.weixin.qq.com/s/sk0Kou9V727tRe5wddmDig

1/15

MyBatis版本升级引发的线上告警回顾及原理分析

总第399篇

2020年第22篇

本文从一次MyBatis版本升级引发的线上告警开始讲起，然后针对告警定位过程、源码原

理进行了深入的分析，并加入了不同版本的类比分析，最后结合实际工作做了一些经验总

结，希望能对大家的工程实践有一定的帮助。

背景

某天晚上，美团到店事业群某项系统服务正在进行常规需求的上线。因为在发布时，提示inf-bom

版本需要升级，于是我们就将inf-bom版本从1.3.9.6升级至1.4.2.1，如下图1所示：

图1 版本升级

不过，当服务上线后，开始陆续出现了一些更新系统交互日志方面的报警，这属于系统的辅助流

程，报警如下方代码所示。我们发现都是跟MyBatis相关的报警，说明在进行类型转换的时候，系

统产生了强转错误。

更新开票请求返回日志, id:{#######}, response:{{"code":XXX,"data":{"callType":3

nested execption is org.apache.ibatis.type.TypeException: Could not set param

jdbcTyp=null,resultMapId='null',jdbcTypeName='null',expression='null'}.Cause

different Jdbc Type for this parameter or a different configuration property.

凯伦 2020-06-18 20:01

原创

美团技术团队

2023/2/17 10:32

MyBatis版本升级引发的线上告警回顾及原理分析

https://mp.weixin.qq.com/s/sk0Kou9V727tRe5wddmDig

2/15

因为报警这一块代码，属于历史功能，如果失败并不会影响主流程。但在定位期间，如果频繁报

警的话，就会造成一定的干扰。因此，我们马上采取了回滚操作，将inf-bom的版本回滚至历史版

本，直至报警消失，然后再进行问题的定位和分析。以下章节就是我们对报警原因的定位及原因

详细分析的介绍，希望这些思路能够对大家有所启发和帮助。

报警原因定位

在回滚完毕后，我们开始具体分析报警产生的主要原因，于是进行了以下几步的排查。

第一步，查看了报警的Mapper方法，如下代码段所示。这个是接收返回参数，根据主键id，更新

具体响应内容和时间的代码，入参有3个，类型分别为long、String和LocalDateTime。

int updateResponse(@Param("id")long id, @Param("response")String response, @Param(

第二步，我们查看了 Mapper方法对应的XML文件，如下代码段所示，对应的parameterType类型

是String，而实际参数的类型包括long、String以及LocalDateTime。

UPDATE invoice_log

SET response = #{response}, update_time = #{updateTime}

WHERE id = #{id}

</update>

第三步，我们查看了MyBatis上线前后的版本，报警的内容是：MyBatis在处理SQL语句时，发现

不能将LocalDateTime转型为String，这一段逻辑在上线前是可以正常运行的，并且上线的业务逻

辑对这段历史代码无改动。因此，我们猜测是因为inf-bom的升级，从而导致MyBatis的版本发生了

变化，对某些历史功能不再支持了。MyBatis版本上线前后的变化如下表所示：

表1 MyBatis版本升级前后对比

第四步，我们通过第三步可以得到，在这次inf-bom的版本升级中，MyBatis的版本直接升了两个大

版本，因此我们可以基本将原因猜测为MyBatis升级跨度较大，导致部分历史功能没有兼容支持，

of 15

5墨值下载

mybatis mysql

关注

评论