1、接口粒度

1.1 服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将面临分布式事务问题，Dubbo暂未提供分布式事务支持。同时可以减少系统间的网络交互。

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

1.3 不建议使用过于抽象的通用接口，接口名称的定义应遵循望文生义原则，如：Map query(Map)，这样的接口没有明确语义，会给后期维护带来不便。

2、接口版本

2.1 每个接口都应定义版本号，为后续不兼容升级提供可能，如：<dubbo:service interface="com.XxService" version="1.0" />

3、接口兼容性

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

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

4、异常处理

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

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

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

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

5. 设计接口时一定要保证输入参数校验通过，否则会给后续的生产者和消费方带来问题，花费大量的时间去定位

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

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

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

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

7、服务接口设计与服务子系统划分过程相互优化