我的Dubbo学习计划

最新推荐文章于 2024-04-14 12:30:26 发布

阿斌Java之路

最新推荐文章于 2024-04-14 12:30:26 发布

阅读量1.4k

点赞数 2

分类专栏： dubbo 文章标签：学习 rpc java

本文链接：https://blog.csdn.net/a972627721/article/details/124909828

版权

10 篇文章 1 订阅

订阅专栏

大家好，我是阿斌。从今天开始，我们就要开始学习一个优秀的RPC框架-Dubbo了。从大致的使用流程，再到深入探究源码，预计的学习时间是在三周左右。

在学习之前，我们可以先了解一下，一个优秀的RPC框架能够提供什么样的能力？

对调用方来说，只需要调用一个接口，而接口最终的实现，是一个屏蔽了底层细节的proxy。proxy会帮助我们将参数序列化，编码，网络传输给远程服务。在提供者端，会统一解析请求，根据映射关系找到具体的接口实现，并返回结果。

在网络传输的过程中，为了解决tcp的粘包拆包问题，我们还需要约定传输的协议，比如设置对应的协议头和协议体。协议头里会放一些整体的消息长度，这样就可以起到一个断句的效果，避免粘包拆包。因为协议体的内容都是需要反序列化的，所以协议头还会存具体的序列化方式。

另外协议体的反序列化是需要消耗cpu的，有一些请求都已经过期了，我们可以直接拒绝，而不需要浪费反序列化的cpu消耗，像这样的超时时间，我们也可以放在协议头。

调用者如何知道对应的服务提供方是谁呢？这时候就需要引入一个注册中心来统一管理所有的custom和consumer，常见的像zookeeper，nacos都可以用来作为服务的注册中心。

针对某个特定的接口，Consumer会向注册中心订阅所有的Provider的地址。如果中途有一些Provider实例异常下线了，注册中心是感知不到的，会导致Consumer访问到了下线的机器，导致请求失败。所以注册中心会和注册的机器保持心跳检测 来确保注册服务的健康。

RPC框架有很多，但是一款好的RPC框架，一定需要有服务治理的能力。随着服务的增多，对RPC框架就需要能够支持更多的业务场景。

在有多个服务提供者的时候，调用者如何选择一个进行调用，这里就涉及到了负载均衡，负载均衡会在后续的章节介绍，我们只需要知道负载均衡是在调用者那进行选择的

如果一次调用失败，有可能是某台provider的异常，我们需要能够异常重试。dubbo默认能够支持3次的重试。

如果下游的某台服务超时了，会导致上游所有直接，间接依赖这个服务的服务都出现大面积超时，为了避免这种情况，调用端需要引入超时熔断的模块，而服务端为了避免被大量的请求导致系统处理不过来，需要引入限流的模块。

随着服务链路变得越来越长，排查一个问题可能需要通知下游的下游，中间间隔很多个服务。这时候需要引入一套链路追踪的能力，标识出一次请求所调用的整个流程。

市面上的dubbo源码学习教程比较少，都是一些简单的使用教程。这也是我第一次学习一个框架，没有看视频。

接下来分享我在学习dubbo过程中发现的优质资料吧

首先最推荐的就是去看官方文档，毕竟这是阿里开源的框架，所以中文文档写的已经特别好了。所有的用法包括源码解读都有。自己去github拉一套dubbo的代码，推荐看老版本的代码，这样既保留了最初设计的思想，还不会被其他复杂的新功能看花了眼，我用的是2.6.x的版本。

专栏讲的是rpc框架在京东最近十年，架构的升级和演进，看完后，大概了解一个rpc框架最终能为我们提供哪些服务。

基本是算是源码伴读了，我跟着看完了整套服务暴露，引用，远程调用的细节。

dubbo的经典书籍，也可以搭配着使用

之前一直找不到源码视频，原来都在付费课程中。这是一位粉丝给我分享的，也就几个小时的时间，用视频大概一览dubbo的源码框架，这样对后期自己的阅读能提供很大的帮助。

接下来，就让我们进入为期三周的dubbo之旅吧！！！

关注