Dubbo服务规范

1前言： 在做项目的时候使用dubbo框架的一些约定，记录一下，后期其他项目使用直接借鉴，嘿嘿！
2项目命名规则
2.1 服务消费方：业务名-api，如图

2.2 服务生产方： 业务名-server ，如图：

3 项目架构

3.1.业务模型设计分为：Controller层、Service层、Manage层、Cache层、DAO层。
3.2.数据模型设计分为：DTO，DO，VO。
3.3.各模型功能描述：

• Controller层：控制层；
• Service层：单表业务；
• Manage层：多表业务；
• Cache层：缓存业务；
• DAO层：数据库访问操作；
• DTO：数据传输对象；
• DO：数据库操作对象；
• VO：视图对象；

4微服务规范

• Manage层：只允许Service层，多表，复杂业务处理。
• Service层：只允许DAO 层和Cache层和Manage层，一个Service对应一个DAO。
• Cache层：只允许DAO 层，可以封装缓存数据库的数据。
• retries重试机制默认是2，调用方根据自己的业务场景配置合适的参数，注意：添加，修改，删除操作等业务设置重试次数时要保障服务幂等性。
• 配置参数生效范围级别：方法级别>接口级别>全局配置，如果级别相等，消费方>服务方。
• 服务之间调用，避免出现循环调用，如A调用B，B调用C，C调用A，不能出现。
• 服务之间，调用方法时避免循环调用，改用批量调用，减少连接数，提高性能。如for循环调用getObjectById(int id)改为getListByIds(List ids)。
• 服务方响应超时时间默认1000ms，建议改为3000-5000ms之间，根据自己业务场景配置。
• 所有api返回的对象是 ResponseData，返回时，必须指定泛型，提高代码可读性，方便后期维护。
• api可返回DTO和VO对象，外部接口：客户端接口返回VO，内部调用：服务接口返回DTO。
• threads线程池 默认是200，根据自己的业务需求进行性能调优，该参数可以适当调大一些。 dispatcher 默认是all ，改为 message，即只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。