使用Spring Cloud的openFeign组件踩坑纪实

背景

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

解决过程

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

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

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

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

真相大白

第二天一大早来公司，想着尽快解决这个遗留问题。于是开始调试，不得不说，业务引入了 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初始化失败无法打开360，形成层次关系。

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 的组件也存在同样的问题，总不能每一个组件都自己修改一遍吧（:joy:）。我觉得还是提议 spring 框架允许设置是否允许事件冒泡来得更靠谱，这样那些靠生成子 Context 存活的组件，也有更多的操作空间（:smirk::smirk:）。

原文链接：