一、服务模块的设计方式
模块调用链:controller->facade->biz->dao
二、服务模块的接口类型
2.1 简单的数据查询接口
controller.facade、dao(例根据Id查询记录)
2.2 带业务逻辑的数据查询接口
controller、facade、biz、dao(复杂的查询，带业务逻辑)
2.3 简单的数据写入接口
controller、facade、dao(简单数据插入)
2.4 带业务逻辑的数据写入接口
controller、facade、biz、dao(有业务逻辑的数据处理)
2.5 同步接口、异步接口
控制业务操作逻辑的幂等性。
三、SOA服务化接口设计原则
3.1 服务接口尽可能大粒度
- 每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将地面临分布式事务问题，
- Dubbo暂未提供分布式事务支持，同时可以减少系统间的网络交互
3.2 服务接口建议以业务场景为单位划分
- 并对相近的业务做抽象,防止接口数量爆增(爆炸)。
例:某一个接口有多个实现，做成一个接口，再在dubbo分组中多实现 - 不建议使用过于抽象的通用接口，如Map query(Map),这样的接口没有明确语义，会给后期维护带来不便
3.3 接口版本及分组
- 每个接口应定义版本号，为后续不兼容升级提供可能
<dubbo:service interface="com.xxService" version="1.0"/>- 合并所有分组
<dubbo:reference interface="com.xxx.MenuService" group="*" merger="true" />- 合并指定分组
<dubbo:reference interface="com.xxx.MenuService" group="aaa,bbb" merger="true" />3.4 接口隔离原则
查询接口与业务操作接口独立接口类名,以便于区分，以及容错处理使用不同策略
- 查询接口：幂等，可以设置失败重试为2，即失败了可以重试调用2次
- 业务操作接口：非幂等，需要控制分布式事务，并设置失败不能重试
3.5 接口兼容性
- 服务接口增加方法，或服务模型增加字段，可向后兼容；
- 删除方法或删除字段，将不兼容，枚举类型新增字段也不兼容，需要通过变更版本号升级。
3.6 异常处理
注意：在事务处理方法中不能调用dubbo查询及dubbo数据处理方法
（涉及到数据处理及远程调用，统一使用RocketMQ进行消息发送）
- 建议使用异常汇报错误，而不是返回错误码，异常信息能携带更多的信息，以及语义更友好。
- 如果担心性能问题，在必要时，可以通过override掉异常类的finlllnStackTrace()方法为空方法，使其不拷贝栈信息。
- 查询方法不建议抛出checked异常，否则调用方在查询 时将过多的try…catch,并且不能进行有效处理。
- 服务提供方不应将DAO或者SQL等异常抛给消费方，应在服务实现中对消费方不关心的异常进行包装，否则可能出现消费方无法反序列化相应异常
- 必要的接口输入参数校验(aop+注解实现)
在Provider上尽量多配置Consumer端属性
扫描二维码关注公众号，回复：
2600443 查看本文章
原因如下:
- 作为服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，并发控制数量，负载均衡 ，等等
- 在Provider配置后，Consumer不配置则会使用Provider的配置值 ，
即Provider配置可以作为Comsumer的缺省值，否则，Consumer会使用Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的 - Provider上尽量多配置Consumer端的属性，让Provider实现者一开始就思考Provider服务特点、服务质量的问题
样例:
3.7 异步通知接口需保持幂等
- 接收外部的异步通知接口必须支持幂等
- 通过数据库唯一性约束保证。