apache/servicecomb-java-chassis

Java-Chassis2.8分支的ServicePathManager初始化流程的健壮性不足

yhs0092 opened this issue · 1 comments

yhs0092 commented

问题原理分析

Java-Chassis做微服务调用的时候, 要求能从 MicroserviceMeta 中取出 ServicePathManager 实例. 而将 ServicePathManager 设置进 MicroserviceMeta 的逻辑是在 RestEngineSchemaListener#onCreateMicroserviceVersion 方法中执行的. 这个监听器从 guava EventBus 监听 CreateMicroserviceVersionEvent 事件, 并创建 ServicePathManager 与对应的 MicroserviceVersion 关联起来.

RestEngineSchemaListener 是在BEFORE_REGISTRY事件阶段注册到 EventBus 的, 也就是说, 如果有MicroserviceVersion对象是在RestEngineSchemaListener注册到 EventBus 之前创建的, 则它无法触发 RestEngineSchemaListener 执行上述动作, 也就不会有对应的 ServicePathManager 对象. 而且, 这个问题是不可恢复的, 一旦MicroserviceVersion对象有这个问题, 除非重启, 否则它一直会保持有问题的状态, 导致consumer端一直调用不了对应的producer微服务.

例如, EdgeService场景下, EdgeInvocation#edgeInvoke 就会触发创建MicroserviceVersion对象, 这是有可能在 BEFORE_REGISTRY 事件之前触发的(它不在SCBEngine#ensureStatusUp的保护范围之内).

建议

  1. 能否取消RestEngineSchemaListener, 目前它做的事情就是在 MicroserviceVersion 对象创建出来的时候, 创建一个 ServicePathManager 对象与之对应. 这个流程能否挪到 MicroserviceVersion 自身的初始化方法中?
  2. edge Dispatcher中也应该做 SCBEngine#ensureStatusUp 状态检查.

这两条都有价值做, 因为建议2无法完全拦截建议1涉及的场景.

liubao68 commented

可以提交PR尝试下吗？