服务子系统的数量把控
过多:可能划分过细,破坏业务子系统的独立性(如:支付订单、退款订单,用户、账户);部署维护工作量大,独立进程占用内存多
过少:没能很好的解耦;开发维护不好分工;升级维护影响面大
服务子系统划分注意事项
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服务特点、服务质量的问题。