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、异常处理
更多信息，以及语义更友好。
fillInStackTrace()方法为空方法，使其不拷贝栈信息。
多的try...catch，并且不能进行有效处理。
法反序列化相应异常
5. 设计接口时一定要保证输入参数校验通过，否则会给后续的生产者和消费方带来问题，花费大量的时间去定位
6、在Provider上尽量多配置Consumer端属性
合理的重试次数，等等
Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的。
考Provider服务特点、服务质量的问题
7、服务接口设计与服务子系统划分过程相互优化