Dubbo服务接口设计原则

接口类型

简单数据查询接口： action、 facade、 dao
带业务逻辑的数据查询接口： action、 facade、 biz、 dao
简单的数据写入接口： action、 facade、 dao
带业务逻辑的数据写入接口： action、 facade、 biz、 dao
同步接口
异步接口

接口粒度：

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

接口版本：

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

接口兼容性：

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

异常处理：

• 建议使用异常汇报错误，而不是返回错误码，异常信息能携带
  更多信息，以及语义更友好。
• 如果担心性能问题，在必要时，可以通过override掉异常类的
  fillInStackTrace()方法为空方法，使其不拷贝栈信息。
• 查询方法不建议抛出checked异常，否则调用方在查询时将过
  多的try...catch，并且不能进行有效处理。
• 服务提供方不应将DAO或SQL等异常抛给消费方，应在服务实
  现中对消费方不关心的异常进行包装，否则可能出现消费方无
  法反序列化相应异常。

必要的接口输入参数校验

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

原因如下：
作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，
合理的重试次数，等等
在Provider配置后， Consumer不配置则会使用Provider的配置值，
即Provider配置可以作为Consumer的缺省值。否则， Consumer会使用
Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的。
Provider上尽量多配置Consumer端的属性，让Provider实现者一开始就思
考Provider服务特点、服务质量的问题

在Provider上尽量多配置Consumer端属性样例.png

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