Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
#4,294 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
停滞
技术栈
java

调研方向

首先跟踪 RestEngineSchemaListener#onCreateMicroserviceVersion 和 MicroserviceVersion 的初始化,然后检查 EdgeInvocation#edgeInvoke 和 SCBEngine#ensureStatusUp。确认哪些创建路径可能先于 EventBus 注册发生。完成的标准是每个 MicroserviceVersion 都有自己的 ServicePathManager,并且 edge dispatcher 处理所需的状态检查。

由索引模型根据 Issue 内容生成。

描述

问题原理分析

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涉及的场景.

主要语言
Java
星标
1.9k
派生
813
平均合并
8 天 23 小时
30 天内合并 PR
1

贡献指南

这个仓库没有索引到贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

apache/servicecomb-java-chassis 的其他 Issue

查看 apache/servicecomb-java-chassis 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。