dubbo 大白话系列-扩展点机制

1. 问题的由来

条条大路通罗马，实现相同的功能可以使用不同的方案，比如说dubbo代理生成的方案，有人喜欢用JDK动态代理，有人喜欢用javasist生成字节码的方式来生成代理。RPC协议可以使用dubbo协议，也可以使用RMI协议。那么问题来了，既然实现同样的功能有多种方案，而dubbo又不能强行用户必须要使用哪一种方案，总不能写死在代码里吧，那么如何做到在运行时根据我的需要自由切换呢？

2. 解决过程

dubbo想达到的效果就是根据用户传入的参数来自动找到合适的方案。

2.1 我能想到最简单的方法就是:

if(参数==“dubbo”){ return new DubboProtocol(); }else if(参数 == "rmi"){ return new RMIProtocol(); }
...... .......
这样也可以解决问题啊，用户参数里指定啥协议，我返回给你啥协议

2.2 能不写if else吗？

万一哪天又出了一种牛逼的rpc协议叫做NBProtocol，难道要去改代码多加个if else吗？
那好吧，那我使用设计模式之 -- 策略模式，不就解决了？对外暴露的接口都是一样的，只是内部的一小部分算法我可以自由替换，也就是说，启动的时候把所有协议统统扫描进来，最终的效果就是策略模式内部维护一个这样的map：

name	className
dubbo	com.xxx.xxx.DubboProtocol
rmi	com.xxx.xxx.RMIProtocol
nb	com.xxx.xxx.NBProtocol

如果用户外边传一个参数叫“rmi”，我就map.get("rmi"),这样就得到了RMIProtocol。

2.3 鸟不拉屎的位置

感觉好像已经解决了，但是好像有点不对，上面说启动的时候把所有协议统统扫描进来，咋扫描？去哪扫描？你的这个牛逼的NBProtocol协议有可能是在哪个旮旯的jar里，也有可能是在哪个鸟不拉屎的package下面，也有可能在文件系统里，也有可能在遥远的网络上，你让dubbo去哪找你哪个牛逼的NBProtocol？

那这也好办，我dubbo就规定了，你自己写的扩展的协议都要放在xxx.xxxx这个classpath下，不放不加载，到时候找不到可别怪我没跟你说过。恩，就这样，按照事先约定好的约定，就可以解决加载位置的问题。

2.4 寻找优越感

按理说已经解决了之前说动态加载的问题了，但是呢，作为一个牛逼的框架，总得写点别人看不懂的代码吧，不然优越感哪里来？
好吧，之前java 1.6 就引入了一种叫做spi的东西，主要就是为了做到服务发现和动态扩展，SPI英文为Service Provider Interface。但是呢，如果直接就用spi虽然也勉强可以，但不改点东西岂不是太low了，我dubbo的优越感哪里找？？何况原生的spi确实有点小问题，那就是他一上来就把你要的类全都实例化了（我只是多放几个在哪里装装逼，压根没想去用，别那么较真）。于是乎dubbo就搞出来一个，而且是按需实例化。人家java spi里有serviceloader，dubbo就来个extensionloader，意思都一样，都是负责去加载自定义的扩展点的。人家java spi 规定了自己写的扩展点必须要在 /META-INF/services/ 下边有一个文件（文件名是接口完全限定名，内容是接口实现类），dubbo也来个规定，必须在