Dubbo分布式服务子系统的划分以及Dubbo服务接口的设计原则

服务子系统的数量把控

      过多：可能划分过细，破坏业务子系统的独立性（如：支付订单、退款订单，用户、账户）；部署维护工作量大，独立进程占用内存多
      过少：没能很好的解耦；开发维护不好分工；升级维护影响面大

服务子系统划分注意事项

      1、不要出现A服务中的SQL需要链接查询到B服务中的表等情况，这样在A服务与B服务进行垂直拆库时就会出错
      2、服务子系统间避免出现环状的依赖调用
      3、服务子系统间的依赖关系链不要过长
      4、尽量避免分布式事务

Dubbo服务接口的设计原则

      1、接口类型

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

       2、接口粒度

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

      3、接口版本

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

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

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

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