记一次中间件乱码问题(扯皮)

98次阅读
没有评论
记一次中间件乱码问题 (扯皮)

事情的导火索是一次中间件的补丁升级工作

升级完暂时没人发现什么事情

直到两天以后

程序那边开始反馈

说程序突然乱码了

就是中间件导致的

这种说法还是头一次听说

运维那边和开发人员一口咬定

程序一点没动,补丁升级之后就乱码了

肯定是中间件有问题

嗯,怀疑的合情合理

但似乎又感觉哪里不对

深入了解后发现是只有中文的业务有问题

由于中文的报文并不是很多

所以影响的业务并不多

开始排查吧

问一句是否能在测试环境复现

那边又开始扯皮了

反正说了半天

人家就是不听

总结一句

你中间件出了问题了

和程序无关

想我们配合没门

手动来一个白眼

只能自己上去看一眼

首先是看中间件的字符集配置情况

看了一圈,升级的和没升级的是保持一致的

没什么发现

在宿主机上执行了 locale

这时候返回是 lang = GB18030

问运维了一句是否改过字符集

结果一问三不知

问就是不知道、没印象、没改过

只能看看其他没升级的机器上

看了一下,结果其他几个机器是同样的字符集 GB18030

GB18030 是一个国标的字符集

支持很多繁体字

但是没印象程序用到过这个

一般程序都是默认使用 UTF-8

本着试试看的心态

把字符集改回了 UTF-8

export lang=UTF-8

结果发现所有异常全部消失

一点问题都没有

后来追问才知道

先部署的中间件

后期他们在同一个用户下运行 jar 包涉及到更换字符集

于是顺手把当前用户的环境变量给改了

由于每次投产程序都不重启中间件

结果程序稳定运行一年 一直没发现问题

直到中间件补丁升级才做了重启

由此一颗大雷就此引爆

总结:运维和开发都是坑比

建议:建议把更改字符集写进启动 jar 包的脚本中

多个程序运行在同一个用户下不应随意更改环境变量

其他建议:用容器

正文完
 
评论(没有评论)