戳上方蓝字“Java面试题精选”关注我
看到这样的代码,内心五味杂陈……
那天下午,看到了令我终生难忘的代码,那一刻破防了……
🔊 本文记录那些年的 Java 代码轶事
ヾ(•ω•`)🫥 故事还得从半年前数据隔离的那个事情说起……
历史背景
数据隔离
预发,灰度,线上环境共用一个数据库。每一张表有一个 env 字段,环境不同值不同。特别说明:env 字段即环境字段。如下图所示:
隔离之前
🖌️插曲:一开始只有 1 个核心表有 env 字段,其他表均无该字段;有一天预发环境的操作影响到客户线上的数据。为了彻底隔离,剩余的二十几个表均要添加上环境隔离字段。
「当时二十几张表已经大量生产数据,隔离需要做好兼容过渡,保障数据安全。」
隔离改造
其他表历史数据很难做区分,于是新增加的字段 env 初始化 all ,表示预发线上都能访问。以此达到历史数据的兼容。
每一个环境都有一个自己独立标志;从 application.properties 中读该字段;最终到数据库执行的语句如下:
SELECT XXX FROM tableName WHERE env = ${环境字段值} and ${condition}
隔离方案
「最拉胯的做法:每一张表涉及到的 DO、Mapper、XML等挨个添加 env 字段。但我指定不能这么干!!!」

具体方案:自定义 mybatis 拦截器进行统一处理。通过这个方案可以解决以下几个问题:
-
业务代码不用修改,包括 DO、Mapper、XML等。只修改 mybatis 拦截的逻辑。
-
挨个添加补充字段,工程量很多,出错概率极高
-
后续扩展容易
最终落地
在 mybatis 拦截器中, 通过改写 SQL。新增时填充环境字段值,查询时添加环境字段条件。真正实现改一处即可。考虑历史数据过渡,将 env = ${当前环境}
修改成 env in (${当前环境},'all')
SELECT xxx FROM ${tableName} WHERE env in (${当前环境},'all') AND ${其他条件}
具体实现逻辑如下图所示:
-
其中 env 字段是从 application.properties 配置获取,全局唯一,只要环境不同,env 值不同
-
借助 JSqlParser 开源工具,改写 sql 语句,修改重新填充、查询拼接条件即可。链接
https://github.com/JSQLParser/JSqlParser
思路:自定义拦截器,填充环境参数,修改 sql 语句,下面是部分代码示例:
@Intercepts(
{@Signature(type = Executor.class, method = "update", args = {MappedStatement.class, Object.class})}
)
@Component
public class EnvIsolationInterceptor implements Interceptor {
......
@Override
public Object intercept(Invocation invocation) throws Throwable {
......
if (SqlCommandType.INSERT == sqlCommandType) {
try {
// 重写 sql 执行语句,填充环境参数等
insertMethodProcess(invocation, boundSql);
} catch (Exception exception) {
log.error("parser insert sql exception, boundSql is:" + JSON.toJSONString(boundSql), exception);
throw exception;
}
}
return invocation.proceed();
}
}
一气呵成,完美上线。
发展演变
业务需求
「随着业务发展,出现了以下需求:」
-
上下游合作,我们的 PRC 接口在匹配环境上与他们有差异,需要改造
SELECT * FROM ${tableName} WHERE bizId = ${bizId} and env in (?,'all')
-
有一些环境的数据相互相共享,比如预发和灰度等
-
开发人员的部分后面,希望在预发能纠正线上数据等
初步沟通
这个需求的落地交给了来了快两年的小鲜肉。在开始做之前,他也问我该怎么做;我简单说了一些想法,比如可以跳过环境字段检查,不拼接条件;或者拼接所有条件,这样都能查询;亦或者看一下能不能注解来标志特定方法,你想一想如何实现……
(●ˇ∀ˇ●)年纪大了需要给年轻人机会。
勤劳能干
小鲜肉,没多久就实现了。不过有一天下午他遇到了麻烦。他填充的环境字段取出来为 null,看来很久没找到原因,让我帮他看看。(不久前也还教过他 Arthas 如何使用呢,这种问题应该不在话下吧🤔)
具体实现
大致逻辑:在需要跳过环境条件判断的方法前后做硬编码处理,同环切面逻辑, 一加一删。填充颜色部分为小鲜肉的改造逻辑。
大概逻辑就是:将 env 字段填充所有环境。条件过滤的忽略的目的。
SELECT * FROM ${tableName} WHERE env in ('pre','gray','online','all') AND ${其他条件}
错误原因
经过排查是因为 API 里面有多处对 threadLoal 进行处理的逻辑,方法之间存在调用。简化举例:A 和 B 方法都是独立的方法, A 在调用 B 的过程,B 结束时把上下文环境字段删除, A 在获取时得到 null。具体如下:
五味杂陈
当我看到代码的一瞬间,彻底破防了……

「queryProject 方法里面调用 findProjectWithOutEnv, 在两个方法中,都有填充处理 env 的代码。」
遍地开花
然而,这三行代码,随处可见,在业务代码中遍地开花…….
// 1. 变量保存 oriFilterEnv
String oriFilterEnv = UserHolder.getUser().getFilterEnv();
// 2. 设置值到应用上下文
UserHolder.getUser().setFilterEnv(globalConfigDTO.getAllEnv());
//....... 业务代码 ....
// 3. 结束复原
UserHolder.getUser().setFilterEnv(oriFilterEnv);

灵魂开问
-
开闭原则符合了吗 -
改漏了应该办呢 -
其他人遇到跳过的检查的场景也加这样的代码吗 -
业务代码和功能代码分离了吗 -
填充到应用上下文对象 user 合适吗 -
…….
重构一下
困难之处
问题列表
-
尽量不要修改已有方法,保证不影响原有逻辑; -
尽量不要在业务方法中修改功能代码;关注点分离; -
尽量最小改动,修改一处即可实现逻辑; -
改造后复用能力,而不是依葫芦画瓢地添加这种代码
实现分析
-
用独立的 ThreadLocal,不与当前用户信息上下文混合使用 -
注解+APO,通过注解参数解析,达到目标功能 -
对于方法之间的调用或者循环调用,要考虑优化
使用案例
@InvokeChainSkipEnvRule(skipEnvList = {"pre"}, skipTableList = {"project"})
@SneakyThrows
@GetMapping("/importSignedUserData")
@InvokeChainSkipEnvRule(skipEnvList = {"pre"}, skipTableList = {"project"})
public void importSignedUserData(
......
HttpServletRequest request,
HttpServletResponse response) {
......
}
具体实现
-
方法上标记注解, 注解参数定义规则 -
切面读取方法上面的注解规则,并传递到应用上下文 -
拦截器从应用上下文读取规则进行规则判断

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface InvokeChainSkipEnvRule {
/**
* 是否跳过环境。 默认 true,不推荐设置 false
*
* @return
*/
boolean isKip() default true;
/**
* 赋值则判断规则,否则不判断
*
* @return
*/
String[] skipEnvList() default {};
/**
* 赋值则判断规则,否则不判断
*
* @return
*/
String[] skipTableList() default {};
}
不足之处
-
整个链路上的这个表操作都会跳过,颗粒度还是比较粗 -
注解只能在入口处使用,公共方法调用尽量避免
总结思考
隔离总结
编码总结
-
尽量修改一个地方,不要写这种边边角角的代码 -
善用自定义注解,解决这种通用逻辑 -
可以妥协,但是要有底线 -
……
场景总结

反思总结
-
如果一开始就做好技术方案或者直接使用不同的数据库 -
是否可以拒绝那个所谓的需求 -
先有设计再有编码,别瞎搞
最后感想
来源:juejin.cn/post/7294844864020430902
构建高质量的技术交流社群,欢迎从事编程开发、技术招聘HR进群,也欢迎大家分享自己公司的内推信息,相互帮助,一起进步!
文明发言,以
交流技术
、职位内推
、行业探讨
为主
广告人士勿入,切勿轻信私聊,防止被骗
原文始发于微信公众号(Java面试题精选):同事写的让我内心五味杂陈的代码。。。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/178949.html