开年叽喳
进入2024年一月后,帝都从之前的零下十几度上升到白天零度以上,伴随着久违的蓝天心情也愉悦起来。新年读完的第一本书《时势 周期波动下的国家、社会和个人》,整本书讲的通俗易懂,把一些常识完美地表达出来,”没有人会一直对下去“是最大的感触。
工作中,机房迁移中个人负责的词典和硬件服务迁移进展迅速,要感谢一直支持的研发小伙伴们!~也遇到一些比较搞笑的事情,哈哈,记录一下。
坑爹的1秒sleep
有一个十多年前的服务在五年前已经放到了容器里面,在北京集群跑的非常好,换到贵阳集群后就不行了,具体表现上就是服务起来后端口不监听,如下图:

这里面monitor.py 中会通过请求127.0.0.1 接口来判断服务状态(下图红框中的部分),异常的话就kill掉记录的进程pid再通过os.system来执行重启脚本重启,看起来这块的逻辑没有问题。但是端口为什么一直没有监听呢??百思不得其解!
最开始怀疑是os.system执行时候默认sh的问题,测试发现并不是;排查发现这个监控间隔time.sleep(1)(下图蓝框中的部分)特别可疑,1s太短了服务有可能起不来,把sleep时间调大到5s,服务能起来端口监听也正常。这~~~

jdk的cacerts
这个也是迁移服务遇到的,换了个机器,拷贝了一份jdk,起来没有多久就遇到了下面的异常。解决起来比较快,发现拷贝的jdk和之前服务用的jdk有些差别,cacerts不一样,更换为之前的jdk后服务正常了。

JAVA类服务在发送https请求的时候,如果请求中没有携带对方合法的ca证书是会报错的,常用的JDK已经集成了很多常用ca的证书。
查看命令:keytool -list -v -keystore lib/security/cacerts,
默认密钥口令:changeit
首先看有问题的jdk中cacerts里面是 Your keystore contains 92 entries

正常的jdk中cacerts里面是 Your keystore contains 129 entries

也可以自行选择往jdk中导入CA证书,网上很多教程还有代码(https://github.com/escline/InstallCert)
写在最后
机房迁移过程中特别特别忙,为了把对用户造成的服务不可用影响降到最小,和研发同学有几天都从凌晨干到天亮,脑子都”雾“了,上面的这些问题作为新年”礼物“,提醒自己还是要细心谨慎。