dubbo

dubbo

方式

xml配置

• 疑问

  • 大佬的案例中没有加@EnableDubbo注解，而且@Service注解也是用的spring的，直接通过@Importresource注解导入xml文件就可以

注解配置

• 也是没有加@EnableDubbo注解，不过@service注解已经用的是Dubbo提供的了，这里和官网是有出入的
• 官网说的是@EnableDubbo 必须配置。

大佬更推荐的是xml配置

参数校验

1. 推荐参考官方的
2. 消费者开启参数校验，请求参数校验不通过时，结束请求，不会向服务提供者发起请求
3. 提供者开启参数校验，请求参数校验不通过时，结束请求，不会执行后续的业务逻辑

自定义实现拓展点

​ Dubbo SPI 机制

整合 Nacos

整合 Sentinel

DubboFallback

​ sentinel-apache-dubbo-adapter 支持配置全局的 fallback 函数，可以在 Dubbo 服务被 Sentinel 限流/降级/负载保护的时候，进行相应的 fallback 处理。

设计 RPC 接口时，你有考虑过这些吗？

旧 RPC 接口的痛点

• 查询接口过多

  • 使用单参 +Specification 模式，降低重复的查询方法，大大降低接口中的方法数量。

• 难以扩展

  • 单参设计其实无形中包含了所有的查询条件的排列组合，可以直接在 app 实现逻辑的新增，而不需要对 api 进行改动（如果是参数的新增则必须进行 api 的升级，参数的废弃可以用 @Deprecated 标准）。

• 升级困难

  • 以 module 为版本演进的粒度。api 和 app 单独演进，减少调用者的不必要升级次数。

• 难以测试

  • 单参数设计 + 自动化测试工具，打造良好的开发体验。

    • 可以通过 Dubbo 接口自动生成 HTTP 接口，体现了单参数设计的兼容性之强
    • 兼容 HTTP 后，我们只需要做一些微小的工作，便可以实现 Swagger 对 Dubbo 接口的可视化测试。
    • 自动生成 TestNG 集成测试代码和缺省测试用例，这使得服务端接口集成测试变得异常简单

• 异常设计不合理

  • Checked Exception+ 正确异常处理姿势，使得代码更加优雅，降低了调用方不处理异常带来的风险。

参考文章地址：cnkirito.moe/rpc-interface-design/

重试次数

1. 通过注解/xml进行固定配置
2. 通过上下文进行运行时动态配置
3. Dubbo 默认会进行额外的最多2次重试

集群容错

Failover Cluster

• 失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries=“2” 来设置重试次数(不含第一次)

Failfast Cluster

• 快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录

Failsafe Cluster

• 失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作

Failback Cluster

• 失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作

Forking Cluster

• 并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks=“2” 来设置最大并行数

Broadcast Cluster

• 广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息

负载均衡

Random LoadBalance

• 随机，按权重设置随机概率

RoundRobin LoadBalance

• 轮询，按公约后的权重设置轮询比率

LeastActive LoadBalance

• 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差

ConsistentHash LoadBalance

• 一致性 Hash，相同参数的请求总是发到同一提供者

线程模型

直接在 IO 线程上处理

• 事件处理的逻辑能迅速完成，并且不会发起新的 IO 请求，比如只是在内存中记个标识

派发到线程池

• 处理逻辑较慢，或者需要发起新的 IO 请求，比如需要查询数据库，则必须派发到线程池，否则 IO 线程阻塞，将导致不能接收其它请求

如果用 IO 线程处理事件，又在事件处理过程中发起新的 IO 请求，比如在连接事件中发起登录请求，会报“可能引发死锁”异常，但不会真死锁。

需要通过不同的派发策略和不同的线程池配置的组合来应对不同的场景