Dubbo服务接口的设计原则

接口粒度：

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

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

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

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

接口版本：

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

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

接口兼容性：

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

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

异常处理：

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

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

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

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

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

作为服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数等

在Provider配置后，Consumer不配置则会使用Provider的配置值，即Provider配置可以作为Consumer的缺省值。

否则，Cousumer会使用Consumer端的全局设置，这对于Provider来说不可控，且往往是不合理的

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