dubbo——基础

最新推荐文章于 2023-01-05 10:14:00 发布

linkingfei

最新推荐文章于 2023-01-05 10:14:00 发布

阅读量122

点赞数

分类专栏： # dubbo

本文链接：https://blog.csdn.net/linkingfei/article/details/105260014

版权

dubbo 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

一、dubbo作用

1、问题

rpc调用，服务url地址（http\tcp\rmi）
服务负载均衡nginx\f5\lvs
服务依赖关系复杂
每个服务的监控

2、解决

软负载均衡
容错机制
服务注册与发现
服务治理：rpc地址管理

3、调用原理

在这里插入图片描述

4、dubbo admin

作用

服务治理、服务管理
统计、日志管理
容错机制、服务降级
负载均衡、路由策略
权限、权重、注册发现

在这里插入图片描述

5、Dubbo实现负载均衡、容错机制

负载均衡原理

客户端取模算法

容错机制

在这里插入图片描述

5、dubbo的升级版dubbx

dubbo协议

dubbo\http\redis\hession\rmi

dubbx协议

rest协议, http+restful+json

6、dubbo面试

dubbo原理
和zk使用
dubbo与dubbx区别
dubbo协议
dubbo使用zk作为注册中心
dubbo支持多协议
springcloud使用eureka
springcloud只支持http协议
springcloud带有zuul网关、分布式注册中心

二、dubbo原理

1 dubbo是什么

dubbo是一个分布式框架，远程服务调用的分布式框架，其核心部分包含：

集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
远程通讯：提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
自动发现：基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

2 dubbo相关问题

2.1 服务调用超时问题怎么解决

dubbo在调用服务不成功时，默认是会重试两次的。这样在服务端的处理时间超过了设定的超时时间时，就会有重复请求，比如在发邮件时，可能就会发出多份重复邮件，执行注册请求时，就会插入多条重复的注册数据，那么怎么解决超时问题呢？如下

对于核心的服务中心，去除dubbo超时重试机制，并重新评估设置超时时间。
业务处理代码必须放在服务端，客户端只做参数验证和服务调用，
不涉及业务流程处理全局配置实例

2.2 Dubbo 集群的负载均衡有哪些策略

Dubbo 提供了常见的集群策略实现，并预扩展点予以自行实现。

Random LoadBalance: 随机选取提供者策略，有利于动态调整提供者权重。截面碰撞率高，调用次数越多，分布越均匀；
RoundRobin LoadBalance: 轮循选取提供者策略，平均分布，但是存在请求累积的问题；
LeastActive LoadBalance: 最少活跃调用策略，解决慢提供者接收更少的请求；
ConstantHash LoadBalance: 一致性 Hash 策略，使相同参数请求总是发到同一提供者，一台机器宕机，可以基于虚拟节点，分摊至其他提供者，避免引起提供者的剧烈变动；

2.3 Dubbo 支持哪些协议，每种协议的应用场景

dubbo：单一长连接和 NIO 异步通讯，适合大并发小数据量的服务调用，以及消费者远大于提供者。传输协议 TCP，异步，Hessian 序列化；
rmi：采用 JDK 标准的 rmi 协议实现，传输参数和返回参数对象需要实现 Serializable 接口，使用 java 标准序列化机制，使用阻塞式短连接，传输数据包大小混合，消费者和提供者个数差不多，可传文件，传输协议 TCP。多个短连接，TCP 协议传输，同步传输，适用常规的远程服务调用和 rmi 互操作。在依赖低版本的 Common-Collections 包，java 序列化存在安全漏洞；
webservice：基于 WebService 的远程调用协议，集成 CXF 实现，提供和原生 WebService 的互操作。多个短连接，基于 HTTP 传输，同步传输，适用系统集成和跨语言调用；
http：基于 Http 表单提交的远程调用协议，使用 Spring 的 HttpInvoke 实现。多个短连接，传输协议 HTTP，传入参数大小混合，提供者个数多于消费者，需要给应用程序和浏览器 JS 调用；
hessian：集成 Hessian 服务，基于 HTTP 通讯，采用 Servlet 暴露服务，Dubbo 内嵌 Jetty 作为服务器时默认实现，提供与 Hession 服务互操作。多个短连接，同步 HTTP 传输，Hessian 序列化，传入参数较大，提供者大于消费者，提供者压力较大，可传文件；
memcache：基于 memcached 实现的 RPC 协议
redis：基于 redis 实现的 RPC 协议

2.4、在使用过程中都遇到了些什么问题

本地调用不能注册：配置具体的注册地址
未实现序列化接口

2.5 默认使用什么序列化框架

默认使用 Hessian 序列化，还有 Duddo、FastJson、Java 自带序列化。
hessian是一个采用二进制格式传输的服务框架，相对传统soap web service，更轻量，更快速。

2.6、默认使用的是什么通信框架，还有别的选择吗?
默认也推荐使用 netty 框架，还有 mina。

三、 HTTP & RPC区别

HTTP主要是位于TCP/IP协议栈的应用层部分，首先需要构建三次握手的链接，接着才能进行数据信息的请求发送，最后进行四次挥手断开链接。
RPC在请求的过程中跨越了传输层和应用层，这是因为它本身是依赖于Socket的原因。（再深入的原因我也不知道）。减少了上边几层的封装，RPC的请求效率自然是要比HTTP高效很多。