乐趣区

那些年我们见过的Java服务端乱象

导读

查尔斯·狄更斯在《双城记》中写道:“这是一个最好的时代,也是一个最坏的时代。”移动互联网的快速发展,出现了许多新机遇,很多创业者伺机而动;随着行业竞争加剧,互联网红利逐渐消失,很多创业公司九死一生。

笔者在初创公司摸爬滚打数年,接触了各式各样的 Java 微服务架构,从中获得了一些优秀的理念,但也发现了一些不合理的现象。现在,笔者总结了一些创业公司存在的 Java 服务端乱象,并尝试性地给出了一些不成熟的建议。

1. 使用 Controller 基类和 Service 基类

1.1. 现象描述

1.1.1.Controller 基类

常见的 Controller 基类如下:

/** 基础控制器类 */
public class BaseController {    
    /** 注入服务相关 */
    /** 用户服务 */
    @Autowired
    protected UserService userService;
    ...

    /** 静态常量相关 */
    /** 手机号模式 */
    protected static final String PHONE_PATTERN = "/^[1]([3-9])[0-9]{9}$/";
    ...

    /** 静态函数相关 */
    /** 验证电话 */
    protected static vaildPhone(String phone) {...}
    ...
}

常见的 Controller 基类主要包含注入服务、静态常量和静态函数等,便于所有的 Controller 继承它,并在函数中可以直接使用这些资源。

1.1.2.Service 基类

常见的 Service 基类如下:

/** 基础服务类 */
public class BaseService {
    /** 注入 DAO 相关 */
    /** 用户 DAO */
    @Autowired
    protected UserDAO userDAO;
    ...

    /** 注入服务相关 */
    /** 短信服务 */
    @Autowired
    protected SmsService smsService;
    ...

    /** 注入参数相关 */
    /** 系统名称 */
    @Value("${example.systemName}")
    protected String systemName;
    ...

    /** 静态常量相关 */
    /** 超级用户标识 */
    protected static final long SUPPER_USER_ID = 0L;
    ...

    /** 服务函数相关 */
    /** 获取用户函数 */
    protected UserDO getUser(Long userId) {...}
    ...

    /** 静态函数相关 */
    /** 获取用户名称 */
    protected static String getUserName(UserDO user) {...}
    ...
}

常见的 Service 基类主要包括注入 DAO、注入服务、注入参数、静态常量、服务函数、静态函数等,便于所有的 Service 继承它,并在函数中可以直接使用这些资源。

1.2. 论证基类必要性

首先,了解一下 里氏替换原则

里氏代换原则(Liskov Substitution Principle,简称 LSP):所有引用基类(父类)的地方必须能透明地使用其子类的对象。

其次,了解一下 基类的优点

  1. 子类拥有父类的所有方法和属性,从而减少了创建子类的工作量;
  2. 提高了代码的重用性,子类拥有父类的所有功能;
  3. 提高了代码的扩展性,子类可以添加自己的功能。

所以,我们可以得出以下 结论

  1. Controller 基类和 Service 基类在整个项目中并没有直接被使用,也就没有可使用其子类替换基类的场景,所以不满足里氏替换原则;
  2. Controller 基类和 Service 基类并没有抽象接口函数或虚函数,即所有继承基类的子类间没有相关共性,直接导致在项目中仍然使用的是子类;
  3. Controller 基类和 Service 基类只关注了 重用性 ,即子类能够轻松使用基类的注入 DAO、注入服务、注入参数、静态常量、服务函数、静态函数等资源。但是,忽略了这些资源的 必要性,即这些资源并不是子类所必须的,反而给子类带来了加载时的性能损耗。

综上所述,Controller 基类和 Service 基类只是一个 杂凑类,并不是一个真正意义上的基类,需要进行拆分。

1.3. 拆分基类的方法

由于 Service 基类比 Controller 基类更典型,本文以 Service 基类举例说明如何来拆分“基类”。

1.3.1. 把注入实例放入实现类

根据“使用即引入、无用则删除”原则,在需要使用的实现类中注入需要使用的 DAO、服务和参数。

/** 用户服务类 */
@Service
public class UserService {
    /** 用户 DAO */
    @Autowired
    private UserDAO userDAO;

    /** 短信服务 */
    @Autowired
    private SmsService smsService;

    /** 系统名称 */
    @Value("${example.systemName}")
    private String systemName;
    ...
}

1.3.2. 把静态常量放入常量类

对于静态常量,可以把它们封装到对应的常量类中,在需要时直接使用即可。

/** 例子常量类 */
public class ExampleConstants {
    /** 超级用户标识 */
    public static final long SUPPER_USER_ID = 0L;
    ...
}

1.3.3. 把服务函数放入服务类

对于服务函数,可以把它们封装到对应的服务类中。在别的服务类使用时,可以注入该服务类实例,然后通过实例调用服务函数。

/** 用户服务类 */
@Service
public class UserService {
    /** 获取用户函数 */
    public UserDO getUser(Long userId) {...}
    ...
}

/** 公司服务类 */
@Service
public class CompanyService {
    /** 用户服务 */
    @Autowired
    private UserService userService;

    /** 获取管理员 */
    public UserDO getManager(Long companyId) {
        CompanyDO company = ...;
        return userService.getUser(company.getManagerId());
    }
    ...
}

1.3.4. 把静态函数放入工具类

对于静态函数,可以把它们封装到对应的工具类中,在需要时直接使用即可。

/** 用户辅助类 */
public class UserHelper {
    /** 获取用户名称 */
    public static String getUserName(UserDO user) {...}
    ...
}

2. 把业务代码写在 Controller 中

2.1. 现象描述

我们会经常会在 Controller 类中看到这样的代码:

/** 用户控制器类 */
@Controller
@RequestMapping("/user")
public class UserController {
    /** 用户 DAO */
    @Autowired
    private UserDAO userDAO;

    /** 获取用户函数 */
    @ResponseBody
    @RequestMapping(path = "/getUser", method = RequestMethod.GET)
    public Result<UserVO> getUser(@RequestParam(name = "userId", required = true) Long userId) {
        // 获取用户信息
        UserDO userDO = userDAO.getUser(userId);
        if (Objects.isNull(userDO)) {return null;}

        // 拷贝并返回用户
        UserVO userVO = new UserVO();
        BeanUtils.copyProperties(userDO, userVO);
        return Result.success(userVO);
    }
    ...
}

编写人员给出的理由是:一个简单的接口函数,这么写也能满足需求,没有必要去封装成一个服务函数。

2.2. 一个特殊的案例

案例代码如下:

/** 测试控制器类 */
@Controller
@RequestMapping("/test")
public class TestController {
    /** 系统名称 */
    @Value("${example.systemName}")
    private String systemName;

    /** 访问函数 */
    @RequestMapping(path = "/access", method = RequestMethod.GET)
    public String access() {return String.format("系统 (%s) 欢迎您访问!", systemName);
    }
}

访问结果如下:

curl http://localhost:8080/test/access
系统 (null) 欢迎您访问!

为什么参数 systemName(系统名称)没有被注入值?《Spring Documentation》给出的解释是:

Note that actual processing of the @Value annotation is performed by a BeanPostProcessor.

BeanPostProcessor interfaces are scoped per-container. This is only relevant if you are using container hierarchies. If you define a BeanPostProcessor in one container, it will only do its work on the beans in that container. Beans that are defined in one container are not post-processed by a BeanPostProcessor in another container, even if both containers are part of the same hierarchy.

意思是说:@Value 是通过 BeanPostProcessor 来处理的,而 WebApplicationContex 和 ApplicationContext 是单独处理的,所以 WebApplicationContex 不能使用父容器的属性值。

所以,Controller 不满足 Service 的需求,不要把业务代码写在 Controller 类中。

2.3. 服务端三层架构

SpringMVC 服务端采用经典的三层架构,即表现层、业务层、持久层,分别采用 @Controller、@Service、@Repository 进行类注解。

表现层(Presentation):又称控制层(Controller),负责接收客户端请求,并向客户端响应结果,通常采用 HTTP 协议。

业务层(Business):又称服务层(Service),负责业务相关逻辑处理,按照功能分为服务、作业等。

持久层(Persistence):又称仓库层(Repository),负责数据的持久化,用于业务层访问缓存和数据库。

所以,把业务代码写入到 Controller 类中,是不符合 SpringMVC 服务端三层架构规范的。

3. 把持久层代码写在 Service 中

把持久层代码写在 Service 中,从功能上来看并没有什么问题,这也是很多人欣然接受的原因。

3.1. 引起以下主要问题

  1. 业务层和持久层混杂在一起,不符合 SpringMVC 服务端三层架构规范;
  2. 在业务逻辑中组装语句、主键等,增加了业务逻辑的复杂度;
  3. 在业务逻辑中直接使用第三方中间件,不便于第三方持久化中间件的替换;
  4. 同一对象的持久层代码分散在各个业务逻辑中,背离了面对对象的编程思想;
  5. 在写单元测试用例时,无法对持久层接口函数直接测试。

3.2. 把数据库代码写在 Service 中

这里以数据库持久化中间件 Hibernate 的直接查询为例。

现象描述:

/** 用户服务类 */
@Service
public class UserService {
    /** 会话工厂 */
    @Autowired
    private SessionFactory sessionFactory;

    /** 根据工号获取用户函数 */
    public UserVO getUserByEmpId(String empId) {
        // 组装 HQL 语句
        String hql = "from t_user where emp_id ='" + empId + "'";

        // 执行数据库查询
        Query query = sessionFactory.getCurrentSession().createQuery(hql);
        List<UserDO> userList = query.list();
        if (CollectionUtils.isEmpty(userList)) {return null;}

        // 转化并返回用户
        UserVO userVO = new UserVO();
        BeanUtils.copyProperties(userList.get(0), userVO);
        return userVO;
    }
}

建议方案:

/** 用户 DAO 类 */
@Repository
public class UserDAO {
     /** 会话工厂 */
    @Autowired
    private SessionFactory sessionFactory;

    /** 根据工号获取用户函数 */
    public UserDO getUserByEmpId(String empId) {
        // 组装 HQL 语句
        String hql = "from t_user where emp_id ='" + empId + "'";

        // 执行数据库查询
        Query query = sessionFactory.getCurrentSession().createQuery(hql);
        List<UserDO> userList = query.list();
        if (CollectionUtils.isEmpty(userList)) {return null;}

        // 返回用户信息
        return userList.get(0);
    }
}

/** 用户服务类 */
@Service
public class UserService {
    /** 用户 DAO */
    @Autowired
    private UserDAO userDAO;

    /** 根据工号获取用户函数 */
    public UserVO getUserByEmpId(String empId) {
        // 根据工号查询用户
        UserDO userDO = userDAO.getUserByEmpId(empId);
        if (Objects.isNull(userDO)) {return null;}

        // 转化并返回用户
        UserVO userVO = new UserVO();
        BeanUtils.copyProperties(userDO, userVO);
        return userVO;
    }
}

关于插件:

阿里的 AliGenerator 是一款基于 MyBatis Generator 改造的 DAO 层代码自动生成工具。利用 AliGenerator 生成的代码,在执行复杂查询的时候,需要在业务代码中组装查询条件,使业务代码显得特别臃肿。

/** 用户服务类 */
@Service
public class UserService {
    /** 用户 DAO */
    @Autowired
    private UserDAO userDAO;

    /** 获取用户函数 */
    public UserVO getUser(String companyId, String empId) {
        // 查询数据库
        UserParam userParam = new UserParam();
        userParam.createCriteria().andCompanyIdEqualTo(companyId)
            .andEmpIdEqualTo(empId)
            .andStatusEqualTo(UserStatus.ENABLE.getValue());
        List<UserDO> userList = userDAO.selectByParam(userParam);
        if (CollectionUtils.isEmpty(userList)) {return null;}

        // 转化并返回用户
        UserVO userVO = new UserVO();
        BeanUtils.copyProperties(userList.get(0), userVO);
        return userVO;
    }
}

个人不喜欢用 DAO 层代码生成插件,更喜欢用原汁原味的 MyBatis XML 映射,主要原因如下:

  • 会在项目中导入一些不符合规范的代码;
  • 只需要进行一个简单查询,也需要导入一整套复杂代码;
  • 进行复杂查询时,拼装条件的代码复杂且不直观,不如在 XML 中直接编写 SQL 语句;
  • 变更表格后需要重新生成代码并进行覆盖,可能会不小心删除自定义函数。

当然,既然选择了使用 DAO 层代码生成插件,在享受便利的同时也应该接受插件的缺点。

3.3. 把 Redis 代码写在 Service 中

现象描述:

/** 用户服务类 */
@Service
public class UserService {
    /** 用户 DAO */
    @Autowired
    private UserDAO userDAO;
    /** Redis 模板 */
    @Autowired
    private RedisTemplate<String, String> redisTemplate;
    /** 用户主键模式 */
    private static final String USER_KEY_PATTERN = "hash::user::%s";

    /** 保存用户函数 */
    public void saveUser(UserVO user) {
        // 转化用户信息
        UserDO userDO = transUser(user);

        // 保存 Redis 用户
        String userKey = MessageFormat.format(USER_KEY_PATTERN, userDO.getId());
        Map<String, String> fieldMap = new HashMap<>(8);
        fieldMap.put(UserDO.CONST_NAME, user.getName());
        fieldMap.put(UserDO.CONST_SEX, String.valueOf(user.getSex()));
        fieldMap.put(UserDO.CONST_AGE, String.valueOf(user.getAge()));
        redisTemplate.opsForHash().putAll(userKey, fieldMap);

        // 保存数据库用户
        userDAO.save(userDO);
    }
}

建议方案:

/** 用户 Redis 类 */
@Repository
public class UserRedis {
    /** Redis 模板 */
    @Autowired
    private RedisTemplate<String, String> redisTemplate;
    /** 主键模式 */
    private static final String KEY_PATTERN = "hash::user::%s";

    /** 保存用户函数 */
    public UserDO save(UserDO user) {String key = MessageFormat.format(KEY_PATTERN, userDO.getId());
        Map<String, String> fieldMap = new HashMap<>(8);
        fieldMap.put(UserDO.CONST_NAME, user.getName());
        fieldMap.put(UserDO.CONST_SEX, String.valueOf(user.getSex()));
        fieldMap.put(UserDO.CONST_AGE, String.valueOf(user.getAge()));
        redisTemplate.opsForHash().putAll(key, fieldMap);
    }
}

/** 用户服务类 */
@Service
public class UserService {
    /** 用户 DAO */
    @Autowired
    private UserDAO userDAO;
    /** 用户 Redis */
    @Autowired
    private UserRedis userRedis;

    /** 保存用户函数 */
    public void saveUser(UserVO user) {
        // 转化用户信息
        UserDO userDO = transUser(user);

        // 保存 Redis 用户
        userRedis.save(userDO);

        // 保存数据库用户
        userDAO.save(userDO);
    }
}

把一个 Redis 对象相关操作接口封装为一个 DAO 类,符合面对对象的编程思想,也符合 SpringMVC 服务端三层架构规范,更便于代码的管理和维护。

4. 把数据库模型类暴露给接口

4.1. 现象描述

/** 用户 DAO 类 */
@Repository
public class UserDAO {
    /** 获取用户函数 */
    public UserDO getUser(Long userId) {...}
}

/** 用户服务类 */
@Service
public class UserService {
    /** 用户 DAO */
    @Autowired
    private UserDAO userDAO;

    /** 获取用户函数 */
    public UserDO getUser(Long userId) {return userDAO.getUser(userId);
    }
}

/** 用户控制器类 */
@Controller
@RequestMapping("/user")
public class UserController {
    /** 用户服务 */
    @Autowired
    private UserService userService;

    /** 获取用户函数 */
    @RequestMapping(path = "/getUser", method = RequestMethod.GET)
    public Result<UserDO> getUser(@RequestParam(name = "userId", required = true) Long userId) {UserDO user = userService.getUser(userId);
        return Result.success(user);
    }
}

上面的代码,看上去是满足 SpringMVC 服务端三层架构的,唯一的问题就是把数据库模型类 UserDO 直接暴露给了外部接口。

4.2. 存在问题及解决方案

存在问题:

  1. 间接暴露数据库表格设计,给竞争对手竞品分析带来方便;
  2. 如果数据库查询不做字段限制,会导致接口数据庞大,浪费用户的宝贵流量;
  3. 如果数据库查询不做字段限制,容易把敏感字段暴露给接口,导致出现数据的安全问题;
  4. 如果数据库模型类不能满足接口需求,需要在数据库模型类中添加别的字段,导致数据库模型类跟数据库字段不匹配问题;
  5. 如果没有维护好接口文档,通过阅读代码是无法分辨出数据库模型类中哪些字段是接口使用的,导致代码的可维护性变差。

解决方案:

  1. 管理制度 上要求数据库和接口的模型类完全独立;
  2. 项目结构 上限制开发人员把数据库模型类暴露给接口。

4.3. 项目搭建的三种方式

下面,将介绍如何更科学地搭建 Java 项目,有效地限制开发人员把数据库模型类暴露给接口。

第 1 种:共用模型的项目搭建

共用模型的项目搭建,把所有模型类放在一个模型项目(example-model)中,其它项目(example-repository、example-service、example-website)都依赖该模型项目,关系图如下:

序号 项目名称 打包类型 项目功能
1 example-model jar 定义了所有模型类,包括 DO 类和 VO 类等
2 example-repository jar 对应持久层,实现了 MySQL、Redis 相关 DAO 等
3 example-service jar 对应业务层,实现了 Service、Job、Workflow 等
4 example-webapp war 对应表现层,实现了 Controller、Interceptor、Filter 等

风险:

表现层项目(example-webapp)可以调用业务层项目(example-service)中的任意服务函数,甚至于越过业务层直接调用持久层项目(example-repository)的 DAO 函数。

第 2 种:模型分离的项目搭建

模型分离的项目搭建,单独搭建 API 项目(example-api),抽象出对外接口及其模型 VO 类。业务层项目(example-service)实现了这些接口,并向表现层项目(example-webapp)提供服务。表现层项目(example-webapp)只调用 API 项目(example-api)定义的服务接口。

序号 项目名称 打包类型 项目功能
1 example-api jar 业务层的表现层,定义了对外开放接口和 VO 类
2 example-repository jar 对应持久层,定义了 DO 类并实现了 MySQL、Redis 相关 DAO 等
3 example-service jar 对应业务层,实现了 Service、Job、Workflow 等
4 example-webapp war 对应表现层,实现了 Controller、Interceptor、Filter 等

风险:

表现层项目(example-webapp)仍然可以调用业务层项目(example-service)提供的内部服务函数和持久层项目(example-repository)的 DAO 函数。为了避免这种情况,只好管理制度上要求表现层项目(example-webapp)只能调用 API 项目(example-api)定义的服务接口函数。

第 3 种:服务化的项目搭建

服务化的项目搭,就是把业务层项目(example-service)和持久层项目(example-repository)通过 Dubbo 项目(example-dubbo)打包成一个服务,向业务层项目(example-webapp)或其它业务项目(other-service)提供 API 项目(example-api)中定义的接口函数。

序号 项目名称 打包类型 项目功能
1 example-api jar 对应业务层的表现层,定义了对外开放接口和 VO 类
2 example-repository jar 对应持久层,定义了 DO 类并实现了 MySQL、Redis 相关 DAO 等
3 example-service jar 对应业务层,实现了 Service、Job、Workflow 等
4 example-dubbo war 对应业务层的表现层,通过 Dubbo 提供服务
5 example-webapp war 对应表现层,实现了 Controller 等,通过 Dubbo 调用服务
6 other-service jar 对应其它项目的业务层,通过 Dubbo 调用服务

说明:Dubbo 项目(example-dubbo)只发布 API 项目(example-api)中定义的服务接口,保证了数据库模型无法暴露。业务层项目(example-webapp)或其它业务项目(other-service)只依赖了 API 项目(example-api),只能调用该项目中定义的服务接口。

4.4. 一条不太建议的建议

有人会问:接口模型和持久层模型分离,接口定义了一个查询数据模型 VO 类,持久层也需要定义一个查询数据模型 DO 类;接口定义了一个返回数据模型 VO 类,持久层也需要定义一个返回数据模型 DO 类……这样,对于项目早期快速迭代开发非常不利。能不能只让接口不暴露持久层数据模型,而能够让持久层使用接口的数据模型?

如果从 SpringMVC 服务端三层架构来说,这是不允许的,因为它会影响三层架构的独立性。但是,如果从快速迭代开发来说,这是允许的,因为它并不会暴露数据库模型类。所以,这是一条不太建议的建议。

/** 用户 DAO 类 */
@Repository
public class UserDAO {
    /** 统计用户函数 */
    public Long countByParameter(QueryUserParameterVO parameter) {...}
    /** 查询用户函数 */
    public List<UserVO> queryByParameter(QueryUserParameterVO parameter) {...}
}

/** 用户服务类 */
@Service
public class UserService {
    /** 用户 DAO */
    @Autowired
    private UserDAO userDAO;

    /** 查询用户函数 */
    public PageData<UserVO> queryUser(QueryUserParameterVO parameter) {Long totalCount = userDAO.countByParameter(parameter);
        List<UserVO> userList = null;
        if (Objects.nonNull(totalCount) && totalCount.compareTo(0L) > 0) {userList = userDAO.queryByParameter(parameter);
        }
        return new PageData<>(totalCount, userList);
    }
}

/** 用户控制器类 */
@Controller
@RequestMapping("/user")
public class UserController {
    /** 用户服务 */
    @Autowired
    private UserService userService;

    /** 查询用户函数(parameter 中包括分页参数 startIndex 和 pageSize) */
    @RequestMapping(path = "/queryUser", method = RequestMethod.POST)
    public Result<PageData<UserVO>> queryUser(@Valid @RequestBody QueryUserParameterVO parameter) {PageData<UserVO> pageData = userService.queryUser(parameter);
        return Result.success(pageData);
    }
}

后记

“仁者见仁、智者见智”,每个人都有自己的想法,而文章的内容也只是我的一家之言。

谨以此文献给那些我工作过的创业公司,是您们曾经放手让我去整改乱象,让我从中受益颇深并得以技术成长。


本文作者:中间件小哥

阅读原文

本文为云栖社区原创内容,未经允许不得转载。

退出移动版