Adjustments to the SOFAArk SPI mechanism policy and the ClassLoaderHook mechanism

[glmapper]

在 SOFAArk 1.1.0 版本中，将会对 SOFAArk 中加载 SPI 机制及 SPI 的作用生效机制进行调整。在此之前 SOFAArk 扩展机制相关描述详见：https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-extension/ 。

相关调整及考虑如下：

基于 biz/plugin 维度实现 spi 能力的隔离

在 1.1.0 版本之前， spi 扩展实现对于 plugin 或者 ark 是全局性的，以 ClassLoaderHook 为例，对于 多个 biz 或者 plugin ,如果都提供了 ClassLoaderHook SPI 的实现，最终生效的是 多个 biz 或者 plugin 中 ClassLoaderHook 实现优先级较高的。例如：

biz1 ( ClassLoaderHookImpl1 order = 1)
biz2( ClassLoaderHookImpl2 order = 2)
biz3( ClassLoaderHookImpl3 order = 3) 

biz1/biz2/biz3 中对 ClassLoaderHook 均作了扩展实现，但基于之前的策略，由于 biz1 的优先级较高，所以最终只有 ClassLoaderHookImpl1 生效，在biz2/biz3中自己提供的将会无效，而生效的是 ClassLoaderHookImpl1。

SOFAARK 本身要完成的事情就是实现隔离，因此在 SPI 扩展上也更期望每个 biz 或则 plugin 能够独立使用自己的 SPI 扩展实现，而不受到其他 biz 或者 plugin 的影响。

提供对 BIZ SPI 扩展机制的支持

295 #213

ClassLoaderHook 在宿主应用中的兜底逻辑处理

在某种场景下，我们希望能够有一个能够全局生效的 SPI 扩展实现，这样就可以不需要每个 biz 都去单独实现。在 SOFAArk 中 Master Biz 是比较特殊的 biz ，它不能被卸载，一般情况下，它的生命周期往往是和容器是一致的，因此我们考虑在 Master Biz 中以一种特殊的方式来做兜底。

[sofastack-bot[bot]]

Hi @glmapper, we detect non-English characters in the issue. This comment is an auto translation by @sofastack-robot to help other users to understand this issue.

We encourage you to describe your issue in English which is more friendly to other users.

In the SOFAArk 1.1.0 release, the mechanism for loading the SPI mechanism and the SPI in SOFAArk will be adjusted. Prior to this, the description of the SOFAArk extension mechanism is available at https://www.sofastack.tech/projects/sofa-boot/sofa-ark-ark-extension/. Related adjustments and considerations are as follows: ###Isolation of spi capability based on biz/plugin dimension Prior to version 1.1.0, the spi extension implementation was global for plugin or ark, with ClassLoaderHook as an example, for multiple biz or plugin, If the implementation of the ClassLoaderHook SPI is provided, the final implementation of the ClassLoaderHook in multiple biz or plugin implementations has higher priority. For example: biz1 ( ClassLoaderHookImpl1 order = 1) biz2( ClassLoaderHookImpl2 order = 2) biz3( ClassLoaderHookImpl3 order = 3) biz1/biz2/biz3 has extended implementation of ClassLoaderHook, but based on the previous strategy, due to Biz1 has a higher priority, so only ClassLoaderHookImpl1 will take effect. It will be invalid in biz2/biz3, and ClassLoaderHookImpl1 will take effect. What SOFAARK itself is doing is to achieve isolation, so it is also expected that each biz or plugin can independently use its own SPI extension implementation on the SPI extension without being affected by other biz or plugin. ### Providing support for BIZ SPI extension mechanism #295 #213 ### ClassLoaderHook Logic processing in the host application In some scenarios, we hope to have a globally valid SPI extension implementation, so that we can Every biz needs to be implemented separately. In SOFAArk, Master Biz is a special biz, it can not be uninstalled. In general, its life cycle is often consistent with the container, so we consider doing a special way in Master Biz.

[caojie09]

有几个设计地方不大明白：

1. 既然 ClassLoaderHook 要区分 Plugin 和 Biz，为什么不直接用类似 BizClassLoaderHook 和 PluginClassLoaderHook 从接口分开，而是选择让大家在 @Extension(Constants.PLUGIN_CLASS_LOADER_HOOK) 中注解属性区分？
2. 1.0.0 版本在 ExtensionLoaderServiceImpl#loadExtensionStartup 中会获取所有 Plugin 的 Extension，这个设计上就不合理吧，因为我们一直强调的是隔离性，A 插件拿到 B 插件的扩展不合理；
3. 接第二条，如果不需要从其他插件获取扩展，那么 Extension#order 还有必要吗？个人倾向 com.alipay.sofa.ark.spi.service.extension.Extension 这个接口没必要，类似 Java 的 spi 机制应该完全够用了
4. ArkServiceLoader 这个类是一个静态类，既然用了 guice，用 guice 管理 bean 是否更合理呢？
5. 看了下 文档，里面说

   为什么不支持 Biz 的 SPI 扩展实现加载

   考虑到 Biz 会动态的安装和卸载，如果支持 Biz 的扩展实现加载，生命周期容易引起混乱，暂时不考虑支持。如果确实存在 Ark Plugin 需要主动触发 Ark Biz 的逻辑调用，可以通过 SOFAArk 内部事件机制。

如果 biz 的扩展只是给 biz 自己用，不会全局共享，风险应该可控。