目录
什么是dubbo?为什么要用?
dubbo的使用场景和核心功能?
dubbo核心组件
dubbo服务注册与发现的流程
dubbo与spring的关系
dubbo与springCloud的区别
dubbo有哪些注册中心?
dubbo使用的什么通讯框架?
dubbo如果注册中心宕机,发布者与订阅者之间还能通信吗?
dubbo负载均衡策略
dubbo容错处理方案
dubbo超时设置方式
dubbo支持协议
dubbo服务降级
dubbo启动时支持几种配置方式
dubbo在安全机制方面如何解决
dubbo连接注册中心和直连的区别
dubbo用到了哪些设计模式?
dubbo是一款高性能、轻量级的开源rpc分布式服务框架,提供了服务自动注册、自动发现等高效服务治理方案,可以和spring无缝集成。
dubbo为了解决随着服务化进一步发展,服务越来越多、服务之间调用越来越复杂,而诞生的架构体系,使远程方法调用透明化,只需要简单配置就能像调用本地方法一样调用远程方法。
1.透明化的远程方法调用
2.负载均衡与容错
3.服务自动注册与发现
1.服务提供者
2.服务消费者
3.注册中心
4.监控中心
5.容器
1.容器启动运行服务提供者
2.提供者启动注册服务
3.消费者订阅所需服务
4.注册中心返回提供者地址给消费者
5.消费者通过负载均衡机制选择提供者
6.消费者和服务者的调用次数与时间发送到监控中心
Dubbo 采用全 Spring 配置方式,透明化接入应用,对应用没有任何API 侵入,只需用 Spring 加载 Dubbo 的配置即可,Dubbo 基于Spring的扩展进行加载
1.SpringCloud是采用Http协议做远程调用,接口一般是Rest风格;Dubbo是采用Dubbo协议,格式固定
2.SpringCloud定位为微服务架构下的一站式解决方案;Dubbo 关注点主要在于服务的调用和治理
3.SpringCloud依托于Spring平台,具备更加完善的生态体系;而Dubbo一开始只是做RPC远程调用,生态相对匮乏
Zookeeper、Redis、Multicast、Simple,推荐使用 Zookeeper 作为注册中心(zookeeper本身是可以负载均衡的 dubbo也可以负载均衡 。但是当结合负载均衡 容灾自动恢复。扩展服务器等等。会让dubbo更健全)
默认使用 Netty 作为通讯框架
可以通信。启动dubbo时,消费者会从zookeeper拉取生产者的地址接口等数据缓存到本地,每次通用时按照本地的存储地址进行调用
常用4种,默认随机策略
1.随机策略
2.轮询策略
3.最少活跃调用策略
4.一致hash策略
1.失败自动切换,重试其他服务器
2.失败立即报错
3.失败直接忽略
4.失败自动恢复
5.并行调用多个服务器,只要返回一个即可
6.广播调用所有服务提供者,任意一台报错即报错
dubbo 在调用服务不成功时,默认是会重试两次。
有两种超时设置方案
1.提供者端设置(推荐在服务端配置,因为服务提供者比消费者更清楚自己提供的服务特性)
2.消费者端设置(消费者端设置了超时时间,以消费者端为主,即优先级更高)
推荐使用dubbo协议
dubbo:单一长连接和 NIO 异步通讯,适合大并发小数据量的服务调用,以及消费者远大于提供者
rmi:传输参数和返回参数对象需要实现
serializable:使用阻塞式短连接,传输数据包大小混合,消费者和提供者个数差不多
webService:多个短连接,基于 HTTP 传输,同步传输,适用系统集成和跨语言调用
http:基于http表单提交的远程调用服务
hessian:传入参数较大,提供者大于消费者,提供者压力较大,可传文件
memcache:基于 Memcache实现的 RPC 协议
redis:基于redis实现rpc协议
有两种方式:内置Mock和自定义Mock方法
内置Mock:设置 mock=“return null”或其他
自定义Mock方法:服务接口名+Mock后缀,实现服务接口
xml、注解、属性、api
Dubbo 通过 Token 令牌防止用户绕过注册中心直连,然后在注册中心上管理授权。Dubbo 还提供服务黑白名单,来控制服务所允许的调用
方
连接注册中心:通过注册中心来管理和维护服务提供者与服务消费者之间的关系
直连:服务消费者直接与指定的服务提供者建立连接,跳过注册中心的过程
连接注册中心通过注册中心的管理和调度,提供了服务自动发现、负载均衡、状态管理和监控等丰富的功能;而直连模式通过简化部署和配置、减少网络开销等方面,提供了更高的灵活性和性能
Dubbo 框架在初始化和通信过程中使用了多种设计模式,可灵活控制类加载、权限控制等功能
工厂模式
装饰器模式
观察者模式
动态代理模式