Dubbo分布式服务框架整理

Dubbo  为分布式系统框架   底层RPC原理

Dubbo分层

Service层: Provider(服务提供者) 和 Consumer(消费者)  ,由自己开发的接口

config层:  配置文件

proxy层:  代理,通过代理 负责provider,consumer之间互相通信,(无论consumer还是provider都需要代理)

registry层: 注册, provider注册自己作为一个服务,consumer去注册中心找要调的服务

cluster层: 一个provider可以部署在多台机器上,多个provider组成一个集群_cluster

monitor层: 监控层,监控provider被调用等信息

protocol层: 负责具体provider和consumer的通信

exchange层: 信息交换

serilaze层: 序列化

服务之间通信原理

1.  服务提供者向注册中心注册自己

2. 服务消费者从注册中心发现服务

3. 服务消费者通过动态代理创建代理类 来执行操作

4. 通过cluster负载均衡选择合适的服务机器来通信

5. 通过protocol选择对应的通信协议 (http协议 dubbo协议)

6. 通过exchange 封装request

7. 将请求序列化

8. 通过网络IO框架通信(Mina/Netty)

9.服务提供者通过代理类获取请求  

注册中心挂了还可以继续通信,consumer本地有缓存 可以知道去哪找provider

Dubbo支持的通信协议

dubbo协议: 特点  长连接 + NIO异步通信 + hession序列化协议

http协议:

hessian协议:

长连接:建立一个永久连接,能持续发送请求

短连接:没发一次请求建立一次连接 请求结束断开

Dubbo负载均衡策略

对于同一个provider在多个机器上的请求分发

1. 顺序分发,按顺序雨露均沾到每台机器上

2.random loadbalance  随即分发,根据不同的机器性能调整权重 

3.根据哈希路由,取模到对应的机器 (网关有一个负载均衡策略就是ip路由)

4.自动感知,某个机器性能越差,越不活跃,接到的请求就越少

集群容错策略

1.failover cluster模式  :失败自动切换,自动重试其他机器    常用于读操作

2.failfast cluster模式 : 一旦调用失败就立即失败   常用于写操作

3.failsafe cluster模式 : 出现异常时忽略掉   常用于日志服务等不重要调用

4.forking cluster模式 : 只要一个成功就立即返回

5.fallback cluster模式 : 失败了自动记录 然后定时重发  常用于消息队列这种

动态代理

默认使用javassist动态字节码生成,创建代理类

(可以通过SPI扩展机制培植自己的动态代理策略)

Dubbo SPI

Dubbo的SPI机制:

Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();

在Dubbo自己的jar中,/META_INF/dubbo/internal/com.alibaba.dubbo.rpc.Protocol文件中 的配置信息:

  dubbo = com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol

  http = com.alibaba.dubbo.rpc.protocol.http.HttpProtocol

  hession = com.alibaba.dubbo.rpc.protocol.hession.HessionProtocol

自己扩展SPI时:自己写个工程,打成jar包

在src/main/resources目录下,搞个META_INF/services 

自己写个Protocol文件,Protocol文件里写 my = com.fuck.Myfuck

把jar包引入到dubbo 的provider的工程中,配置<dubbo:Protocol name="my" port="20000"/>

Dubbo服务治理,降级,重试

服务治理:

1.生产各个服务之间调用链路图,多个服务之间复杂调用关系图

2.各服务接口之间访问延迟,访问压力

3. 服务间调用失败处理

重试机制:

失败重试,

超时重试

服务降级:
服务调用失败几次 或者特定失败 做降级(返回个null或者做其他逻辑处理返回个结果)

保证幂等性:

1.通过唯一标识做幂等性保证,例如订单id,重复的请求相同的订单id不做处理。数据库唯一键插入失败 整个事务回滚

2.在缓存中加一个状态标识,每次请求先查redis看看状态标识是否存在了

保证消息顺序性:
1.基于分布式锁zookeper锁  每一个请求调用前都会尝试去获取zookeper锁,如果该请求未按顺序来的 则获取失败,再来下一个请求来尝试获取锁

原文地址:https://www.cnblogs.com/ttaall/p/13553069.html