一次golang健康检查导致的问题

下面是整理后的事故报告:

事故概述

公司午高峰期间,支付服务的k8s 执行了pod的扩容操作,但由于id生成器服务资源不足,导致新增的pod无法成功连接到id生成器服务。由于id生成器服务采用懒加载方式,只有写操作才会用到,因此所有的查询请求都可以执行,但所有的写入操作全部失败。这导致了流量成倍增加,pod继续扩容,一度达到了14个,正常中午5个就够用了,虽然pod增加了,但是一些支付逻辑并未执行,超时关单了,或者支付失败,造成非常差的用户体验。

事故原因

id生成器服务采用懒加载方式,没有在启动时初始化连接池,只有第一个使用时才会初始化连接池。同时,aws那边回收了机器(node节点),但id生成器服务所在的pod并没有回收成功,导致部分连接失败。

运维侧原因

运维侧相关人员表示,aws那边回收了机器,但id生成器服务所在的pod并没有回收成功,这是因为应该先把pod对应的地址在服务发现之类的路由表移除以后,再去回收pod,但此次没有按照正常流程进行。对于这个问题,虽然我不是运维,但是在go语言2023年开发者大会上,我有幸观看了一些k8s运维相关的讲座,里面提到了k8s的不足,里面提到关于pod的容器退出是不保证顺序的。

image.png
image.png

完整文档链接

解决思路

为了避免类似事故再次发生,建议在服务启动时调一下id生成器、ping一下数据库,成功以后再启动grpc服务器。同时,后续健康检查也要重写一下,加入其它更合理的逻辑,如ping数据库,一些grpc服务等等。

总结

本次事故主要是由于id生成器服务的懒加载方式和运维侧的不当操作导致的。通过在服务启动时进行初始化连接池和重写健康检查,可以有效避免类似事故再次发生。

©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容