从单体到分布式，聊聊Mybatis在数据持久化里的那些事儿

主要综合自网络技术社区、博客文章以及Mybatis官方文档的常见讨论主题）

记得我刚入行那会儿，做的第一个项目就是个典型的单体应用，所有的功能，用户管理、订单处理、数据报表，都打包在一个大大的war包里，往一个Tomcat服务器上一扔，就跑起来了，那时候，数据持久化的选择，团队里几乎没什么争议，就是Mybatis加上它的好搭档PageHelper分页插件，为什么是它呢？因为简单、直接，对于我们这些当时还半懂不懂的Java新手来说，SQL是看得见摸得着的东西，Mybatis把写SQL的控制权完全交给了我们，不用担心像某些框架那样生成一堆难以理解的“魔法”SQL，出了问题调试起来也方便，直接看自己写的SQL语句对不对就行了，在单体架构下，数据库通常也就一个，最多搞个主从复制读写分离，Mybatis配合个简单的数据源配置，就能很好地胜任工作，那时候，我们关心的无非就是怎么把SQL写得高效一点，怎么用好动态SQL来避免代码里拼接字符串的混乱，以及怎么通过Mybatis的缓存机制让查询更快一些,整个数据访问层是清晰而内聚的。

但是后来，随着业务越来越复杂，用户量蹭蹭往上涨，单体架构的瓶颈就暴露出来了，最直接的就是数据库扛不住了，一个库要应对所有模块的读写，CPU、IO经常飙高，架构开始向分布式、微服务演进，这一变，数据持久化这一块儿可就迎来了翻天覆地的变化,Mybatis扮演的角色和遇到的挑战也跟着变了。

首先就是著名的“分库分表”问题，在单体时代，我们一张user表可能就存了千万级的用户数据，查询越来越慢，为了解决这个问题，不得不把数据和访问压力分散开，也就是把一个大库拆分成多个小库，把一张大表拆成多张小表，这下Mybatis原生的那套映射机制就有点不够看了，你不能再简单地通过一个Mapper接口的selectByUserId方法去查数据了，因为数据到底落在哪个库的哪张表里，需要根据一个分片键（比如用户ID）来计算，这时候，就需要引入像ShardingSphere（以前叫Sharding-JDBC）这样的中间件，它可以理解成一个增强版的数据源代理，在Mybatis底下默默工作，Mybatis还以为自己在操作一个单一的数据库，发出标准的SQL，但ShardingSphere会拦截这个SQL，根据规则把它改写，然后路由到正确的数据库和数据表上执行，最后再把结果汇总起来，Mybatis从直接操作数据库的“执行者”，变成了分布式数据访问流程中的一个“环节”，它依然负责最擅长的ORM映射，但更上层的路由、分发逻辑交给了专门的组件。

在微服务架构下，每个服务都有自己的专属数据库，这就是所谓的“数据库隔离”，比如订单服务有自己的订单库，用户服务有自己的用户库，这带来了数据独立性的好处，但也带来了新的问题：跨服务的数据关联查询怎么办？在单体应用里，一个多表JOIN查询就能搞定的事情，在微服务里行不通了，因为你不能直接去连别的服务的数据库，这时候，Mybatis本身是解决不了这个问题的，常见的做法有两种：一是在应用层进行“拼装”，即先用Mybatis从订单服务查出订单列表，拿到用户ID集合，再通过调用用户服务的API去批量查询用户信息，最后在代码里把数据组合起来；另一种是使用“命令查询职责分离”（CQRS）模式，通过监听领域事件，把其他服务关心的数据冗余一份到自己服务的数据库中，形成一个只读的副本，这样查询时就可以直接用Mybatis在本库中完成了，这两种方式，Mybatis的角色都变得更专注了,它只负责处理自己服务边界内的数据持久化。

分布式事务也是个绕不开的坎儿，在单体应用里，一个@Transactional注解就能保证多个数据库操作在一个事务里，但在微服务中，一个业务操作可能涉及更新订单库、扣减库存库、增加积分库，这三个操作分布在三个不同的服务、三个不同的数据库上，传统的数据事务（ACID）失效了，取而代之的是最终一致性方案，比如基于消息队列的可靠事件通知模式或者TCC模式，在这些模式下，Mybatis执行的每个本地数据库操作仍然是事务性的，但多个本地事务之间的协调，需要依靠上层的分布式事务框架来保证最终结果一致，Mybatis在这里再次退居二线，确保单点操作的可靠性,而把全局一致性的难题交给了架构层面解决。

回过头来看，从单体到分布式，Mybatis这个“老伙计”并没有过时，它的核心价值——灵活的SQL映射能力——依然非常重要，变化的是它所处的生态系统和它需要承担的职责边界，它从一个数据持久化的“全能选手”，逐渐演变为分布式数据访问架构中一个专注且可靠的“专业组件”，我们不再期望它解决所有数据层的难题，而是学会让它与其他强大的分布式中间件（如ShardingSphere、Seata分布式事务框架等）协同工作，共同构建起稳定、高效的数据访问层，这个过程，也是我们开发者从只关注单点技术,到必须具备整体架构思维的一个缩影。