根据接口类型划分
- 简单的数据查询接口:action facade dao
- 带业务逻辑的数据查询接口:action facade biz dao
- 简单的数据写入接口:action facade dao
- 带业务逻辑的数据写入接口:action facade biz dao
- 同步接口
- 异步接口
设计原则
接口粒度
服务接口尽可能大粒度,每个服务方法应代表一个功能,而不是某功能的一个步骤,否则将地面临分布式事务问题,Dubbo暂未提供分布式事务支持,同时可以减少系统间的网络交互
服务接口建议以业务场景为单位划分,并对相近的业务做抽象,防止接口数量爆增(爆炸)。
例:某一个接口有多个实现,做成一个接口,再在dubbo分组中多实现
不建议使用过于抽象的通用接口,如Map query(Map),这样的接口没有明确语义,会给后期维护带来不便
接口版本:
每个接口应定义版本号,为后续不兼容升级提供可能
如:
<dubbo:service interface="com.xxService" version="1.0"/>
接口兼容性:
服务接口增加方法,或服务模型增加字段,可向后兼容;
删除方法或删除字段,将不兼容,枚举类型新增字段也不兼容,需要通过变更版本号升级。
异常处理:
建议使用异常汇报错误,而不是返回错误码,异常信息能携带更多的信息,以及语义更友好。
如果担心性能问题,在必要时,可以通过override掉异常类的finlllnStackTrace()方法为空方法,使其不拷贝栈信息。
查询方法不建议抛出checked异常,否则调用 方在查询 时将过多的try…catch,并且不能进行有效处理。
服务提供方不应将DAO或者SQL等异常抛给消费方,应在服务实现中对消费方不关心的异常进行包装,否则可能出现消费方无法反序列化相应异常
必要的接口输入参数校验
在Provider上尽量多配置Consumer端属性: