dubbo使用(dubbo使用nacos)
本篇文章给大家谈谈dubbo使用,以及dubbo使用nacos对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。
本文目录一览:
dubbo泛化调用使用及原理解析
通常我们想调用别人的dubbo服务时,我们需要在项目中引入对应的jar包。而泛化调用的作用是,我们无需依赖相关jar包,也能调用到该服务。
这个特性一般使用在网关类项目中,在业务开发中基本不会使用。
假设我现在要调用下面的接口服务
在xml文件做以下配置
然后注入使用
在两种调用方式中,我们都需要使用被调用接口的字符串参数生成GenericService,通过GenericService的$invoke间接调用目标接口的接口。
$invoke的三个参数分别为,方法名,方法参数类型数组,方法参数数组。
可以看到泛化调厅并用的一个复杂性弊伏唤在于$invoke的第三个参数的组装,下面介绍几种复杂入参的调用方式
首先丰富提供者接口
与入参相似,虽然$invoke的返回定义为Object,实际上针对不同类型有不同的返回。
泛化调用和直接调用在消费者者端,在 使用上的区别 是,我们调用服务时使用的接口为GenericService,方法为$invoker。在 底层的区别 是,消费者端发出的rpc报文发生了变化。
在使用上,不管哪种配置方式,我们都需要配置generic=true
设置generic=true后,RefereceConfig的interfaceClass会被强制设置为GenericService
这也使得我们的RefereanceBean返回的是GenericService类型的代理。
生成的代理是GenericService的代理只是我们使用方式上的变化,更为核心的是,底层发送的rpc报文发生了什么变化。
Dubbo的rpc报文分为header和body两部分。我们这边只需要关注body部分。构造逻辑如下
那么我们通过直接调用与泛化调用ByeService的bye方法在报文上有啥区别呢?
我一开始以为报文中的path是GenericeService,其实并没有,path就是我们调用的目标方法。
path来源???todo
而报文中的方法名,方法参数类型以及具体参数,还是按照GenericeService的$invoke方法入参传递的。
这么个二合一的报文,发送到提供者那边,它估计也会很懵逼,我应该怎么执行?
所以针对泛化调用报文还会把generic=true放在attchment中传递过去
具体逻辑在GenericImplFilter中。
GenericImplFilter中有很多其他逻辑,比如泛化调用使用的序列化协议,正常接口走泛化调用的模式,我们只需要设置attachment的那部分。
知道消费者端报文发生了什么变化,那么接下来就去看提供者端如何处理这个改造后的报文。
总结一下ReferenceConfig中interfaceClass和interfaceName的区别?(这道面试题好像不错)
interfaceClass用于指定生成代理的接口
interfaceName用于指定发送rpc报文中的path(告诉服务端我要调用那个服务)
消费者泛化调用的rpc报文传递到提供者还不能直接使用,虽然path是对的,但是实际的方法名,参数类型,参数要从rpc报文的参数中提取出来。
GenericFilter就是用来做这件事情。
在提供者这边,针对泛化调用的逻辑全部封装到了GenericFilter,解耦的非常好。
注意第4个条件,一开始很疑惑,后来发现rpc报文中的path是目标接口的,这边invoker.getInterface()返回的肯定就是实际接口了
这边有个疑问,为什么这边还要再次反序列化一次,netty不是有decoder么??
嗯,你别忘了,针对一个POJO你传过来是一个Map,从Map转换为POJO需要这边进一步处理。
这边需要注意一下!!针对接口的泛化调用,抛出的异常都会经过GenericException包装一下。
从功能上来看,泛化调用提供了在没有接口依赖情况下进行的解决方案,丰富框架的使用场景。
从设计上来看,泛化调用的功能还是通租凯过扩展的方式实现的,侵入性不强,值得学习借鉴。
[img]dubbo服务器线程使用情况查看
在dubbo服务器上,执行telnet可进入dubbo命令控制行:
点击回车,进入dubbo控制台
ls
显示服务列表。
ls -l
显示服务详细信息列表。
ls XxxService
显示服务的方法列表。
ls -l XxxService
显示服务的方法详细信息列表。
ps
显示服务端口列表。
ps -l
显示服务地址列表。
ps 20880
显示端口上的连接信息。
ps -l 20880
显示端口上的连接详细信息。
trace XxxService
跟踪没备胡1次服务任意方法的调用情况。
trace XxxService 10
跟踪10次服务任意方法的调用滚知情况。
trace XxxService xxxMethod
跟踪1次服务方法的调用情况
trace XxxService xxxMethod 10
跟踪10次服务方法枯拦的调用情况。
Dubbo 协议
Dubbo是 Alibaba 开源的分布式服务框架远程调用框架,在网络间传输数据,就需要通信协议和序列化。
Dubbo支持dubbo、rmi、hessian、http、webservice、thrift、redis等多种协议,但是Dubbo官网是推荐我们使用Dubbo协议的,默认也是用的dubbo协议。
先介绍几种常见的协议:
缺省协议,使用基于mina1.1.7+hessian3.2.1的tbremoting交互。
连接个数:单连接
连接方式:长连接乎带
传输协议:TCP
传输方式:NIO异步传输
序列化:Hessian二进制序列化
适用范围:传入传出参数数据包较小(建议小于100K),消费者比岩谈提供者个数粗顷碰多,单一消费者无法压满提供者,尽量不要用dubbo协议传输大文件或超大字符串。
适用场景:常规远程服务方法调用
1、dubbo默认采用dubbo协议,dubbo协议采用单一长连接和NIO异步通讯,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况
2、他不适合传送大数据量的服务,比如传文件,传视频等,除非请求量很低。
配置如下:
dubbo:protocol name="dubbo" port="20880" /
dubbo:protocol name=“dubbo” port=“9090” server=“netty” client=“netty” codec=“dubbo”
serialization=“hessian2” charset=“UTF-8” threadpool=“fixed” threads=“100” queues=“0” iothreads=“9”
buffer=“8192” accepts=“1000” payload=“8388608” /
3、Dubbo协议缺省每服务每提供者每消费者使用单一长连接,如果数据量较大,可以使用多个连接。
dubbo:protocol name="dubbo" connections="2" /
4、为防止被大量连接撑挂,可在服务提供方限制大接收连接数,以实现服务提供方自我保护
dubbo:protocol name="dubbo" accepts="1000" /
Java标准的远程调用协议。
连接个数:多连接
连接方式:短连接
传输协议:TCP
传输方式:同步传输
序列化:Java标准二进制序列化
适用范围:传入传出参数数据包大小混合,消费者与提供者个数差不多,可传文件。
适用场景:常规远程服务方法调用,与原生RMI服务互操作
RMI协议采用JDK标准的java.rmi.*实现,采用阻塞式短连接和JDK标准序列化方式 。
基于Hessian的远程调用协议。
连接个数:多连接
连接方式:短连接
传输协议:HTTP
传输方式:同步传输
序列化:表单序列化
适用范围:传入传出参数数据包大小混合,提供者比消费者个数多,可用浏览器查看,可用表单或URL传入参数,暂不支持传文件。
适用场景:需同时给应用程序和浏览器JS使用的服务。
1、Hessian协议用于集成Hessian的服务,Hessian底层采用Http通讯,采用Servlet暴露服务,Dubbo缺省内嵌Jetty作为服务器实现。
2、Hessian是Caucho开源的一个RPC框架: ,其通讯效率高于WebService和Java自带的序列化。
基于http表单的远程调用协议。参见:[HTTP协议使用说明]
连接个数:多连接
连接方式:短连接
传输协议:HTTP
传输方式:同步传输
序列化:表单序列化
适用范围:传入传出参数数据包大小混合,提供者比消费者个数多,可用浏览器查看,可用表单或URL传入参数,暂不支持传文件。
适用场景:需同时给应用程序和浏览器JS使用的服务。
基于WebService的远程调用协议。
连接个数:多连接
连接方式:短连接
传输协议:HTTP
传输方式:同步传输
序列化:SOAP文本序列化
适用场景:系统集成,跨语言调用
序列化是将一个对象变成一个二进制流就是序列化, 反序列化是将二进制流转换成对象
为什么要序列化?
Dubbo序列化支持java、compactedjava、nativejava、fastjson、dubbo、fst、hessian2、kryo,其中默认hessian2。其中java、compactedjava、nativejava属于原生java的序列化。
hessian2序列化:hessian是一种跨语言的高效二进制序列化方式。但这里实际不是原生的hessian2序列化,而是阿里修改过的,它是dubbo RPC默认启用的序列化方式。
json序列化:目前有两种实现,一种是采用的阿里的fastjson库,另一种是采用dubbo中自己实现的简单json库,但其实现都不是特别成熟,而且json这种文本序列化性能一般不如上面两种二进制序列化。
java序列化:主要是采用JDK自带的Java序列化实现,性能很不理想。
dubbo 中使用 ThreadLocal 隐患
在 Dubbo 中使用 ThreadLocal ,如果采用默认的设置,每次 Dubbo 调用结束,Dubbo 处理响应线程并不会被销毁, 而是归还到迅没线程池中。而从 ThreadLocal 源码可裤唯以看出,每次我们设置的值其实会存在位于 Thread 中 ThreadLocalMap 变量中。
这就导致,下次如果 Dubbo 处理响应恰好继续使用到这个线程,该线程就能调用到上次响应中设置在 ThreadLocal 设置的值。这就引起内存泄露,可能还会导致业务上异常。其实并不止在 Dubbo 中,该案例还会发生在 web项目中,只要相关使用线程池的,都有可能发生。
dubbo 默认采用单一长连接加线程池方式处理调用。
默认采取 Dispatcher=all 的分发策略,所有消息都派发到线程池,包括请求,响应,连接事件,断开事件,心跳等。
线程池在缺省配置为固定大小线程池,启动时建立线程,不关闭,一直持有。胡昌培
使用 Threadlocal,我们需要注意几点:
调整线程池大小配置是
dubbo.protocol.threads = 5000
调整线程池类型配置是
dubbo.protocol.threadpool = cached
调整事件处理方式配置是
dubbo.protocol.dispatcher = message
或者
dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" /
关于dubbo使用和dubbo使用nacos的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。