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也来个规定，必须在
这3个文件夹（任意一个）下有一些特殊文件（文件名为接口名，内容是key=value形式的扩展点配置），总言而之，原理是和java spi的原理一毛一样 。
3. 最后让我们来举个栗子，使用咱自定义的NBProtocol来暴露服务。#####
-
弄一个jar包，jar结构如下
Paste_Image.png 新建一个dubbo provider的工程，pom里依赖上面的jar，里面的spring xml 配置加上这个
3.首先在一开始加载的时候会扫描到我们自定义的协议，
在往下走，运行到了断点这个位置，说明开始暴露服务了，说明咱的牛逼协议流程可以通了
总结
上面就是我的一些关于扩展点加载机制的了解，最直观的感受是，有了扩展点明显感觉生活质量明显提高了不少，因为不管猴年马月，不管你是蹲在那个阴暗的角落，只要按照规范弄个jar包丢到classpath中，你可以直接替换原来的功能了，让我们看下dubbo自带哪些扩展点
哇！这帮人真能写啊，也就是说这些东东我们统统能换掉，学习了上面的知识，让我们分分钟把dubbo改的面目全非吧！！
阿里云服务器限时打折！点击获取
