Dubbo的接口设计&编写规范

接口类型
设计原则
接口兼容性
异常处理
Specification 模式解决接口爆炸问题
- 单参数易于管理
接口异常设计

Dubbo的接口设计&编写规范

action->facade->biz->dao

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

接口类型

同步&异步

简单的数据查询接口:action -> facade -> dao(例根据Id查询记录)
带业务逻辑的数据查询接口:action -> facade -> biz -> dao(复杂的查询，带业务逻辑)
简单的数据写入接口：action -> facade -> dao(简单数据插入)
带业务逻辑的数据写入接口:action -> facade ->biz -> dao(有业务逻辑的数据处理)

设计原则

服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将地面临分布式事务问题
Dubbo暂未提供分布式事务支持，同时可以减少系统间的网络交互
服务接口建议以业务场景为单位划分，并对相近的业务做抽象,防止接口数量爆增(爆炸)。
不建议使用过于抽象的通用接口，如Map query(Map),这样的接口没有明确语义，会给后期维护带来不便
给每个接口默认分配一个版本, 方便升级维护

接口兼容性

服务接口增加方法，或服务模型增加字段，可向后兼容
删除方法或删除字段，将不兼容，枚举类型新增字段也不兼容，需要通过变更版本号升级

异常处理

建议使用异常汇报错误，而不是返回错误码，异常信息能携带更多的信息，以及语义更友好。
如果担心性能问题，可以通过override掉异常类的finlllnStackTrace()方法为空方法，使其不拷贝栈信息。
查询方法不建议抛出checked异常, 或者说让Consumer尽量减少接受异常的种类
Provider上尽量多配置Consumer端的属性, 让Provider实现者一开始就思考Provider服务特点、服务质量的问题

简单聊下

Specification 模式解决接口爆炸问题

public interface UserMainProvider {
    UserMainDTO findByUserId(Long userId);
    UserMainDTO findByUsername(String username);
    List<UserMainDTO> listByUsername(Long username);
    List<UserMainDTO> listByNickname(Long nickname);
}

先不要纠结我有没有写注释, 像这样的接口书写方式,后期业务复杂的话肯定会出现接口爆炸的情况

我们可以这样修改:

public interface UserMainProvider {

    UserMainDTO findByUsername(UserMainSpec spec);
    List<UserMainDTO> listByUsername(UserMainSpec spec);
    PageInfo<UserMainDTO> page(UserMainPageSpec spec);

}

如果你了解领域驱动设计，会发现这里借鉴了其中 Specification 模式的思想。不清楚自行google吧

单参数易于管理

我们可以定义个抽象父类,方便做一些统一的做一些东西, 例如公用参数, 切面对象等等

@Data
public abstract class RpcSpecification<T> implements Serializable {
    private static final long serialVersionUID = 1L;

    /** 追溯ID */
    private String traceId;
    /** 操作类型*/
    private OperationTypeEnum operationType;
    /** client IP */
    private String clientIP;
    /** client name */
    private String clientName;
}