从今天起开一个固定栏目：每天读一本书，把里面的东西压缩到 20 分钟内读完，再写点自己的看法。方向是金融、AI、历史这三块——前两块是饭碗，最后一块是让人不至于把今年发生的事都看成世界末日。 这个栏目不打算做成读书笔记的搬运。我做了八年 Java 和 AI，又自己跑过出海盘子、也清零过两次，读这些书
现象：发布到 K8s 之后 Pod 一直在重启 周一上午发了个小版本，只改了几行。结果 K8s 里这个 Pod 一直 CrashLoopBackOff，被杀了五次。 $ kubectl get pod -n prod | grep order order-service-7d9f8b6c5-x2m4
背景：一封邮件引发的升级 五月底基础架构组发了封邮件，说 Oracle JDK 8 从 8u211 起商业使用要收费，公司统一切 OpenJDK 11（下一个 LTS），老服务年底前迁完。我们组四个服务，清一色 Spring Boot 2.3.12 + JDK 8u282。我手上这个订单服务先动，Q
上了 K8s 之后，Pod 每天重启三四次 6 月初把订单服务迁到公司新搭的 K8s 集群（1.19）。上线第一天就发现问题：Pod 频繁重启。 $ kubectl get pod -l app=order-service -n trade NAME
升级到 2.4，服务起不来了 6 月初，把一个服务从 Spring Boot 2.3.7 升到 2.4.6。改完 pom 里的版本号，启动，直接炸： *************************** APPLICATION FAILED TO START *******************
编译一次 8 分钟，改一行代码等半天 5 月中旬，我们的主工程已经长成一个 47 个 package、21 万行的单体。mvn clean install 的时间： $ time mvn clean install -DskipTests [INFO] BUILD SUCCESS [INFO] To
实习生问我：这堆 GC 日志到底看什么 4 月底，团队来了个实习生。有次他看到我电脑上的 gc.log，问了一句："这一行行的数字，你是怎么看出问题的？" 2021-04-28T09:14:22.118+0800: 341882.221: [GC (Allocation Failure) [PSY
晚上八点半，所有接口一起超时 4 月 15 号晚上八点二十几分，告警群开始刷屏：订单服务全部接口超时，错误率 100%。 Pod 是活的，CPU 和内存都正常，CPU 只有 31%。但所有请求都在报同一个错： 2021-04-15 20:23:41.882 ERROR [http-nio-8080-
排查一次下单失败，登了 7 台机器 4 月初有用户反馈下单失败，报错是"系统繁忙"。这个接口要经过 7 个服务：网关 → 订单 → 库存 → 价格 → 风控 → 优惠券 → 支付。 我们的排查方式是：先猜可能是哪个服务，登录它的机器 grep 日志，找不到就换下一个。那天从晚上八点查到十点半，最后在
一条 ALTER TABLE，把整个订单库堵死了 3 月 22 号下午两点，我在 t_order_item 上执行了一条自认为很安全的语句： ALTER TABLE t_order_item ADD COLUMN promotion_type TINYINT NOT NULL DEFAULT 0 C
商家后台一个接口 2.3 秒，被投诉了半年 3 月上旬，客服转过来一条工单：某连锁商家反馈"经营概览"页面打开要转好几秒，用了半年一直这样。 我复现了一下，确实慢。这个接口返回商家今日/本月/累计的订单量、销售额、退款率、热销商品 Top5、会员增长数，一共 9 个指标。 第一步永远是耗时拆解，不是
32 G 内存的 Redis，用到 28 G 就没人敢再往里放了 3 月初做大促容量评估，缓存这块的数据很难看： $ redis-cli info memory used_memory_human:28.41G maxmemory_human:32.00G mem_fragmentation_rat
财务对账少了 3 笔积分 2 月中旬，财务同学找过来：2 月 10 号这天的积分发放和订单数据对不上，少了 3 笔。 我们链路是：订单服务发 ORDER_PAID 事件到 Kafka，积分服务消费后发积分。查了一圈，积分服务没报错，是消息压根没到。 先看生产者的配置： spring: kafka
升级 JDK 11 之后，代码里开始出现 var 2 月初我们把一个服务从 JDK 8u272 升到了 JDK 11.0.10。升级本身没什么好说的，倒是有个副作用：有同事开始用 var 了。 第一次在 review 里看到这段代码，我打了回退： var result = orderService.
review 时和同事吵了一架 1 月中旬做 code review，我写了一段统计订单金额的代码： long total = orders.stream() .mapToLong(Order::getAmount) .sum(); 同事评论："Stream 有性能
商品详情页 P99 1.8 秒，五个 RPC 串行调用 12 月中旬，前端同学甩过来一张截图：商品详情页首屏白屏 2 秒多，用户投诉"点商品没反应"。我去看 SkyWalking 的拓扑，这个接口平均 690 ms，P99 1.8 s，P999 3.2 s。 接口干的事很简单，串着调了 5 个下游：
