微服务 数据库耦合_动态代理+注解+反射解决微服务项目常见的业务耦合问题

--业务背景：

某一天，项目经理老王接了一个新的项目，说是要开发一款商城后台管理系统（RBAC），系统中有订单管理、用户管理、权限管理、数据分析...等等模块。刚开始，研发小组长小陈评估这个系统的并发度不是很高，为了节省资源成本，只使用了一个mysql搭配n个reids来完成，万万没想到在项目上线的几个月之后，突然接到了客户的投诉，说是系统的响应速度越来越慢，慢得像只蜗牛那样，经过沟通了解之后，老王立马知道了问题所在，但仍然还是要被客户bilibalabilibala一番，老王受了一肚子气回到公司，双手叉腰，看着在瑟瑟发抖的小陈，小陈以为等待他的只有一番痛斥，没想到老王只是跟小陈说明了和客户沟通的情况，要求小陈对项目进行升级，以适应日访问量不断递增的情况，此时小陈心态180度大转变，为了不负老王的期望（不希望老王再次被客户bilibali，主要还是不想自己被骂，嘻嘻），下定决心要把项目升级工作做好，此时小陈和其他的开发人员沟通一番，之后发现，系统需要升级为微服务项目，并打算一个模块对应一个数据库。

--分析：

RBAC系统的两个版本架构大致如下（主要分析订单、用户模块）：

--需求：查询所有订单信息（订单号、客户姓名）

假设：

[1] t_order表的字段：id、customerId。
[2] t_user表的字段：id、name。

--根据假设可以得出：

RBAC 1.0 直接 一条sql语句就解决需求：select o.id, u.name from t_order o join t_user u on o.customerId = u.id;
RBAC 2.0 显然需要 两条sql分别查询 两个数据库才能完成这个需求。这意味着订单信息的组装需要通过java代码（业务层）来完成。如下：

@Service
public class OrderServiceImpl implements OrderService {
    

    @Autowired
    private OrderMapper orderMapper;

    @Autowired
    private UserMapper userMapper;

    @Override
    public List<Order> getOrders() {
    
        List<Order> orders = orderMapper.getOrders();
        // 组装代码
        for (Order order : orders) {
    
            User user = userMapper.getUserById(order.getCustomerId());
            order.setCustomerName(user.getName());
        }
        return orders;
    }
}

这段代码虽然可以满足需求，但是存在两个潜在问题：

[1] 违背了单一职责原则，orderService中，应该仅仅只和Order模块相关，不应该参插入User模块，随着时间的推移，代码维护成本日益递增。 [2]