dubbo
方式
xml配置
-
疑问
- 大佬的案例中没有加@EnableDubbo注解,而且@Service注解也是用的spring的,直接通过@Importresource注解导入xml文件就可以
注解配置
- 也是没有加@EnableDubbo注解,不过@service注解已经用的是Dubbo提供的了,这里和官网是有出入的
- 官网说的是@EnableDubbo 必须配置。
大佬更推荐的是xml配置
参数校验
- 推荐参考官方的
- 消费者开启参数校验,请求参数校验不通过时,结束请求,不会向服务提供者发起请求
- 提供者开启参数校验,请求参数校验不通过时,结束请求,不会执行后续的业务逻辑
自定义实现拓展点
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/
重试次数
- 通过注解/xml进行固定配置
- 通过上下文进行运行时动态配置
- 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 线程阻塞,将导致不能接收其它请求