Module config no support unexport

[owen200008]

unexport add remove config

[codecov-commenter]

Codecov Report

Merging #10380 (283fb84) into 3.0 (e3cc859) will decrease coverage by 0.07%. The diff coverage is 86.95%.

@@             Coverage Diff              @@
##                3.0   #10380      +/-   ##
============================================
- Coverage     65.72%   65.65%   -0.08%     
+ Complexity      319      318       -1     
============================================
  Files          1233     1234       +1     
  Lines         53721    53859     +138     
  Branches       8119     8154      +35     
============================================
+ Hits          35309    35359      +50     
- Misses        14564    14642      +78     
- Partials       3848     3858      +10     

Impacted Files	Coverage Δ
...ache/dubbo/config/context/ModuleConfigManager.java	69.76% <78.57%> (+1.34%)	:arrow_up:
...he/dubbo/config/context/AbstractConfigManager.java	76.69% <100.00%> (+2.64%)	:arrow_up:
...va/org/apache/dubbo/config/spring/ServiceBean.java	70.73% <100.00%> (+3.16%)	:arrow_up:
.../apache/dubbo/rpc/filter/ProfilerServerFilter.java	62.85% <0.00%> (-20.00%)	:arrow_down:
...bo/rpc/protocol/dubbo/DecodeableRpcInvocation.java	70.19% <0.00%> (-6.74%)	:arrow_down:
...e/dubbo/rpc/protocol/tri/transport/WriteQueue.java	73.80% <0.00%> (-4.77%)	:arrow_down:
...dubbo/remoting/exchange/support/DefaultFuture.java	87.93% <0.00%> (-4.32%)	:arrow_down:
.../apache/dubbo/rpc/protocol/injvm/InjvmInvoker.java	63.56% <0.00%> (-3.88%)	:arrow_down:
...he/dubbo/remoting/transport/netty/NettyServer.java	70.17% <0.00%> (-3.51%)	:arrow_down:
.../registry/zookeeper/ZookeeperServiceDiscovery.java	68.35% <0.00%> (-2.54%)	:arrow_down:
... and 24 more

Help us with your feedback. Take ten seconds to tell us how you rate us.

[AlbumenJ]

还有一个问题是 ServiceBean 的 unexport 方法是谁调用的，理论上用户不会直接使用 ServiceBean 的，一般都是使用的 ReferenceConfig。如果 ServiceBean 的 unexport 是来自框架的调用，那么应该由外面的销毁管理器来统一清理。 这里有一个依赖关系是 ModuleModel => ConfigManager => ReferenceConfig，理论上是不应该由后级直接向前级直接发起调用的（一些特殊场景除外，但是要尽量减少这种场景），否则会很容易出现循环依赖。

[owen200008]

还有一个问题是 ServiceBean 的 unexport 方法是谁调用的，理论上用户不会直接使用 ServiceBean 的，一般都是使用的 ReferenceConfig。如果 ServiceBean 的 unexport 是来自框架的调用，那么应该由外面的销毁管理器来统一清理。 这里有一个依赖关系是 ModuleModel => ConfigManager => ReferenceConfig，理论上是不应该由后级直接向前级直接发起调用的（一些特殊场景除外，但是要尽量减少这种场景），否则会很容易出现循环依赖。

我这边要做的就是service和ref的一个热加载的功能，service mesh里面控制面肯定也是需要这块的

1. 我原始是基于ServiceBean做export和unexport来实现的，我这边考虑改成用ServiceConfig去热加载服务，这样可以避开目前这个问题，我这边的实现这里应该是我用法问题

针对ServiceBean的代码增加我看了#8789 #8867 没有完全理解

1. 就是为什么不是加到自己成员的ModuleModel
2. ModuleModel => ConfigManager => ServiceConfig 理论上是不应该由后级直接向前级直接发起调用的，这个我非常同意，对用户使用的是ServiceConfig和ReferenceConfig，因此难免会有操作上涉及到管理类的变更，更极端一些我可能不希望包含这些类，我只想包含定义变更的接口让对应管理层来实现（类似delegate也可以），这样用于解决内部循环依赖问题 用户使用层不用关心内部实现层次，但是实现层内部本身解决调用链问题

[AlbumenJ]

我这边要做的就是service和ref的一个热加载的功能，service mesh里面控制面肯定也是需要这块的

这里在 3.0 的最新版本中，最好是和 ModuleModel 一起来做的，一次热发布绑定到 ModuleModel 的生命周期。目前 Spring Context 也支持绑定到 ModuleModel 上，在 Spring Context 关闭后也会自动关闭 ModuleModel，然后连带清理环境。当然单个的 Config 也是支持独立热发布的。

ModuleModel => ConfigManager => ServiceConfig

这里想到一个方式，是否可以 ServiceConfig 向 ConfigManager 发送初始化或者销毁的通知，由 ConfigManager 来决策是否销毁这个引用。

[owen200008]

我这边要做的就是service和ref的一个热加载的功能，service mesh里面控制面肯定也是需要这块的

这里在 3.0 的最新版本中，最好是和 ModuleModel 一起来做的，一次热发布绑定到 ModuleModel 的生命周期。目前 Spring Context 也支持绑定到 ModuleModel 上，在 Spring Context 关闭后也会自动关闭 ModuleModel，然后连带清理环境。当然单个的 Config 也是支持独立热发布的。

ModuleModel => ConfigManager => ServiceConfig

这里想到一个方式，是否可以 ServiceConfig 向 ConfigManager 发送初始化或者销毁的通知，由 ConfigManager 来决策是否销毁这个引用。

这样是可以的 目前我对注册进ConfigManager的用途没有深入研究过，因为目前在ModuleModel里面的deployer有exportservice这个保存的配置信息已经足够了，后期是打算全部放到ConfigManager，这边都删除掉吗？

[AlbumenJ]

多实例化改造之后ModuleModel持有了 ConfigManager 和 ServiceRepository。和配置相关的放在 ConfigManager，和发布后服务相关的放在 ServiceRepositorory。Deployer 直接存储 exportedService 应该是有问题，最后都要收口到 ConfigManager 和 ServiceRepository。