今晚卧龙试玩放出，却没有打开游戏机的心情。应该是最近有点累到了，要做的事情堆得很多，压力也有，说不紧张是有点假的。

在Spring Boot 3正式发布的那天，我拉上了几个同事一起哼哧哼哧把我们早就看不顺眼，或已经标记为废弃的库全部铲掉，换上了新的库。

那段时间有天同事跑到我身后问我：“我发现你一声不吭在这写代码写了三天，你到底在做什么？”。当时我键盘敲得飞快，同事还以为我在生闷气。那天快结束的时候，插件统计我写了快12小时，如果没记错的话，应该是去年11月28日，一个周三的晚上。

下周一，我们生产环境的基础框架从Spring Boot 2升级到3，意味着所有容器会从Java 8切到Java 17。而升级到Java 17有何意义？升级到Spring Boot 3又有何意义？

我们的业务量很有周期性，一直在增长，在特定时段为超高速增长，为了应付业务超高速增长带来的冲击，我们需要在全年堆业务的同时，还要不断优化代码以提高性能。

效果如何呢？举个数据库相关的例子，当我们业务量是现在的1/5时，数据库事务峰值是20K/s，比较忙碌的时段平均下来是12K/s。如今，我们通过优化代码，将数据库事务峰值压到8K/s，比较忙碌的时段平均下来是4K/s。最近一次的发版，则是把数据库CPU峰值占用从60%直接压到了40%，忙时CPU平均占用从40%压到20%。

即使大部分业务数字已经存在我的脑里，但我不会和任何人透露具体的业务数字，我的同事也是如此。我和别人聊起我们的数据库，我会说，我们的数据库从上线到现在，一直是4核16G内存的规格，只升级过两次，一次是从突发实例升级到标准实例，第二次，也就是这周一，从amd64架构切换至arm64架构，规格不变，性能上升，价格下降，在用户增长时，平摊到用户身上，平均成本上一直在减小。

我很清楚我们的业务是计算密集型业务，每个API被调用时候都需要经过一系列的计算和校验判断是否合法，每一条消息都会确保合法且未被篡改。每一分钟，JVM内会产生上千万个临时对象，数百万的日志或消息会流入各类中间件中，我们的工作就是保证所有信息以最快的速度转发出去。

Java 17能尽可能让转发的流程不会被GC中断给用户带来时延，Spring Boot 3能确保应用准确无误跑在Java 17上，这是业务性质决定，我们所有的升级工作都有明确的目的，并非把玩技术，或是拿我们的用户做试验。

上图为我们在一个数据中心上线了Java 17，并与Java 8的暂停时间对比，效果拔群。

然而说了那么多，我的压力并不来源于Java 17的升级，而源于Java 17升级之后的架构大改动。近似于：我需要偷偷将我们所有用户从一架旧飞机换到一架新飞机上，且在他们不知不觉的情况下完成。我之前只搬运过中国用户，这次是全球，难度完全不一样。

希望没啥问题吧，洗洗睡了。