Java后端微服务研发规范

技术栈说明

在编写研发规范时,需要一定的技术栈说明,我们这里明确使用到的技术有:JDK8、SpringBoot、Dubbo、Zookeeper、MySQL5.7、MyBatis/MyBatisPlus、Redis、RabbitMQ、MongoDB、ELK、Sentry。

项目分层说明

项目分层说明
  • 前后端分离
  1. 前端采用AntDesign for Vuejs Pro
  2. 微前端架构:在一个基座上承载多个SPA应用,基座上有一些基础的能力,每个应用还可以导出组件和能力。
  • 后端微服务
  1. interfaces:包含dto\enums\publicservice-interface。其中enums中放本模块中的所有枚举类。如果不需要向外界提供RPC服务,就没有dto和publicservice
  2. services: 传统单体应用所有内容,包含vo, entity, controller, serviceInterface, serviceImpl,repository, dao, mapper, RabbitMQ\Redis\ES,publicserviceImpl。
    • vo: 定义前端接口的输入输出。
    • entity: 定义表的实体类,和数据库表一一对应。这里使用MyBatisPlus减少简单SQL的编写,提高开发效率。
    • controller: MVC controller层。
    • serviceInterface: 定义单体服务层接口。
    • serviceImpl: 单体服务层实现
    • dao: MyBatisPlus接口层。
    • repository: MyBatisPlus数据访问实现层,避免在单体服务层出现大量dao层的操作代码。也可以是RabbitMQ\Redis\ES操作数据的Repository实现类。
    • mapper: MyBatisPlus复杂查询的SQL Map。

项目分层编码说明

采用自上而下的逻辑说明每一个逻辑分层的主要职责。

  • 配置层:Web层相关配置、各自框架的JavaConfig、业务配置BusinessConfig等配置类。
  • Controller层:负责登录状态验证、权限验证、统一异常处理、统一返回值包装、LoginUser信息赋值、HTTP层缓存处理、输入验证等。只有此层可以从Cookie或Token中获取登录用户的状态,其他层只能依赖上层传递过来的入参来处理。
  • Dubbo Service层:Dubbo接口放在interfaces中,实现放在publicservice中,供其他领域服务调用。
  • 单体Service层:分接口和实现两个类,比如SystemUserService\SystemUserServiceImpl。主要负责业务逻辑处理、本地缓存或Redis缓存处理。如果是数据库资源操作相关代码比较多,建议下沉封装到Repository层,确保服务层主要描述业务逻辑。
  • Repository层: Dao接口或Redis, ES, MongoDB的包装,将相关资源操作逻辑代码封装在这里。
  • Dao层:MyBatisPlus层的接口。
  • Mapper: MyBatisPlus的Mapper文件,主要是需要定制化的一些SQL。使用了MyBatisPlus后,另一部分简单的CRUD操作不需要编写SQL。
  • Entity:放在services实现层中,定义表的实体类,和数据库表一一对应。
  • DTO: 放在interfaces接口层。只有需要向其他领域暴露服务的才有interfaces层。
  • VO: 放在services实现层,负责Web层的输入输出。该层可以按领域来划分包,做到清晰明了。

Web 层规范

在Web层,我们最需要处理的就是登录校验(@HasAuth)、权限校验(@HasFuction)、数据绑定(@RequestBody, @RequestParam)、数据校验(SpringValidation+HibernateValidator, @Validated, @Valid)、登录信息注入下传(@ControllerAdrivce+@InitBinder)、统一异常处理(@ControllerAdrivce+@ExceptionHandler)、统一返回结果DtoResult(@ControllerAdvice+ ResponseBodyAdvice)。

DubboService(publicservice)层规范

命名规范

  • 实体命名规范
    Service/DAO & 领域模型等命名规约:XxxDTO, XxxEntity, XxxEnum, XxxConstants, XxxService, XxxServiceImpl, XxxServiceProxy
    dto:XxxDTO
    entity: XxxEntity
    查询条件:XxxQueryFilter
    分页查询条件: XxxPageQueryFilter
    复合查询结果:XxxQueryResult

  • 方法命名规范:

    1. 分页查询列表时方法使用pageList开头,查询总数使用pageCount开头。
    2. 不分页查询列表使用list开头。
    3. 查询单个数据可以使用get开头,如getXX。
    4. 指定某个属性进行操作可以使用getByXX、deleteByXX、updateByXX。
  • 数据库命名规范

  1. 通用字段: 数据表必须有的几个字段:Id, CommonStatus, InUserId, InUserName, InDate, EditUserId, EditUserName, EditUserDate。CommonStatus标记数据有效性 0:无效,1:有效
  2. 数据表名用小写+下划线分割,字段名用UpperCamelCase风格命名(大驼峰法,单词首字母大写,比如通用字段CommonStatus)
  3. 业务逻辑唯一的字段或字段组织必须增加唯一索引确保唯一性,比如项目应用关联关系表project_intelli_app(Id, ProjectId, AppId, ..., CommonStatus,InUserId, InUserName, InDate, EditUserId, EditUserName, EditUserDate)中的字段组合ProjectId+AppId+CommonStatus必须唯一,那么一定要加上唯一索引UIX_ProjectId_AppId_CommonStatus(ProjectId,AppId,CommonStatus)
  4. 尽量做到字段不为空。让代码逻辑更清楚,比如避免OR\UNION ALL等。


    尽量做到字段不为空

基类实体定义

  • 基类BaseVO
# 当前登录人的信息
Long userId
String userName
String userOrganizatonId;
String userOrganizatonCode;
  • 基类UpdateStatusVO:BaseVO
# 单据系统编号
Long Id
# 数据状态
CommonStatusEnum commonStatus
  • 分页查询基础QueryFilterVO
  • 基类BaseEntity
# 单据系统编号
Long Id
# 数据状态
CommonStatusEnum commonStatus

# 操作人的信息
Long inUserId
String inUserName
Long editUserId
String editUserName

其中的commonStatus\inUserId\inUserName\editUserId\editUserName使用MyBatisPlus的自动填充机制进行填充。

现在的项目都是前后端分离的。关于VO\DTO是否需要同时存在,我一直比较纠结。最终我发现,他们两个存在一定的重复性,我建议还是不要VO, 统一保留DTO和Entity两个概念就可以了。

项目具体结构

Maven Module 一般分为:

  1. xxx-xx-business #业务逻辑和数据访问层
  2. xxx-xx-interface #微服务相关
  3. xxx-xx-protal #前端相关
  4. xxx-xx-job #定时任务
  • Business Module
src/main/java/com/xxx/xxx/.../business #包目录 根据业务定义路径
  /config #配置类目录
    ...
  /constant #常量类 存放业务定义的各种常量
    ...
  /dao #存放数据访问层接口
    ...
  /mapper #Mybatis Mapper文件
    ...
  /entity #实体类目录 存放和数据库表结构一直的实体类
    ...
  /enums #枚举类目录
    ...
  /sevice # service层目录 存放service接口和实现
    /impl #存放接口实现类
    ...
  /util #工具类目录
    ...
  /dto #存放dto类
    XXXQueryFilter #dao层查询使用的QueryFilter类,`*XXX*`和对应实体类命名一致
    XXXQueryResult #dao层查询返回结果包装类,`XXX`和对应实体类命名一致
    XXXVo #前端与Controller交互的Vo类,`XXX`和对应实体类命名一致
    ...
  • Interface Module
src/main/java/com/xxx/xxx/.../interfaces #包目录 根据业务定义路径
  /dto #数据传输对象目录,用于微服务间数据传输
    ...
  /constant #常量类,接口使用的常量
    ...
  /enums #枚举类目录,接口使用的枚举
    ...
  /service #微服务接口目录
    ...
  • Portal Module
src/main/java/com/xxx/xxx/.../portal #包目录 根据业务定义路径
 /config #配置类目录
    ...
 /controller #Controller层目录,按业务划分子目录,url前面需要带上路径 /api/XX XX为应用简称
    ...
 /microservice #微服务接口的实现,url前面需要带上路径 /ms/XX
    ...
 /mobile # 移动端api目录,按业务划分子目录,url前面需要带上路径 /m/XX 
    ...
 /filter #过滤器
    ...
 /interceptor #拦截器
    ...
src/test/ #测试用例目录
src/main/resources #存放配置文件或其他非Java类资源
  • Job Module
src/main/java/com/xxx/xxx/.../job #包目录 根据业务定义路径
  /config #配置类目录
    ...
  /task #定时任务目录,根据业务定义子目录
    ...
src/test/ #测试用例目录
src/main/resources #存放配置文件或其他非Java类资源

异常处理

在Web层统一处理,不允许直接吞掉异常。
线上常出现的异常主要有以下几种
NullPointerException:
SQLSyntaxErrorException:
SQLIntegrityConstraintViolationException:Column 'EntryApprove' cannot be null
MysqlDataTruncation:Data truncation: Data too long for column 'ApprovalDesc' at row 1
TooManyResultsException:Expected one result (or null) to be returned by selectOne(), but found: 2
TimeoutException:
最难搞的是Zookeeper、Appollo、Netty等通信类异常。

参考资料

  • SpringBoot系列(十)优雅的处理统一异常处理与统一结果返回
  • SpringBoot 统一异常处理和统一数据返回
  • springboot 统一返回数据格式和异常处理
  • SpringBoot系统列 4 - 常用注解、拦截器、异常处理
  • Spring Validation最佳实践及其实现原理,参数校验没那么简单!
  • 看看别人后端API接口写得,那叫一个优雅!
  • SpringBoot 拦截器、过滤器、监听器、定时器使用
  • https://juejin.cn/post/6844903911715782669
  • https://juejin.cn/post/6872226869605826573
  • 什么是接口的幂等性,如何实现接口幂等性?一文搞定
  • https://juejin.cn/post/6937533353914531876

你可能感兴趣的:(Java后端微服务研发规范)