GA 在下个月，我们这个月就已经在迁了 Spring AI 2.0 的 GA 定在 2026 年 6 月。我们在 5 月初就拉了 2.0.0-RC1 做迁移演练，到今天两周，9 个服务里有 6 个跑通了。 为什么不等 GA？因为 1.x 到 2.0 的破坏性变更比想象中多，我们评估过，等 GA 再动
去年底老板拍板：核心交易系统去 Oracle。理由很直接——一年 380 万的授权费，加上审计合规越来越严。我接手时第一反应是：这活儿坑比想象多，不是导出 SQL 再导入就完事。 先盘家底 系统跑了九年，Oracle 里不止 SQL。我用了两周做依赖盘点，列了一张表： 依赖类型 数量 风险 存储过程
背景：我们一套跑了五年的订单分析系统，主库是 MySQL 8.0，平时扛交易，月底还要跑 T+1 报表。一次月底大查询把从库 CPU 打到 100%，复制延迟一度飙到 47 秒，运营看板直接瘫痪。那一刻我意识到，把 OLTP 和重分析塞在同一套实例里，迟早出事。 为什么盯上 TiDB 当时评估了三个
缓存和数据库又双叒不一致了 我们的商品详情页用"先更新 DB，再删缓存"的策略。大多数时候没问题，但运营一次批量改价后，部分用户看到的价格还是旧的，持续了十几分钟。根因是并发下的时序问题：线程 A 更新 DB、还没删缓存时，线程 B 读了旧 DB 值并写回缓存，导致 A 的删除"删了个寂寞"，脏数据
提前迁移 Spring Boot 3.0：踩在 GA 前的准备 Spring Boot 3.0 要在 2022 年 11 月正式 GA，但我司有几个新服务打算直接基于 3.0 起项目，不想上线半年就面临大版本升级。于是我在 9 月就基于3.0 的里程碑/RC 候选版本做了一次迁移验证，把要改的点摸了
8200 万行数据，怎么搬到 32 个分片里去 接上一篇。分片规则定好了、ShardingSphere 配好了，接下来的问题是：老库里那 8200 万行数据怎么搬过去，而且不能停服。 这篇文章写的是迁移本身，跟分片设计是两件事，但难度可能更大。 先算停机方案要多久 最省事的做法是挂维护页，导出导入。
周会上定的事：6 周内把 Netflix 那一套换成 Alibaba 3 月底的架构周会，我把一张图投到了屏幕上：Spring Cloud Netflix 的组件里，Hystrix、Zuul 1.x、Ribbon、Archaius、Turbine 五个都挂着"maintenance mode"或者干
32 万行单体，我们用了 5 个月切成微服务，一次没停过机 去年 10 月启动的拆分，到今年 2 月底核心链路切完。这期间系统一天没停过，用户侧没有感知到任何一次发布异常。回过头看，技术选型上没什么新鲜的，真正难的是"怎么一步步把流量搬过去，以及搬错了怎么退回来"。 先说被拆的那个东西 shop-a
