使用 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 存活的组件，也有更多的操作空间（😏😏）。

写在最后

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