我们注意到掘金上一篇技术文章正在被传阅：一位工程师用 Spring 的 FactoryBean（Spring 提供的「对象工厂」接口）配合 JDK 动态代理，把 Redis 双活——也就是两个机房同时读写、互相备份——直接焊进了 Spring 业务代码，零中间件、零业务改造。值得关心的是，AI 产品频繁宕机的根因往往不在模型，而在这种「没人愿意写」的基础设施层。
这是什么
Redis 双活解决的是「机房 A 挂了，机房 B 还能正常服务」的问题。传统做法是在 Redis 之外架一层同步中间件（Redis-Shake、CloudCanal、RedisSyncer），让两个机房的数据互相复制。这位作者认为这条路有问题：双写逻辑藏在应用之外，出问题时你只能去翻同步日志，排查链路被拉长。
他的方案是把双写下沉到应用层。用 Spring 的 FactoryBean 接口在交付 Redis 客户端之前，给它套一层 JDK 动态代理的壳：对外是普通的 RedisDualClient 接口，业务代码注入即用；对内自动把一次写入复制到两个机房，把一次读取路由到最近的机房。
判断：这不是颠覆，是一种权衡。中间件方案通用但黑盒，应用层方案可控但把复杂度推给了业务团队。
行业怎么看
支持者认为这是正确方向——容灾本来就该和应用语义绑定，中间件做的是「看不见的活」，最难定位的就是这种故障。文中「壳套得再好类型对不上 Spring 都进不去门」这种细节，是只有真正踩过坑才写得出的判断。
反对意见同样值得听。FactoryBean 是 Spring 里相对小众的 API，团队里没人熟悉的话，新人接手成本陡增；双活的核心难题——脑裂（两个机房都以为自己是主）和数据冲突——这位方案并没有真正解决，只是把排查点搬到了更近的地方。「业务代码零改动」的代价是运维、配置、监控的复杂度被推给业务团队，对中小公司未必划算。
对普通人的影响
对企业 IT：传统行业上线 AI 产品时，模型选型是显性投入，底层可靠性（Redis 双活、机房容灾）是隐性投入——但用户能感知到的，往往是后者。
对个人职场：AI 越火，写这种「无聊基础设施」的工程师越值钱。模型调优岗会饱和，凌晨两点能在告警里定位到双写冲突的人，永远稀缺。
对消费市场：AI 产品「看起来越来越聪明」是模型层的进步，「凌晨下单不掉购物车」是基础设施层的进步。两个进步不挂钩，消费者别把两者混为一谈。