Java进阶5-Dubbo

cmyshare

已于 2023-01-06 23:55:50 修改

阅读量631

点赞数

分类专栏： Java 文章标签： dubbo java 分布式

于 2023-01-06 23:42:21 首次发布

本文链接：https://blog.csdn.net/qq_43517845/article/details/128586555

版权

Java 专栏收录该内容

15 篇文章 2 订阅

订阅专栏

1、Dubbo是什么

Apache Dubbo 是一款高性能、轻量级的开源 Java RPC 框架。Dubbo 提供了六大核心能力：

面向接口代理的高性能RPC调用。
智能容错和负载均衡。
服务自动注册和发现。
高度可扩展能力。
运行期流量调度。
可视化的服务治理与运维。

2、Dubbo有哪些模块组成

Dubbo架构图

上述节点简单介绍以及他们之间的关系：

Container： 服务运行容器，负责加载、运行服务提供者。必须。
Provider： 暴露服务的服务提供方，会向注册中心注册自己提供的服务。必须。
Consumer： 调用远程服务的服务消费方，会向注册中心订阅自己所需的服务。必须。
Registry： 服务注册与发现的注册中心。注册中心会返回服务提供者地址列表给消费者。非必须。
Monitor： 统计服务的调用次数和调用时间的监控中心。服务消费者和提供者会定时发送统计数据到监控中心。非必须。

下图是 Dubbo 的整体设计，从下至上分为十层，各层均为单向依赖。

service 层：接口层，给服务提供者和消费者来实现的
config 配置层：Dubbo相关的配置。支持代码配置，同时也支持基于 Spring 来做配置，以 ServiceConfig, ReferenceConfig 为中心
proxy 服务代理层：调用远程方法像调用本地的方法一样简单的一个关键，真实调用过程依赖代理类，以 ServiceProxy 为中心。
registry 注册中心层：封装服务地址的注册与发现。
cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心。
monitor 监控层：RPC 调用次数和调用时间监控，以 Statistics 为中心。
protocol 远程调用层：封装 RPC 调用，以 Invocation, Result 为中心。
exchange 信息交换层：封装请求响应模式，同步转异步，以 Request, Response 为中心。
transport 网络传输层：抽象 mina 和 netty 为统一接口，以 Message 为中心。
serialize 数据序列化层 ：对需要在网络传输的数据进行序列化。

3、Dubbo工作原理

服务启动的时候，provider和consumer根据配置信息，连接到注册中心register，分别向注册中心注册和订阅服务
register根据服务订阅关系，返回provider信息到consumer，同时consumer会把provider信息缓存到本地。如果信息有变更，consumer会收到来自register的推送
consumer生成代理对象，同时根据负载均衡策略，选择一台provider，同时定时向monitor记录接口的调用次数和时间信息
拿到代理对象之后，consumer通过代理对象发起接口调用
provider收到请求后对数据进行反序列化，然后通过代理调用具体的接口实现

4、Dubbo优缺点

Dubbo 帮助我们解决了什么问题呢？

负载均衡 ：同一个服务部署在不同的机器时该调用哪一台机器上的服务。
服务调用链路生成 ：随着系统的发展，服务越来越多，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。Dubbo 可以为我们解决服务之间互相是如何调用的。
服务访问压力以及时长统计、资源调度和治理 ：基于访问压力实时管理集群容量，提高集群利用率。
…

另外，Dubbo 除了能够应用在分布式系统中，也可以应用在现在比较火的微服务系统中。

Dubbo缺点：
1、只支持JAVA语言
2、强一致性，以ZooKeeper 为注册中心，Zookeeper 保证的是CP ，但对于服务发现而言，可用性比数据一致3性更加重要，而 Eureka 设计则遵循AP原则。
3、Dubbo只是实现了服务治理，其他组件需要另外整合以实现对应的功能。如分布式配置、服务跟踪、批量任务

5、如何设计一个RPC框架

遇到这类问题，起码从你了解的类似框架的原理入手，自己说说参照 dubbo 的原理，你来设计一下，举个例子，dubbo 不是有那么多分层么？而且每个分层是干啥的，你大概是不是知道？那就按照这个思路大致说一下吧：
方案1：

首先需要一个服务注册中心，这样consumer和provider才能去注册和订阅服务
需要负载均衡的机制来决定consumer如何调用客户端，这其中还当然要包含容错和重试的机制
需要通信协议和工具框架，比如通过http或者rmi的协议通信，然后再根据协议选择使用什么框架和工具来进行通信，当然，数据的传输序列化要考虑
除了基本的要素之外，像一些监控、配置管理页面、日志是额外的优化考虑因素。

方案2：

上来你的服务就得去注册中心注册吧，你是不是得有个注册中心，保留各个服务的信息，可以用 zookeeper 来做，对吧。
然后你的消费者需要去注册中心拿对应的服务信息吧，对吧，而且每个服务可能会存在于多台机器上。
接着你就该发起一次请求了，咋发起？当然是基于动态代理了，你面向接口获取到一个动态代理，这个动态代理就是接口在本地的一个代理，然后这个代理会找到服务对应的机器地址。
然后找哪个机器发送请求？那肯定得有个负载均衡算法了，比如最简单的可以随机轮询是不是。
接着找到一台机器，就可以跟它发送请求了，第一个问题咋发送？你可以说用 netty 了，nio 方式；第二个问题发送啥格式数据？你可以说用 hessian 序列化协议了，或者是别的，对吧。然后请求过去了。
服务器那边一样的，需要针对你自己的服务生成一个动态代理，监听某个网络端口了，然后代理你本地的服务代码。接收到请求的时候，就调用对应的服务代码，对吧。