Suggestions for modification Microcore + plugin

前言

大家好，我是一名dubbo的深度使用者，在使用的过程中，发现在dubbo扩展点的设计上还留有一些小的缺陷。在说明的过程中，我会以接口org.apache.dubbo.rpc.Protocol来举例子。

缺陷说明

dubbo的扩展点可以满足新增一种实现方式的需求，比如我可以新增一种Protocol的实现（如下面的代码），用户可以在他的配置文件中使用新的实现。
但是却无法满足用户这样的需求：不想修改SPI默认扩展点的名字（对Protocol来说默认是dubbo），仅 仅想替换DubboProtocol的实现，也许是用户有更好的实现想自己尝试一把，但又不想通过修改源码重新编译来完成，抑或者是用户发现了一个bug，但是社区又不可能马上修改这个bug立马发布一个版本,对此时的用户而言，他最希望能无缝替换原实现）。我有时就有这种冲动，想要替换原实现。:）

 public  class  NewProtocol  implement Protocol{
       //code here ...
 }

修改建议 微核心+插件式

扩展点的加载方式，全部统一按照插件方式加载。插件由一个插件生命周期管理容器维护，它们构成微核心，核心不包括任何功能，这样可以确保所有功能都能被替换，并且，框架作者能做到的功能，扩展者也一定能做到，以保证平等对待第三方，所以，框架自身所有Extension功能均通过插件的方式实现，没有任何硬编码。

分包

• 微内核包 包括插件管理器的接口、一些核心注解、插件接口、插件生命周期接口、事件通知接口等
• 插件管理器的默认实现包 负责查找具体的插件实现（注意：插件管理器本身也是可以通过插件的形式被用户替换的哦）
• 其他的功能包（比如dubbo-config,dubbo-remoting）

目的

通过只添加代码就能替换或者新增实现，且无需修改任何原始代码。

Foreword Hello everyone, I am a deep user of dubbo. During the process of using it, I found that there are some minor defects in the design of the dubbo extension point. In the process of explanation, I will use the interface org.apache.dubbo.rpc.Protocol as an example.

Defect description Dubbo’s extension point can meet the needs of a new implementation. For example, I can add a protocol implementation (such as the following code), users can use the new implementation in his configuration file. But it can not meet the needs of users: do not want to modify the name of the SPI default extension point (the default is dubbo for Protocol), just want to replace the implementation of DubboProtocol, maybe the user has a better implementation, I want to try it myself, but I don’t want to recompile by modifying the source code, or the user finds a bug, but the community can’t immediately modify the bug to release a version. For this user, he hopes to replace the original implementation seamlessly.) . I sometimes have this urge to replace the original implementation. 😃

Public class NewProtocol implement Protocol{        //code here …  } Suggestions for modification Microcore + plugin The loading method of the extension point is all loaded in the same way as the plugin. Plugins are maintained by a plugin lifecycle management container, they form a micro core, the core does not include any features, so that all functions can be replaced, and the features that the framework author can do, the extension can certainly do, Guaranteed equal treatment of third parties, so all extension functions of the framework itself are implemented through plug-ins, without any hard coding.

Subcontracting Microkernel package includes plugin manager interface, some core annotations, plugin interface, plugin lifecycle interface, event notification interface, etc. The default implementation package of the plugin manager is responsible for finding the specific plugin implementation (note: the plugin manager itself can also be replaced by the user in the form of a plugin) Other feature packs (such as dubbo-config, dubbo-remoting) purpose You can replace or add an implementation by just adding code, without modifying any of the original code.

[kimmking]

For most users, it’s the best way to provide an out-of-the-box library. It is so dangerous to replace the built-in components with some self-defined ones. If you are a senior expert of dubbo, you can fork a custom version and modify it to your own way.

[CrazyHZM]

Close this issue temporarily, if you have a new idea, you can reopen it.