背景:
我们的应用服务架构设计已经支持不停机发版了, 但是某次上线的时候,由于运维失误,误更改了一个错误的 eureka 配置(我们当前生产的配置是运维管理的),导致了服务启动的时候从配置中心拉到了一个错误的 eureka 地址,结果就是连接不上: org.apache.http.conn.ConnectTimeoutException: Connect to [eureka-ip:eureka-port] timed out
原本我们的容器架构是支持健康检测失败自动回滚的, 巧就巧在这个问题应用服务只是连接不上 eureka, 但是它本身是健康的,所以k8s 未回滚。这个过程触发了我以下几点思考:
关键因素:
人的失误如何避免?
如何优化应用架构来换取服务健壮性?
多点风险因素并发导致风险概论提升,如何分散风险?
发版的时间节点是否应该优化?
可参考的优化思路及逆思考:
》人的失误总会存在的, 就象机器会宕机一样正常。可以放慢节奏,加强运维层面的规范执行例如:更改重要的基础配置的时候,两人或以上一起操作相互提醒。关注 CI/CD 的生命周期(打包-上传-启动),打包发版的时候加强日志的观察,在确认当前基点启动正常后再进行后续的发版工作,以尽可能减小影响。
》应用架构优化:管理 eureka 的连接超时异常,升级它的异常处理策略为 :应用启动的时候连接不上就不启动服务,做失败处理(预期触发 k8s 的回滚以保证服务可用),或者光棍点把基础架构的建设都交给云原生——注意了未来中小型企业应用架构一定是云原生的要优于自管理、半管理的应用架构的。
》风险的问题,只能靠经验做风险预估,要分散管理风险也是依赖人的经验,方法论可以参考项目管理方法论,只是方法论本身还是基于经验的基础上得来的,且不可照搬照套,总结起来还是要靠人,引入风险管理工具等(最简单的就是文档,复杂的如直方图、因果分析图、帕累托图等)。
》对于发版时间节点的风险管控这点,但是本身服务就是无状态的,如果通过控制发版时间来限制的话,那是历史的倒退)。