本篇文章以dubbo最新版本dubbo-3.0.5进行分析
- 首先跑一下dubbo-demo-spring-boot的示例,直观感受一下查看官方文档,了解dubbo3.x的变更内容(主要看了服务注册发现、Triple协议)对Dubbo消费端源码进行了分析总结逐步跟代码,找到Dubbo对Triple协议实现的地方(具体实现逻辑暂未分析)对grpc进行简单介绍并编写了demo感受了一下
- 运行demo工程,观察是否运行正常
1.1 本地启动zookeeper(充当注册中心、配置中心、元数据中心)
1.2 启动服务端ProviderApplication,暴露DemoService服务(@DubboService)
1.3 启动消费端ConsumerApplication,调用DemoService服务(@DubboReference)
下面展示Dubbo的部署架构
2.1 注册中心:服务注册和服务发现的职责
(1)支持接口级别和应用级别
(2)在Dubbo + Mesh的场景下,Dubbo注册能力弱化,不再是必须项
2.2 元数据中心:作为服务发现机制的补充
- 要启用服务发现,为Dubbo增加注册中心的配置
# application.properties dubbo registry address: zookeeper://127.0.0.1:2181Dubbo3引入全新的服务发现模型
2.1 Dubbo3 应用级服务发现,以应用粒度组织地址数据
(1)容器化微服务被编排、调度的过程即完成了在基础设施层面的注册
(2)"RPC接口"与具体的业务相关,不可能被基础设施托管
2.3 Dubbo2 接口级服务发现,以接口粒度组织地址数据
Dubbo2.x老用户如何迁移到Dubbo3.x
3.1 dubbo3.x Provider端开启双注册,来保证能同时被2.x与3.x的消费者实例发现
(1)当所有的上游消费端迁移到3.x后,提供端切换到intsance模式(只注册应用级地址)
3.2 对于 3.x 的消费者,它具备同时发现 2.x 与 3.x 提供者地址列表的能力
(1)对于双订阅的场景,消费端虽然可同时持有 2.x 地址与 3.x 地址,但选址过程中两份地址是完全隔离的:要么用 2.x 地址,要么用 3.x 地址,不存在两份地址混合调用的情况
- 以远程服务调用为入口进行分析,在调用被@DubboReference修饰的服务,调用InvokerInvocationHandler#invoke(下图展示一下自己分析的草图)
总结一下上图,Dubbo远程调用总体步骤
2.1 通过过滤器链对请求层层过滤(FilterChainBuilder#invoke)
2.2 请求通过过滤后,通过负载均衡算法在注册中心订阅的服务中选取一个提供者
2.3 对provider发起请求,处理异步结果(DubboInvoker#doInvoke)
dubbo 3.x选择兼容gRPC,以HTTP2作为传输层构建新的协议,也就是 Triple
1.1 这行描述性的文字显得冷冰冰?那dubbo3.x是怎么实现的?如果要我去实现,怎么去实现?
以dubbo-3.0.5分支的dubbo-demo-triple模块为例,启动ApiProvider服务提供者,一步一步跟代码
2.1 从ApiProvider启动发现设置协议的地方(红色标记),有设置就有使用的地方(顺藤摸瓜)
2.2 在获取协议配置的地方打上断点,观察在哪里获取配置,然后获取之后干嘛?
(1)发现在ConfigManager#refreshAll时会获取协议配置,并对ProtocolConfig属性进行赋值
(2)再打断点观察ProtocolConfig赋值属性(name、port)在哪里被调用
2.3 排除一些校验之外,最终发现真正调用的地方在ServiceConfig#doExportUrlsFor1Protocol
(1)将协议绑定到url
(2)把url暴露出去(因为协议在url中,所以一直观察url的使用,最终会跟到ServiceConfig#doExportUrl)
(3)这里dubbo提供扩展点,找到Triple协议的扩展TripleProtocol#export(重点就在PortUnificationExchanger.bind(invoker.getUrl()))
重点关注PortUnificationExchanger绑定Url
3.1 按照地址的维度(ip+port)开启服务PortUnificationServer
3.2 关注PortUnificationServer是如何绑定的(PortUnificationServer#doOpen)
(1)看下面的截图,标准的netty服务端写法,里面包含关于协议的handler:PortUnificationServerHandler
(2)服务端在接受请求,调用PortUnificationServerHandler#decode进行解码
(3)调用demo的ApiConsumer发现在解码后,会调用TripleHttp2Protocol#configServerPipeline(这里面的实现印证了上面冷冰冰的描述)
- gRPC基于定义服务的思想,指定可以远程调用的方法及其参数和返回类型默认情况下,gRPC使用protocol buffers作为接口定义语言(IDL)
2.1 用于描述服务接口和有效负载信息的结构
// 服务接口
service HelloService {
rpc SayHello (HelloRequest) returns (HelloResponse);
}
// 定义请求类型
message HelloRequest {
string greeting = 1;
}
// 定义返回类型
message HelloResponse {
string reply = 1;
}
- 下载Jar
把proto文件放在src/main/proto目录中io.grpc grpc-netty-shaded1.43.1 runtime io.grpc grpc-protobuf1.43.1 io.grpc grpc-stub1.43.1 org.apache.tomcat annotations-api6.0.53 provided
2.1 helloworld.proto、HelloWorldServer、HelloWorldClient都是拷贝的grpc-java的demo
maven中指定protoBuf的插件,然后点击编译生成代码
3.1 编译生成的代码如下图kr.motd.maven os-maven-plugin1.6.2 org.xolstice.maven.plugins protobuf-maven-plugin0.6.1 com.google.protobuf:protoc:3.19.1:exe:${os.detected.classifier} grpc-java io.grpc:protoc-gen-grpc-java:1.43.1:exe:${os.detected.classifier} compile compile-custom
分别运行HelloWorldServer、HelloWorldClient观察结果
本篇更偏向是知识点的梳理,里面具体的实现待分析。等找到合适的场景,自定义RPC协议,带着实际场景去学习



