Dubbo高级篇_07_Dubbo服务接口的设计原则

1 、设计方式

action->facade->biz->dao

好的Dubbo服务接口设计,并非只是纯粹的接口服务化

2.接口类型

简单的数据查询接口:action.facade、dao(例根据Id查询记录)

带业务逻辑的数据查询接口:action、facade、biz、dao(复杂的查询,带业务逻辑)

简单的数据写入接口:action、facade、dao(简单数据插入)

带业务逻辑的数据写入接口:action、facade、biz、dao(有业务逻辑的数据处理)

同步接口

异步接口

3.设计原则

服务接口尽可能大粒度,每个服务方法应代表一个功能,而不是某功能的一个步骤,否则将地面临分布式事务问题,

Dubbo暂未提供分布式事务支持,同时可以减少系统间的网络交互


服务接口建议以业务场景为单位划分,并对相近的业务做抽象,防止接口数量爆增(爆炸)

例:某一个接口有多个实现,做成一个接口,再在dubbo分组中多实现


不建议使用过于抽象的通用接口,如Map query(Map),这样的接口没有明确语义,会给后期维护带来不便



接口版本:

每个接口应定义版本号,为后续不兼容升级提供可能

如:

<dubbo:service interface="com.xxService" version="1.0"/>


接口兼容性:

服务接口增加方法,或服务模型增加字段,可向后兼容;

删除方法或删除字段,将不兼容,枚举类型新增字段也不兼容,需要通过变更版本号升级。


异常处理:

建议使用异常汇报错误,而不是返回错误码,异常信息能携带更多的信息,以及语义更友好。


如果担心性能问题,在必要时,可以通过override掉异常类的finlllnStackTrace()方法为空方法,使其不拷贝栈信息。


查询方法不建议抛出checked异常,否则调用 方在查询 时将过多的try...catch,并且不能进行有效处理。


服务提供方不应将DAO或者SQL等异常抛给消费方,应在服务实现中对消费方不关心的异常进行包装,否则可能出现消费方无法反序列化相应异常


必要的接口输入参数校验


在Provider上尽量多配置Consumer端属性:

原因如下:

作为服务的提供者,比服务使用方更清楚服务性能参数,如调用的超时时间,合理的重试次数,并发控制数量,负载均衡 ,等等

在Provider配置后,Consumer不配置则会使用Provider的配置值 ,

即Provider配置可以作为Comsumer的缺省值,否则,Consumer会使用Consumer端的全局设置,这对于Provider不可控的,并且往往是不合理的


Provider上尽量多配置Consumer端的属性,让Provider实现者一开始就思考Provider服务特点、服务质量的问题

样例:



  • 5
    点赞
  • 16
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 3
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

有恒则成

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值