8、Dubbo协议 服务调用
8.1 服务端 启动过程深入分析
我们查看一下服务启动的过程
ProtocolFilterWrapper.export
好我们进入DubboProtocol.export
创建服务
分析我们的Handler
我们接着返回刚才位置
下面的super方法里面会创建服务,ChannelHandlers.wrap会对hander进一步包装
1、我们进入ChannelHandlers.wrap
MultiMessageHandler—>HeartbeatHandler---->AllChannelHandler -> DecodeHandler -> HeaderExchangeHandler -> ExchangeHandlerAdapter
我看看一下super创建服务
NettyServerhandler -> NettyServer -> MultiMessageHandler—>HeartbeatHandler---->AllChannelHandler -> DecodeHandler -> HeaderExchangeHandler -> ExchangeHandlerAdapter
8.2 服务端调用过程
我们知道请求过来通过Netty服务一定是Handler的处理,下面就是整个过程
NettyServerHandler -> NettyServer -> MultiMessageHandler—>HeartbeatHandler---->AllChannelHandler -> DecodeHandler -> HeaderExchangeHandler -> ExchangeHandlerAdapter
NettyServerHandler
MultiMessageHandler
HeartbeatHandler
AllChannelHandler
https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/advanced-features-and-usage/performance/threading-model/provider/
DecodeHandler
HeaderExchangeHandler
ExchangeHandlerAdapter
这里是调用我们的目标invoker,但是这里目标invoker被filter给包装了,所以先要调用filter
我们自定义过滤器就会在这里起作用
调用完毕过滤器就会调用到AbstractProxyInvoker#invoke
8.3 客户端调用
会调用JavassistProxyFactory#getProxy获取代理类
调用的时候一定会调用到InvokerInvocationHandler.invoker的方法
调用过程会有容错负载均衡FailoverClusterInvoker#doInvoke
我们可以简单看一下负载均衡
HeaderExchangeChannel#request发送请求
HeaderExchangeHandler#received处理返回数据
9、Triple协议
9.1 背景
在Dubbo2.7中,默认的是Dubbo协议,因为Dubbo协议相比较于Http1.1而言,Dubbo协议性能上是要更好的。
但是Dubbo协议自己的缺点就是不通用,假如现在通过Dubbo协议提供了一个服务,那如果想要调用该服务就必须要求服务消费者也要支持Dubbo协议。
而随着企业的发展,往往可能会出现公司内部使用多种技术栈,可能这个部门使用Dubbo,另外一个部门使用Spring Cloud,另外一个部门使用gRPC,那此时部门之间要想相互调用服务就比较复杂了,所以需要一个通用的、性能也好的协议,这就是Triple协议。
9.2 Triple协议介绍
Triple 是 Dubbo3 提出的基于 HTTP2 的开放协议,旨在解决 Dubbo2 私有协议带来的互通性问题。另外,Google公司开发的gRPC,也基于的HTTP2,目前gRPC是云原生事实上协议标准,包括k8s/etcd等都支持gRPC协议。
9.3 HTTP1 和HTTP2进行对比
9.3.1 HTTP1
POST /getName HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 27username=john&password=1234
我们会发现我们除了username=john&password=1234 数据之外,其他的内容都是额外信息,并且这些额外信息量很大。
9.3.2 HTTP2
-
帧长度,用三个字节来存一个数字,这个数字表示当前帧的实际传输的数据的大小,3个字节表示的最大数字是2
的24次方(16M),所以一个帧最大为9字节+16M。
-
帧类型,占一个字节,可以分为数据帧和控制帧
- DATA:用于传输请求和响应中的数据,包含有效载荷(payload)。
- HEADERS:用于传输HTTP头部信息,包含有效载荷(payload)。
- PRIORITY:用于指定数据流的优先级,包含与数据流相关的信息。
- RST_STREAM:用于指示数据流的中止,并通知原因。
- SETTINGS:用于传输HTTP/2连接的配置参数。
- PUSH_PROMISE:用于服务端推送资源,包含预期的请求头和有效载荷。
- PING:用于检测HTTP/2连接的可用性和延迟时间。
-
标志位,占一个字节,可以用来表示当前帧是整个请求里的最后一帧,方便服务端解析、
-
流标识符,占4个字节,在Java中也就是一个int,不过最高位保留不用,表示Stream ID,这也是HTTP2的一个重要设计
-
实际传输的数据Payload,如果帧类型是HEADERS,那么这里存的就是请求头,如果帧类型是DATA ,那么这里
存的就是请求体
通过这种设计,我们可以发现,我们就可以来压缩请求头了,比如如果帧的类型是HEADERS ,那就进行压缩,当然压缩算法是固定的HPACK算法,不能更换。
9.4 Triple源码分析
通过学习Dubbo协议,我们首先要知道我们启动服务的应该是在TripleProtocol
9.4.1 客户端处理
调到TripleInvoker.doInvoke
发送数据
发送数据包括请求头和请求体
发送请求头
这里我们数据会放到队列,最后会调用到HeaderQueueCommand#doSend方法,发送数据
放入队列
先放到队列,然后会定时flush的时候进行处理
下面我们可以看到,当我发现有数据就会一直取知道128个后才发送,如果poll为空,则走下面内容数据不为空则发送
刷新后则调用到HeaderQueueCommand#doSend方法
下面发送请求体和完成,与上面发送请求头都是异步处理,代码一样只是最后调用处理不同
发送数据
上图我们可以看出,也是异步处理,最终会调用到DataQueueCommand#doSend方法
发送完成数据
最终会调用感到EndStreamQueueCommand.doSend方法
9.4.2 服务端启动
进入启动Netty的源码
这里有个处理器NettyPortUnificationServerHandler,我们这里有的decode方法,他会识别我们是不是HTTP2协议
怎样识别HTTP2协议?
如果要建立的是一个HTTP2连接,那么在建立完Socket连接后,客户端立刻会发送一个连接前言,也就是一串字节
(对应的字符串为:“PRI*HTTP/2.0\r\n\r\nSM\r\n\r\n”), 给到服务端,服务端从而知道要建立的是HTTP2
如果识别出RECOGNIZED,
处理数据
处理请求头
获取invoker
启动监听器
这里处理请求头获取了Invoker和对应的listener:UnaryServerCallListener 处理请求内容中会用到
处理请求
处理请求体
这里只是给我们invoker设置了参数,但是没有立刻调用,而是在complete中进行调用
处理完成帧
10、扩展点SPI
10.1 概念
SPI是一种软件编程模型,用于实现在运行时动态加载和扩展组件的能力。在Dubbo3中,SPI机制被广泛应用于扩展框架功能,允许用户自定义实现各种接口,以满足业务需求。
Java中的SPI机制
我们使用Mybatis操作数据库,那我们应该使用怎样操作mysql 或者oracle或者DB2呢? 首先我们应该引入对应的Mysql的jar,我们利用这jar才能操作数据库,那对于JDBC操作DriveMananger获取链接的时候,他怎样获取Mysql的jar包中对应的类,来链接mysql呢
实例:
加载对应的配置
缺点:我们如果对应配置文件中com.msb.dubbo.provider.SPI.JDK.Course配置多个实现类,但是我们只需要EnglishCourse,所以为了效率我们只应该加载EnglishCourse,但是JDK的SPI会把所有的加载掉,所以Dubbo退出自己的SPI
Dubbo3 SPI演示
Wrapper包装(AOP)