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也来个规定,必须在

源码截图

这3个文件夹(任意一个)下有一些特殊文件(文件名为接口名,内容是key=value形式的扩展点配置),总言而之,原理是和java spi的原理一毛一样 。

3. 最后让我们来举个栗子,使用咱自定义的NBProtocol来暴露服务。#####

  1. 弄一个jar包,jar结构如下


    Paste_Image.png
  2. 新建一个dubbo provider的工程,pom里依赖上面的jar,里面的spring xml 配置加上这个

Paste_Image.png

3.首先在一开始加载的时候会扫描到我们自定义的协议,


Paste_Image.png

在往下走,运行到了断点这个位置,说明开始暴露服务了,说明咱的牛逼协议流程可以通了


Paste_Image.png

总结

上面就是我的一些关于扩展点加载机制的了解,最直观的感受是,有了扩展点明显感觉生活质量明显提高了不少,因为不管猴年马月,不管你是蹲在那个阴暗的角落,只要按照规范弄个jar包丢到classpath中,你可以直接替换原来的功能了,让我们看下dubbo自带哪些扩展点

源码

哇!这帮人真能写啊,也就是说这些东东我们统统能换掉,学习了上面的知识,让我们分分钟把dubbo改的面目全非吧!!

阿里云服务器限时打折!点击获取

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,511评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,495评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,595评论 0 225
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,558评论 0 190
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,715评论 3 270
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,672评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,112评论 2 291
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,837评论 0 181
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,417评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,928评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,316评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,773评论 2 234
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,253评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,827评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,440评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,523评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,583评论 2 249

推荐阅读更多精彩内容

  • 前面我们了解过了Java的SPI扩展机制,对于Java扩展机制的原理以及优缺点也有了大概的了解,这里继续深入一下D...
    加大装益达阅读 4,963评论 2 20
  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 134,048评论 18 139
  • Dubbo是什么 Dubbo是Alibaba开源的分布式服务框架,它最大的特点是按照分层的方式来架构,使用这种方式...
    Coselding阅读 17,028评论 3 196
  • FIREFOXJS阅读 234评论 0 0
  • 作文教学最大的问题是,我们对什么是真正的“好的儿童作文”,发生了根本性的偏差。诸如“童年的事情多如天上的星星,在向...
    风尘海马泉阅读 257评论 0 0