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: 27
username=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)



10.2源码分析




















