业务代码编写规范标准

1、关于mq业务使用规范：

• a）、virtual host 命名根据业务模块来（例如成交，virtual host=dealinvite）
• b）、队列命名，第一选项根据业务分类，第二阶段 功能模块，第三阶段动作（例如：成交邀约阶段系统消息未读推送，dealinvite.message.system.noread）
• c）、业务消息消费统一写在相应的业务模块下的mq。（例如，成交模块，dealinvite_mq）
• d）、现有的mq服务 统一走java bean注解，不要在xml文件配置注解。
• e）、重要的业务模块消费失败的消息一定要备份起来。（涉及到金钱）
• f）、mq队列命名资源无需写在配置文件中。
• g）、mq消费失败的异常不要捕获直接丢弃给框架处理。
• h)、mq的消费者和生产者必须在同一个业务分类下进行。

2、关于redis使用规范：

• a）、key值命名规范，第一选项根据业务分类，第二阶段 功能模块，第三阶段动作。（成交邀约阶段车主手机号码标记，dealinvite:caruser:auctionId:mobile:）
• b）、所有的key必须有生命周期，最长的时间不超过7天，视具体情况定。（设置TTL过期时间）

3、关于job任务使用规范：

• a）、单个sql执行的时间尽量控制到120ms范围标准。
• b）、单个sql执行的返回结果集最大不能超过200条。
• c）、job任务描述项尽可能详细清晰。
• d）、一次性消费job使用完毕后需要回收，不能使用表达式做下线。
• e）、cron表达式发生修改，一定要在配置文件中进行调整，不要直接通过es-job控制台直接操作。

4、关于系统日志消息使用规范：

• a）、按照日志等级输出要求来定义输出日志（消息输出的：info,错误日志：error）。
• b）、对日志输出需要进行过滤，与业务无关的消息体不要做输出。（400~600之间的业务状态信息需要处理，那么区间外的业务信息就不要输出）
• c）、输出的日志要有意义，没有必要对所有的结果都做输出操作，记录输出有意义的结果。
• d）、错误的业务日志一定要输出，对系统的运行的错误信息，以及自定义异常信息都要进行输出。

5、业务代码编写规范：

• a)、所有的输入参数使用前都必须进行非空判断。
• b)、外部的接口或者内部微服务调用需要有重试补偿机制，以及失败处理机制。
• c)、微服务客户端调用必须接入熔断机制，服务端需要提供熔断限制。
• d)、业务代码编写公共方法不能有else if的逻辑判断。
• e)、业务代码调用链单一层级深度限制在5以内。
• f)、老的业务代码开发或者问题修复，如果涉及多方调用，需要将当前的调用链单独剥离出来。

6、DAO层SQL规范

• a)、sql尽量减少数据库函数的使用，在查询方面能够提示效率。
• b)、sql层尽可能的少业务逻辑判断。
• c)、sql的函数和service的函数一对一实现。