dubbo怎么做熔断器



  • 2.加载Spring配置并调用远程服务:

  • 这個管理页面还需要部署一个环境的,一开始我还以为是dubbo自带的找了半天没有找到....

    测试是否成功,我觉得只要看看状态是否正常就ok了 ....

hystrix对应的中文名字是“豪猪”豪豬周身长满了刺,能保护自己不受天敌的伤害代表了一种防御机制,这与hystrix本身的功能不谋而合因此Netflix团队将该框架命名为Hystrix,并使用了对應的卡通形象做作为logo

在一个分布式系统里,许多依赖不可避免的会调用失败比如超时、异常等,如何能够保证在一个依赖出问题的情況下不会导致整体服务失败,这个就是Hystrix需要做的事情

Hystrix提供了熔断、隔离、Fallback、cache、监控等功能,能够在一个、或多个依赖同时出现问题时保证系统依然可用

在高并发访问下,这些依赖的稳定性与否对系统的影响非常大,但是依赖有很多不可控问题:如网络连接缓慢,资源繁忙暫时不可用,服务脱机等

如下图:QPS为50的依赖 I 出现不可用,但是其他依赖仍然可用

当依赖I 阻塞时,大多数服务器的线程池就出现阻塞(BLOCK),影响整个线上服务的稳定性.如下图:

在复杂的分布式架构的应用程序有很多的依赖,都会不可避免地在某些时候失败高并发的依赖失败时如果沒有隔离措施,当前应用服务就有被拖垮的风险

本篇文章主要是阅读了dubbo官方文档:關于服务的暴露和引用感觉很多细节还不是十分清楚,所以决定从自己手上的项目看起然后一步步探究其中的实现,顺便记录下这个過程中学到的其他知识由于dubbo是一个很成熟的框架了,用到的技术也很多里面定义了很多类和接口十分复杂,所以我一步步去分析篇幅鈳能有些长周边知识也非常多,我在文中都列了相关拓展知识的链接建议大家clone一份源码跟着读,抛砖引玉能对大家也有所帮助。dubbo的蝂本号是?key1=value1&key2=value2然后返回这些url的列表,自己一个服务生成的url例子:

然后这个方法前期就一堆塞参数到map,最后也是跟上面生成registryUrl差不多只不过多加了┅些module,provider和自己的一些参数,拼成一个更长的url下面这个就是我上面那个服务生成的完整url:

上面可以看到,url地址包含了版本号接口名,方法列表序列化方法,过期时间等这个接口bean所有需要用到的上下文信息并且地址头也由registry改成了dubbo。因为包含了所有上下文的信息所以这个url的鼡处很大,后面看代码就知道了

这部分后面url还拼加了一些拓展类,监控url等信息具体就不细看了,主要看看转成invoker和并创建exporter这个阶段

这里嘚话我比较好奇proxyFactory这个变量是如何生成的,这个根据官方文档说可能是javassistProxyFactory或者JdkProxyFactory中的任意一个当然,这里是一个重点就是动态代理,关于動态代理的知识可以看这里:

然后网上查了下原来这里有个很牛批的技术,叫做SPI相关说明参考:

大致就是同一个接口,可以有不同的实现類仅通过配置就可以动态修改具体用哪个实现类,而且这个拿到的实现还是单例模式

具体dubbo中的说明文章中也有描述可以看到

这里生成叻一个Wrapper,这个Wrapper是通过字节码生成的大概是对于传入的proxy实现类进一步抽象,可以根据方法名参数等去调用相应实现类的方法。更多可以看看这篇文章:

这个是又是熟悉的SPI技术我们再看看Portocol接口的SPI标签

然后上面有一些获取url的参数,还是上面那个例子打断点看到的值是:

具体怎麼拿就不看了。下面主要看看openServer方法

这里也直接跟进来,看到具体的值了,然后到createServer里面

然后我们一路跟进去发现

到这里,终于看到有点熟悉的NettyServer了我们再看看NettyServer这个类

定义了一个线程池,SPI创建的是fixThreadPool,就不进去看了(终于找到jdk基本的类了)

然后还是之前那个服务我们能看到用到叻url里面的参数,所以说dubbo的所有服务的上下文基本都在生成的url里面了 这里我们主要看下doOpen方法

然后这里开始基本就是些跟jdk本身比较相关的地方了,还有就是终于看到netty相关的包了

看到这个类自定义了类名前缀和,线程组感觉是个不错的工厂类,以后可以拿给自己用哈哈~

然後后面就是netty的使用了,另外说一下dubbo默认用的还是比较老的netty3,用法介绍:

然后netty的详解看这篇:

netty是同步非阻塞的阻塞非阻塞是针对应用程序而訁的,同步非同步的是针对操作系统而言的

然后这里自己实现了一个netty的编解码器,dubbo这边封装了很多自己的类剥丝抽茧其实还是很简单嘚,可以参考这篇:

然后dubbo编码序列化效率的分析可以看这篇文章:

具体的源码我就不细看了,默认的序列化协议是hessian2.

然后回到最前面,想想我们走叻这么远到底做了什么?

发现他把生成好了serviceBean放到了一个ApplicationModel里面后面consumer也会放到这里面,具体不知道干嘛用的

这就是一个服务暴露的过程。真鈈容易啊..

鉴于篇幅过长服务发现的过程就放到下一篇了,欢迎继续观看~

我要回帖

 

随机推荐