GA 在下个月,我们这个月就已经在迁了 Spring AI 2.0 的 GA 定在 2026 年 6 月。我们在 5 月初就拉了 2.0.0-RC1 做迁移演练,到今天两周,9 个服务里有 6 个跑通了。 为什么不等 GA?因为 1.x 到 2.0 的破坏性变更比想象中多,我们评估过,等 GA 再动
背景:我们一套跑了五年的订单分析系统,主库是 MySQL 8.0,平时扛交易,月底还要跑 T+1 报表。一次月底大查询把从库 CPU 打到 100%,复制延迟一度飙到 47 秒,运营看板直接瘫痪。那一刻我意识到,把 OLTP 和重分析塞在同一套实例里,迟早出事。 为什么盯上 TiDB 当时评估了三个
提前迁移 Spring Boot 3.0:踩在 GA 前的准备 Spring Boot 3.0 要在 2022 年 11 月正式 GA,但我司有几个新服务打算直接基于 3.0 起项目,不想上线半年就面临大版本升级。于是我在 9 月就基于3.0 的里程碑/RC 候选版本做了一次迁移验证,把要改的点摸了
周会上定的事:6 周内把 Netflix 那一套换成 Alibaba 3 月底的架构周会,我把一张图投到了屏幕上:Spring Cloud Netflix 的组件里,Hystrix、Zuul 1.x、Ribbon、Archaius、Turbine 五个都挂着"maintenance mode"或者干
32 万行单体,我们用了 5 个月切成微服务,一次没停过机 去年 10 月启动的拆分,到今年 2 月底核心链路切完。这期间系统一天没停过,用户侧没有感知到任何一次发布异常。回过头看,技术选型上没什么新鲜的,真正难的是"怎么一步步把流量搬过去,以及搬错了怎么退回来"。 先说被拆的那个东西 shop-a