使用SpringCloud的openFeign组件踩坑纪实

背景

2021.05.25 晚上,刚要下班回家,突然被拉到一个群里,说是网关有问题,接入的一个应用接口死活注册不上去,新业务无法使用,而且业务方说已经发布过好几次都不生效,但是同一个应用的其他接口却可以正常注册。听起来还挺诡异的,想着重启大法,重启了下网关应用(其实网关好久没有迭代了,挺稳定的)。结果群里更是炸锅了,说原来可以用的接口也没有了,业务完全停滞(小心脏砰砰直跳)。这下搞大了,放下小书包,开始查问题...

解决过程

其实刚开始完全没有头绪,网关没有做任何改动,只是重启应用,怎么会导致业务方原来可以正常使用的接口也无法注册呢?但明显的肯定是业务方改动引起的,因为其他业务方都可以正常使用网关。于是分头行动,我去查找业务接口无法注册网关的原因,业务开发同学查看最近做过哪些变动。

因为无法注册的问题是必现,所以我在本地调试接口注册网关代码,发现他们用到了 spring-cloud 套件,联想起不久前还帮他们查过一个应用无法注册 bean 导致启动失败的案例,初步判断这个事件也跟他们使用 spring-cloud 套件有关。这个怀疑得到了开发的认可,他们确实在二个月前就使用了 spring-cloud 的 openFeign 组件,可一直相安无事呀(后来发现自从引入了 openFeign 组件后,新接口就没注册成功过,😓),为啥网关重启就导致旧接口也无法使用呢?

因为事态紧急,当务之急是恢复服务,可网关重启已经不起作用了,该如何处理呢?这时开发有了一个大胆的想法,因为网关重启前旧接口是正常的,那么只要代码业务代码撤销对 openFeign 的使用,发布上去应该能正常使用,而为了保证业务逻辑,再把代码恢复到使用 openFeign 再次发布,就能将状态恢复到网关重启前的样子。我快速将该思路理了下,又想起了网关有使用到本地缓存来保存拉取到的接口服务列表,跟重启网关导致的接口失效原因吻合,于是同意了他的做法。最终在经历了两轮发布-回滚代码-再发布,其中一个应用终于恢复到了网关重启前状态,业务反馈部分恢复。于是再同样操作把受影响的另一个应用也处理完,业务终于恢复到新接口上线前的状态,才稍微松了一口气。此时距问题发生已经过去了半个小时左右。

但是此时真正原因并没有找到,只是有了初步思路。于是群里回复相关人员:新项目中的一个依赖组件,和网关有冲突,导致服务注册不上。临时解决方案:去掉这个组件后,触发服务正常注册。此时已经晚上十点半了,具体原因只能明天详查了(😳)。

真相大白

第二天一大早来公司,想着尽快解决这个遗留问题。于是开始调试,不得不说,业务引入了 spring-cloud 后,调试链路变得更加复杂,尤其是使用了 openFeign 组件,不知道有做了啥幺蛾子。在触发注册接口的 ServivceBeanExportedEvent 监听器中,总是获取不到已经初始化好的 dubbo bean。经过多次溯源,发现业务方使用了 openFeign 组件后,整个应用上下文变成了如下图所示:

另外,在调试过程中,很诡异的发现ContextRefreshedEvent被提早触发了(在业务 Bean 没有完成初始化的情况下)。最终,在跟踪 openFeign 组件初始化中找到端倪:

原来在初始化 openFeign 组件的最后,会调用 SubContext 的 refresh()操作,最终会触发 SubContext 发出ContextRefreshedEvent事件。可问题是,子 Context 发出的事件怎么会也触发父 Context 发出类似事件呢?原来这里还有个知识点,在 Spring 框架中,事件(Event)是会沿着 Context 层次向上传播(类似 Dom 模型中的事件冒泡传播),代码如下:

再联系到 dubbo 接口导出服务依赖的ContextRefreshedEvent 以及 网关注册业务接口所依赖的 ServiceBeanExportedEvent(如下图所示):

整个事件的起因就清楚了,根本原因:项目依赖的 spring-cloud-openfeign 组件导致 dubbo 接口无法正常注册到网关。简单来说就是子 Context 发出初始化完成事件,进而引发父 Context 也发出相同事件,而父 Context 此时并没有真正初始化完成。详细解释:

大致依赖关系如下:(基本前提是 spring 框架在发布事件时,会以冒泡方式沿层次架构上报)

1. dubbo 接口 export 需要等待ContextRefreshedEvent出现,export 完成后发ServiceBeanExportedEvent

2. 网关组件依赖的 dubbo-rest 组件会等待ServivceBeanExportedEvent,然后上传 dubbo 接口信息到网关。

3.项目依赖的 openFeign 组件在初始化时会生成一个新的 ApplicationContext,以当前存在的 ApplicationContext 为父 Context,形成层次关系。

4.openFeign 组件初始化完成后会进行 Context.refresh(),该操作最后会触发ContextRefreshedEvent事件,进而会触发父 Context 发出ContextRefreshedEvent事件,导致 dubbo 接口提前初始化,引发错误,因为此时网关 Bean 组件尚未初始化完成,无法完成注册业务接口。

后续

找出事件的真正原因后,就面临着给出解决方案的问题。从上面初始化链路来看,dubbo 服务初始化的时候,确实是 parentContext 发出的ContextRefreshedEvent,只不过是由于子 Context 发出而冒泡产生(事件源还是子 Context)。所以要解决这个问题,一个办法就是修改 spring 框架增加是否冒泡参数,另一个就是 dubbo export 时判断 Event 事件源是否为其所属的 Context 发出,两种方式感觉都会对框架造成影响,因为一个是要修改 dubbo 框架的服务导出判断逻辑,一个是 spring 框架的内置逻辑,都不太好处理。

最后我们采用的是,用 @Lazy 注解将 feignClient 的初始化延迟至使用时进行,因为这时其他 Context 下的 bean 都已经初始化完成,不会有上述提前初始化的问题。

github 上也有人遇到类似的问题,大家讨论的方案也都差不多,在 dubbo 官方不打算加入对 event 冒泡做支持的情况下,可以通过

FeignClientInterface client = applicationContext.get(FeignClientInterface.class

复制代码

这样的方式获取 feignClient 实例来规避提前初始化问题(其实效果跟 @Lazy 一样)。

最后贴上一张讨论截图:

诚如网友所提出的方法,即使判断 event 来源再 export 服务也只能解决 dubbo 一个组件的问题,对于其他依赖于ContextRefreshedEvent的组件也存在同样的问题,总不能每一个组件都自己修改一遍吧(😂)。我觉得还是提议 spring 框架允许设置是否允许事件冒泡来的更靠谱,这样那些靠生成子 Context 存活的组件,也有更多的操作空间(😏😏)。

写在最后

大家有遇到类似的问题么,欢迎留言探讨解决方案~

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/71dc2fcd5f0a5360b0f017c8a
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注腾讯云开发者

领取腾讯云代金券