SpringBoot - 实践阿里巴巴Manager 层_通用业务处理层

Posted 2022-03-04 小小工匠

文章目录

• 规范
• 对比传统MVC
• 小栗子
• • V1.0 传统写法
  • V2.0 引入Manager层
• 源码

---

规范

---

对比传统MVC

说几个弊端

• Service层代码臃肿

• Service层易出现大事务，事务嵌套，易出问题且难排查

• dao层混杂业务逻辑

• dao层sql语句复杂

• …

为了解决这个问题，《阿里巴巴泰山版java开发手册》推荐在Service层之下独立出一个通用业务处理层（Manager层）

相比较传统的MVC，主要增加了 Manager 层， 它有如下特征：

• 1） 对第三方平台封装的层，预处理返回结果及转化异常信息
• 2） 对 Service 层通用能力的下沉，如缓存方案、中间件通用处理
• 3） 与 DAO 层交互，对多个 DAO 的组合复用

---

实际开发中，

• 对于复杂业务，service调用manager层，然后把事务下沉到Manager层，Manager层不允许相互调用，不会出现事务嵌套。

• 专注于不带业务SQL，也可以在manager层进行通用业务的dao层封装。

• 避免复杂的join查询，可以在manager层严格控制好SQL，应对复杂的SQL查询。

简言之， Manager 层提供原子服务接口，Service 层负责依据业务逻辑来调用原子接口。

---

小栗子

举个例子说明一下Manager层的使用场景

需求：

1. APP 登录的用户，如果系统中没有用户，需要自动创建用户，然后再返回相关的用户信息用于展示
2. 网页端登陆的用户，如果系统中没有用户，不自动创建用户，需要用户注册。

反手就是一顿突突啊

---

V1.0 传统写法

 package com.artisan.service;

import com.artisan.dao.UserDao;
import com.artisan.response.ResponseData;
import lombok.SneakyThrows;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

import java.util.concurrent.TimeUnit;

/**
 * @author 小工匠
 * @version 1.0
 * @mark: show me the code , change the world
 */


@Service
public class ServiceWithoutManager 

    private final boolean APP = true;

    @Autowired
    private UserDao userDao;

    @Transactional(rollbackFor = Throwable.class)
    public ResponseData<String> buiz(Long idCard, Long name) 

        // 验证 1  假设  DB操作 校验
        String  var1 = doDBCheck1();

        // 验证 2  假设  DB操作 校验
        String  var2 =  doDBCheck2();

        // 业务  APP -- DB校验 --- 自动创建用户 -- 返回用户信息
        //      网页 -- DB校验 ---  -- 返回用户信息
        doBiz(var1,var2);

        return ResponseData.success("success");
    

    @SneakyThrows
    private void doBiz(String a ,String b) 
        if(APP) 
            // 模拟业务耗时
            TimeUnit.MILLISECONDS.sleep(1200);
        else 

        
    

    @SneakyThrows
    private String doDBCheck2() 
        // 模拟业务耗时
        TimeUnit.MILLISECONDS.sleep(500);
        return "";
    

    @SneakyThrows
    private String doDBCheck1() 
        // 模拟业务耗时
        TimeUnit.MILLISECONDS.sleep(1000);
        return "";
    



    
    

这有啥子问题？ 常规操作啊…

每日一博 - 常见的Spring事务失效&事务不回滚案例集锦

让我们来分析分析

• 典型的长事务问题 ， 由于方法上有@Transactional 注解，所以验证和业务都是使用的同一个 connection
• 对于复杂业务、复杂的验证逻辑，会导致整个验证过程始终占用该 connection 连接，占用时间可能会很长，直至方法结束，connection 才会交还给数据库连接池。

对于复杂业务的不可预计的情况，长时间占用同一个 connection 连接应该尽量避免，应该尽量缩短占用时间。

@Transactional 注解， AOP 实现，本质就是在目标方法执行前后进行拦截。 在目标方法执行前加入或创建一个事务，在执行方法执行后，根据实际情况选择提交或是回滚事务。

当 Spring 遇到该注解时，会自动从数据库连接池中获取 connection，并开启事务然后绑定到 ThreadLocal 上，对于@Transactional注解包裹的整个方法都是使用同一个connection连接。

如果出现了耗时的操作，比如三方接口调用，业务逻辑复杂，大数据处理等就会导致占用这个connection的时间过长，数据库连接一直被占用不释放。一旦类似操作过多，进而导致数据库连接池耗尽。

---

V2.0 引入Manager层

将数据在 service 层准备好，然后传递给 manager 层，由 manager 层添加@Transactional事务注解进行数据库操作, 尽量减少大事务带来的危害。

源码

https://github.com/yangshangwei/boot2