dubbo服务划分和接口设计原则(五)
1.服务划分
服务化的目标：
将系统中独立的业务模块抽取出来，按业务的独立性进行垂直划分，抽象出基础服务层。
服务化的目标：
服务化的目标：基础服务为上游业务的功能实现提供支撑，基础服务应用本身无状态，可随着系统的负荷灵活伸缩来提供服务能力。
服务子系统的数量把控
过多：可能划分过细，破坏业务子系统的独立性（如：支付订单、退款订单，用户、账户）部署维护工作量大，独立进程占用内存多
过少：没能很好的解耦开发维护不好分工升级维护影响面大
（以简易版支付系统服务的划分为例）服务子系统划分注意事项：
不要出现A服务中的SQL需要链接查询到B服务中的表等情况，这样在A服务与B服务进行垂直拆库时就会出错。（一旦分库分表就 会出错）
服务子系统间避免出现环状的依赖调用服务子系统间的依赖关系链不要过长尽量避免分布式事务
服务子系统的划分是一个不断优化的过程
2.Dubbo服务接口设计
action、facade、biz、dao
好的Dubbo服务接口设计，并非只是纯粹的接口服务化
2.1接口类型
简单数据查询接口：action、facade、dao
带业务逻辑的数据查询接口：action、facade、biz、dao
简单的数据写入接口：action、facade、dao
带业务逻辑的数据写入接口：action、facade、biz、dao
同步接口异步接口
2.2设计原则接口粒度
服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将面临分布式事务问题，Dubbo暂未提供分布式事务支持。同时可以减少系统间的网络交互。
服务接口建议以业务场景为单位划分，并对相近业务做抽象，防止接口数量爆炸。
不建议使用过于抽象的通用接口，如：Mapquery(Map)，这样的接口没有明确语义，会给后期维护带来不便。
2.3设计原则接口版本
每个接口都应定义版本号，为后续不兼容升级提供可能，如：
<dubbo:serviceinterface="com.XxService" version="1.0" />
2.4设计原则接口兼容性
服务接口增加方法，或服务模型增加字段，可向后兼容；删除方法或删除字段，将不兼容，枚举类型新增字段也不兼容，需通过变更版本号升级。
2.5设计原则异常处理
建议使用异常汇报错误，而不是返回错误码，异常信息能携带更多信息，以及语义更友好。
如果担心性能问题，在必要时，可以通过override掉异常类的 fillInStackTrace()方法为空方法，使其不拷贝栈信息。
查询方法不建议抛出checked异常，否则调用方在查询时将过多的try...catch，并且不能进行有效处理。
服务提供方不应将DAO或SQL等异常抛给消费方，应在服务实现中对消费方不关心的异常进行包装，否则可能出现消费方无法反序列化相应异常。