用JDBC + AOP 实现的数据库加密切面能不能切西瓜？
JDBC + AOP（切面）能不能切西瓜？
最后出结论 … …
JDBC + AOP（切面）到底能不能切西瓜？咱们结合技术原理展开聊聊。如果硬拿它类比现实切西瓜，切出来的效果会又薄又大又圆，最后甚至没法啃，如下图所示（图 1-1）：
图 1-1
基于 Spring AOP 切面拦截 JDBC 数据库操作（增删改查），就是在 SQL 执行前后自动对字段加解密，无侵入业务代码，但是该实现方案会造成数据库原生索引彻底失效，数据库内置存储过程、触发器与用户自定义函数在直接操作存储密文时，会因数据格式不一致抛出异常；加解密逻辑运行于 JDBC 驱动层，不受数据库事务管理机制约束，进而形成事务盲区；加之加密操作会不可逆变更数据原本的物理存储形态与逻辑属性，最终导致数据无法适配数据库字段定义、SQL 语法规范及各类常规业务逻辑，就像你无意中切开了一个过期的西瓜一样 —— 本来你是想吃瓜，一刀下去苦哈哈，如下图所示（图 1-2）：
图 1-2
我们把数据加解密这种繁琐重复的工作，单独剥离交给切面自动执行，业务代码只专注读写数据库，完全不用手写任何加解密逻辑。拿切西瓜类比切面加密，切面负责一刀切完成加密。那这一切会不会哧哧流出西瓜汁？答案是一定会的，这里流出的西瓜汁，就是加密过程中流转、临时暴露的原始业务明文数据，如下图所示（图 1-3）：
图 1-3
那我们先聊聊这个切瓜刀子 —JDBC是干嘛的？JDBC 就是 Java 程序连接数据库的 “搬运工”，专门负责来回传递 SQL 语句和数据，天天在代码、内存和数据库之间打转，这辈子的工作范围就局限在虚拟的数据世界里，压根碰不到现实里的东西。而 AOP 也就是面向切面编程，在程序员圈子里一直有个有趣的外号 —“切瓜神器”，这可不是空穴来风。
我们可以把一整条业务流程想象成一个大西瓜。核心业务代码是清甜的瓜瓤，是整个西瓜的精华，而数据加解密、日志打印、事务控制这类重复通用逻辑，就像是西瓜多余的瓜皮。传统写法是把瓜皮和瓜瓤揉在一起，然后再来上一铁锤，代码又臃肿又难维护，最后的结果就像西瓜的处刑现场，你都不知道道自己是心疼瓜还是想吃瓜，如下图所示（图1-4）：
图 1-4
AOP 的横切能力，就好比拿起一把刀，横向一刀切，把通用逻辑和核心业务分离开，这就是程序员口中调侃的 “切西瓜”， 如下图所示（图 1-5）：
图 1-5
大家可能最关心的是它到底能不能切西瓜，就像曾经有人问JAVA能不能炸死青蛙一样。JDBC+AOP 从头到尾都是跑在服务器里的代码逻辑，只会和字符、数据、SQL 打交道，既没有机械刀片，也没有物理操控能力。哪怕代码写得再精妙、切面功能再强大，也没法拿出一把切面刀，跑到现实里切开西瓜。你指望一串代码去切西瓜，就好比你让八戒去爬树，猴哥看了翻白眼，鲁智深气的拔掉它，如下图所示（图 1-6）：
图 1-6
但放到编程领域，情况则完全不同，这套 JDBC+AOP 字段加密方案，绝对是“切西瓜”的刽子手。我们继续沿用西瓜类比：JDBC 贯穿数据库读写的全流程，相当于西瓜的中心瓜脉；我们自定义的加密切面，精准切入 JDBC 执行增、删、改、查的核心节点，完成一次标准的技术版“切西瓜”操作，如下图所示（图 1-7）：
图 1-7
当程序要往数据库新增、修改数据时，切面抢先一步拦截参数，自动把手机号、身份证这类敏感字段加密，再交给 JDBC 去执行 SQL；当程序查询数据时，数据库返回密文数据，切面又会第一时间完成解密，再把明文数据交给业务代码。整个过程里，核心业务代码，不用做任何改动，加解密这块 “西瓜” 被切面单独剥离处理。这不就是 AOP “切西瓜” 的经典操作吗？
图 1-8
但是JDBC+AOP 字段加密最致命缺陷在于加密逻辑依托 Spring 切面代理实现，无法全覆盖所有 JDBC 操作链路，原生 JDBC 硬编码、Service 内部自调用、存储过程、多租户 / 分页插件等场景极易绕过加密逻辑造成明文入库。且切面仅处理入库实体字段，无法同步加密查询条件，模糊检索、排序、索引全部失效，同时明文长期驻留应用内存、密钥托管能力缺失易造成数据泄露，一旦密钥外泄或代码出现拦截漏洞，全量敏感数据直接暴露，就如上文所提，切西瓜一定会流出西瓜汁！这种情况下，硬要满足等保与个人信息保护合规要求，那得加多层额外的防护技术方案，此时此刻，你还想用这把刀，切自家的大西瓜（数据库）吗？
最终结论
从现实物理角度来说，JDBC+AOP 加密切面只是虚拟代码，绝对切不了能吃的实物西瓜。但站在编程技术的角度，它完美运用了 AOP 横切思想，把通用的加解密逻辑和核心业务代码拆分，这不就是标准技术版的“切西瓜”嘛 … … ！
图 1-9
总结一句话：切我们的西瓜它不行，编程里 “切瓜” 它最行！