dubbo重点知识总结

RPC工作原理

1. .Client像调用本地服务似的调用远程服务；
2. Client stub接收到调用后，将方法、参数序列化
3. 客户端通过sockets将消息发送到服务端
4. Server stub 收到消息后进行解码（将消息对象反序列化）
5. Server stub 根据解码结果调用本地的服务
6. 本地服务执行(对于服务端来说是本地执行)并将结果返回给Server stub
7. Server stub将返回结果打包成消息（将结果消息对象序列化）
8. 服务端通过sockets将消息发送到客户端
9. Client stub接收到结果消息，并进行解码（将结果消息发序列化）
10. 客户端得到最终结果。

dubbo设计架构

节点	角色说明
Provider	暴露服务的服务提供方
Consumer	调用远程服务的服务消费方
Registry	服务注册与发现的注册中心
Monitor	统计服务的调用次数和调用时间的监控中心
Container	服务运行容器

调用关系说明

1. 服务容器负责启动，加载，运行服务提供者。
2. 服务提供者在启动时，向注册中心注册自己提供的服务。
3. 服务消费者在启动时，向注册中心订阅自己所需的服务。
4. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

Dubbo超时和重连机制

dubbo启动时默认有重试机制和超时机制。
超时机制的规则是如果在一定的时间内，provider没有返回，则认为本次调用失败，
重试机制在出现调用失败时，会再次调用。如果在配置的调用次数内都失败，则认为此次请求异常，抛出异常。

超时机制
如果出现超时，通常是业务处理太慢，可在服务提供方执行：jstack PID > jstack.log 分析线程都卡在哪个方法调用上，这里就是慢的原因。如果不能调优性能，请将timeout设大。
重试机制
dubbo在调用服务不成功时，默认会重试2次。
Dubbo的路由机制，会把超时的请求路由到其他机器上，而不是本机尝试，所以 dubbo的重试机制也能一定程度的保证服务的质量。
但是如果不合理的配置重试次数，当失败时会进行重试多次，这样在某个时间点出现性能问题，调用方再连续重复调用，
系统请求变为正常值的retries倍，系统压力会大增，容易引起服务雪崩，需要根据业务情况规划好如何进行异常处理，何时进行重试。

dubbo高可用

zookeeper宕机
现象：zookeeper注册中心宕机，还可以消费dubbo暴露的服务。
原因：

1. 监控中心宕掉不影响使用，只是丢失部分采样数据
2. 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
3. 注册中心对等集群，任意一台宕掉后，将自动切换到另一台
4. 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
5. 服务提供者无状态，任意一台宕掉后，不影响使用
6. 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

Dubbo直连
在开发及测试环境下，经常需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直连方式，将以服务接口为单位，忽略注册中心的提供者列表，A 接口配置点对点，不影响 B 接口从注册中心获取列表。

注意 为了避免复杂化线上环境，不要在线上使用这个功能，只应在测试阶段使用。我们可以在开发的时候使用此方式进行调试

负载均衡
在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 random 随机调用。

负载均衡策略

• 随机，按权重设置随机概率。
• 轮询，按公约后的权重设置轮询比率。
• 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
• 一致性 Hash，相同参数的请求总是发到同一提供者。

服务降级
当我服务器的压力比较大的时候,我们可以通过服务降级功能 临时屏蔽某个出错的非关键服务，并定义降级后的返回策略,屏蔽掉不重要的服务如广告服务等,来降低核心业务的压力

我们可以直接在Admin控制台来操作服务降级,服务消费者中的屏蔽相当于不发起远程调用,
容错相当于对该服务的方法调用在失败后，再返回 null 值

参考地址