DUBBO的 SPI 方式思考

  

      Java 的SPI方式可以动态的加载扩展类，但是用法不是很灵活，DUBBO框架因为存在多个扩展点所以实现了自定义的一种扩展方式，也就是实现了作者提到的微核心，插件式的思路。

比如，需要扩展Dubbo的协议，只需在xxx.jar中放置：
文件：META-INF/services/com.alibaba.dubbo.rpc.Protocol
内容为：com.alibaba.xxx.XxxProtocol
Dubbo通过ServiceLoader扫描到所有Protocol实现。

 

这样的一种扩展思路本身是非常符合OO的思想，如果要扩展一种新的实现，只需要配置和新写实现即可，甚至不需要动原来的jar包，直接放在扩展包。当每一个地方都使用扩展的时候就出现了一种管道式的架构。

 

  

 

           在dubbo框架的每一个有多种实现或者潜在实现的关键点，作者都使用了这种方式，实现了微核心，插件式的开发模式。之前对以微核心这种思想一直理解的不是很深入，看了dubbo后，有了新的认识。此外作者在这些切入点还支持包装和过滤监听等功能，当有个性化的需求的时候是很容易切入这个点。此为为了管理这些扩展点，dubbo实现了一个庞大的工厂类来支持或者和加载这些类，而具体需要使用什么具体扩展实例，都是通过上层传递的参数来确定的。通过这样的设计：

 

             1、实现了微核心。通过这种方式，代码的关键代码非常的少，主流程逻辑非常清楚，在设计最初对细节不是很确定的情况下，但是主要流程固定的情况下可以使用这种方式，将后来的需求作为实现，个人化的需求，可以作为插件的监听或者连接器配置，这样可以使得主流程非常的清晰，也符合OO的思想。

             2、便于测试。因为使用了这样的方式，每个功能点都是扩展，可以针对每个点进行测试，每个组件因为都只承担了一个功能，所以可以针对一个功能点进行测试。

             3、便于扩展，当需需求变化需要变动功能时，可以针对扩展点进行写新的实现。或者开发新的插件，这样不会动到原来的东西。

    总之，dubbo是一个良好的微核心插件式的例子，通过对dubbo的学习，可以领悟这种设计的优点和可扩展性，进而对理解OO思想也很有帮助。