rpc、dubbo基础知识

 全文字数 2248 阅读约 5 分钟

如何设计一个 RPC 框架

大致上一个 RPC 框架需要做的就是约定通信协议,序列化的格式,一些容错机制,负载均衡策略,监控运维和一个注册中心。

服务消费者

我们先从消费者方(调用方)来看看需要什么,首先消费者面向接口编程,所以需要知道有哪些接口可以调用,可以通过公用 jar 包的方式来维护接口。

知道了有哪些接口可以调用了,但是光有接口,具体的实现怎么来?具体的实现怎么来?必须交给框架处理了!所以还需要一个代理类,让消费者只管调,其他交给代理搞定。

但你还要记得,告诉代理你调用的哪个方法,参数的值是什么。

虽然代理帮你搞定了,但是代理也不知道自己到底要调用哪个机子上的远程方法,所以需要有个注册中心,这样调用方从注册中心可以知晓可以调用哪些服务提供方,一般而言提供方不止一个,毕竟只有一个挂了那就集体爆炸?

所以提供方一般是集群部署,那调用方需要通过负载均衡来选择一个调用,可以通过某些策略,例如机房优先调用啥的。

当然还需要容错机制,毕竟是远程调用,网络是不可靠的,所以可能需要重试什么的。

还要和服务提供方约定一个协议,例如我们就用 HTTP 来通信好了,也就是大家都说中文,不然可能听不懂了。

序列化也是必要的,毕竟我们本地的结构是”立体“的,需要序列化之后才能传输,因此还需要约定序列化格式。

服务提供者

服务提供者肯定要实现对应的接口。

然后需要把自己的接口暴露出去,向注册中心注册自己,暴露自己能提供的服务。

有消费者请求过来需要处理,提供者需要和消费者协商好的协议来处理这个请求,然后反序列化。

序列化完的请求扔到线程池里面做处理,某个线程接受到这个请求之后找到对应的实现调用,然后再将结果原路返回。

注册中心

这东西就相当于一个平台,大家在上面暴露自己的服务,也砸爱上面得知自己能调用哪些服务。

它还能做配置中心,将配置集中化处理,动态变更通知订阅者。

监控运维

面对众多的服务,精细化的监控和方便的运维必不可少。

dubbo 简介

Dubbo 是一个基于 Java 的开源 RPC 框架。在 2019 年正式成为 Apache 顶级项目。

它实现了面向接口的代理 RPC 调用,并且可以配合 ZooKeeper 等组件实现服务注册和发现功能,并且拥有负载均衡、容错机制等。

dubbo 总体架构

1599999924000image.png

一些注意点

注册中心和监控中心是可选的,你可以直接在配置文件里面写,然后提供方和消费方直连。

注册中心、提供方、消费方之间都是长连接,和监控方不是长连接,并且消费方是直接调用提供方,不经过注册中心。

消费者有本地缓存提供者的信息,因此注册中心、监控中心宕机了也不会影响已经正常运行的提供者和消费者。

dubbo 分层架构

总的而言非为三层,再细分下去,有十层。

1599999996000image.png

大的三层分别为 Business(业务层)、RPC层、Remoting,并且还分为 API 层和 SPI 层。

分为大三层其实是和我们知道的网络分层一样的意思,层次分明、职责边界清晰才能更好的扩展。

而分 API 层和 SPI 层这是 dubbo 成功的一点,采用微内核设计 + SPI扩展,使得定制的二次开发更方便。

具体看一下每一层都是干嘛的。
• Service,业务层,咱们的业务逻辑层

• Config,配置层,主要围绕 ServiceConfig 和 ReferenceConfing (引用配置),初始化配置信息

• Proxy,代理层,服务提供者还是消费者都会生成一个代理类,使得服务接口透明化,代理层做远程调用和返回结果

• Register,注册层,封装了服务注册和发现

• Cluster,路由和集群容错层,负责选取具体调用的节点,处理特殊的调用要求和负责远程调用失败的容错措施

• Monitor,监控层,负责监控统计调用时间和次数

• Portocol,远程调用层,主要封装 RPC 调用

• Exchange,信息交换层,用来封装请求响应模型,同步转异步

• Transport,网络传输层,抽象了网络传输的统一接口

• Serialize,序列化层,将是数据序列化成二进制流,也搞反序列化

阅读 38发布于 2020-09-06 23:38:04
哈希表内部博客,转载请联系说明!