Dubbo有哪些注册中心
-
Zookeeper
-
采用Zookeeper的watch机制。
-
Redis
-
key/map存储，基于Redis的发布/订阅模式。
Dubbo 的注册中心集群挂掉，发布者和订阅者之间还能通信么？
- 可以通讯。启动 Dubbo 时，消费者会从 Zookeeper 拉取注册的生产者的地址接口等数据，
缓存在本地。每次调用时，按照本地存储的地址进行调用。
Dubbo负载均衡策略
- Random ：随机策略，可动态调整权重
- RoundRobin：轮询选取，平均分布，有可能请求累计
- LeastActive：最少活跃调动策略，慢提供者接收更少的请求
- ConstantHash：一致性hash，相同参数的请求发到同一个提供者
Dubbo的集群容错方案
- Failover Cluster：失败自动切换，出现失败重试其他服务器
- Failfast Cluster：快速失败，只发起一次调用，失败立即报错
- Failsafe Cluster：失败安全，出现异常直接忽略
- Failback Cluster：失败自动恢复，后台记录失败请求，定时重发
- Forking Cluster：并行调用多个服务器，只要有一个成功即可，通常用于实时性要求高的读操作，但比较浪费资源。
- Broadcast Cluster：广播调用所有提供者，逐个调用，任意一台报错则报错。
Dubbo序列化方式
- hession
- java二级制序列化
- json
- SOAP
RPC原理及实现
远程过程调用 Remote Procedure Call
- Server 暴露服务的服务提供方
- Client 调用远程服务的服务消费方
- Registry 注册中心
设计RPC
大致流程如下：
- Provider启动，然后向注册中心注册自己所能提供的服务
- Consumer启动，然后向注册中心订阅自己所需的服务
- 注册中心将元信息通知给Consumer
- Consumer可以通过负载均衡选择一个服务来使用
详细从各个服务方的角度来看，又有很多组成
-
服务消费者
-
消费方需要知道哪些接口可以调用，
导入公用jar包的方式来维护接口 -
知道接口可以调用了，具体如何调用，需要一个
代理类来搞定调用，只需要告诉代理类调用的哪个方法和参数的值 -
代理类调用，需要知道调用的哪个机子，所以
需要一个注册中心，这样调用方就知道有哪些服务方了 -
为了保证高可用，提供方一般都是集群部署，所以需要有
一些负载均衡的策略（轮询，权重，最少活跃，一致性hash） -
为了保证高可用，还需要
有容错机制（默认失败自动接环，还有直接失败，快速失败，失败安全，失败恢复，并行调用，广播调用等） -
调用服务方需要通信，所以需要
定义一个通信协议（http、tcp） -
传输对象，需要将对象转成二进制，需要约定
序列化格式（默认hessian、http、webservice、soap、rmi） -
中间可能还有一些额外的处理，可以
插入一些filter来统一处理，mdc或调用计数器等 -
服务提供者
-
实现对应的接口 -
向注册中心注册自己 -
反序列化接收参数和序列化返回结果 -
高可用的集群部署和容错机制 -
注册中心
-
服务方在上面暴露服务，订阅服务
-
动态变更通知订阅者
Dubbo协议有哪些
-
通信协议
-
默认dubbo协议，hessian序列化，单一长连接,NIO异步通信，为了支持高并发场景，调用量上亿次，长连接较合适，传输协议tcp
-
http协议，传输协议http
-
rmi，走java二进制序列化，多个短链接适合消费者提供者数量差不多
-
hession，走hession序列化，多个短链接，适用于提供者数量比消费者多的
-
webservice，走SOAP文本序列化
-
序列化协议
-
hession
-
java二进制序列化
-
json
-
SOAP
Dubbo和springcloud的异同
- dubbo采用的是传输层tcp协议，会序列化后使用二进制传输，占用带宽较少，springcloud是应用层http协议，占用带宽更多，同时使用json传输
- dubbo采用的是长链接适合传输数据量较少的，而对于springcloud是短链接，适合传输大数据量的信息
- dubbo开发依赖jar包，对依赖管理比较复杂，springcloud的接口协议比较松散，约束性不强。
- 注册中心不同，dubbo是zk，springcloud是eureka
