事情的导火索是一次中间件的补丁升级工作
升级完暂时没人发现什么事情
直到两天以后
程序那边开始反馈
说程序突然乱码了
就是中间件导致的
这种说法还是头一次听说
运维那边和开发人员一口咬定
程序一点没动，补丁升级之后就乱码了
肯定是中间件有问题
嗯，怀疑的合情合理
但似乎又感觉哪里不对
深入了解后发现是只有中文的业务有问题
由于中文的报文并不是很多
所以影响的业务并不多
开始排查吧
问一句是否能在测试环境复现
那边又开始扯皮了
反正说了半天
人家就是不听
总结一句
你中间件出了问题了
和程序无关
想我们配合没门
手动来一个白眼
只能自己上去看一眼
首先是看中间件的字符集配置情况
看了一圈，升级的和没升级的是保持一致的
没什么发现
在宿主机上执行了 locale
这时候返回是 lang = GB18030
问运维了一句是否改过字符集
结果一问三不知
问就是不知道、没印象、没改过
只能看看其他没升级的机器上
看了一下，结果其他几个机器是同样的字符集 GB18030
GB18030 是一个国标的字符集
支持很多繁体字
但是没印象程序用到过这个
一般程序都是默认使用 UTF-8
本着试试看的心态
把字符集改回了 UTF-8
export lang=UTF-8结果发现所有异常全部消失
一点问题都没有
后来追问才知道
先部署的中间件
后期他们在同一个用户下运行 jar 包涉及到更换字符集
于是顺手把当前用户的环境变量给改了
由于每次投产程序都不重启中间件
结果程序稳定运行一年 一直没发现问题
直到中间件补丁升级才做了重启
由此一颗大雷就此引爆
总结：运维和开发都是坑比
建议：建议把更改字符集写进启动 jar 包的脚本中
多个程序运行在同一个用户下不应随意更改环境变量
其他建议：用容器