从今天起开一个固定栏目：每天读一本书，把里面的东西压缩到 20 分钟内读完，再写点自己的看法。方向是金融、AI、历史这三块——前两块是饭碗，最后一块是让人不至于把今年发生的事都看成世界末日。 第一本很适合开栏：《金钱心理学》（The Psychology of Money），摩根·豪泽尔。 它的核心
为什么要从 CMS 迁到 G1 我们在 JDK 8 上跑 CMS 跑了两年多，一直相安无事。真正推动迁移的是两件事。 第一件是碎片问题终于爆了。四月份的一个凌晨，promotion failed 触发了 Serial Old 单线程 Full GC，整个应用 STW 了 11.4 秒： 2020-0
同事问：订单状态怎么倒着走了 做微服务改造时，订单状态变更要通过 MQ 广播给下游（积分、优惠券、物流、通知）。上线一周后，物流组的同事找过来："你们发的消息顺序不对，我这边先收到'已发货'，后收到'已付款'，状态机直接报错。" 我看了一眼他的日志，确实是反的： 14:03:21.114 收到订单消
运营找上门：同一笔积分被发了两次 七月的一个下午，运营拿着工单来找我："用户 88372 投诉，说下单后积分到账两次，多领了 300 积分。" 我第一反应是代码里有循环或者被调用了两次。翻了消费日志，同一个 msgId 确实处理了两遍： 2020-07-05 14:22:31.117 [Consum
面试官问：你们的分布式锁为什么选 Redis 不选 ZK 七月底跳槽面试，被问到分布式锁。我说我们用 Redis + Redisson。面试官追了一句："Redis 锁在主从切换时会丢锁，你们业务能接受？为什么不用 Zookeeper？" 我当时答得挺虚的。回来把三种实现都搭了一遍，用 JMeter
压测时发现的怪事：接口 TP99 高但 CPU 才 30% 六月份做订单列表接口的压测，200 并发、跑 5 分钟，结果很怪：QPS 卡在 1400 上不去，TP99 到了 620ms，但应用服务器 CPU 只有 30% 出头，数据库连接池（HikariCP，最大 20）也没打满，MySQL 那边
新同事接手网关，问我的第一个问题：Predicate 和 Filter 到底啥区别 上周把网关交给组里另一个同学维护。他看了半天配置问我：predicates 和 filters 都是配在 route 下面的，凭什么一个叫断言、一个叫过滤器，它们分别什么时候执行？ 这个问题挺好，我当年也绕了一阵。这
早上八点，消费积压告警：lag 320 万 6 月 1 号早上八点十几分，钉钉机器人开始刷屏：ORDER_EVENT_TOPIC 的消费 lag 突破 300 万，还在涨。 这个 topic 是订单事件流，下游有 5 个消费者组：风控、数据同步、搜索索引、积分、客服。lag 涨到 320 万意味着这
压测雪崩复盘：每一层的超时都设成了 30 秒 5 月初做 618 前的压测。我们给网关发了 3000 QPS 的流量，持续 90 秒，结果整个交易链路崩了：网关大量 504，订单服务 CPU 98%，成功率从 99.9% 掉到 34%，压测停止后还花了 4 分钟才恢复。 排查时发现一个很荒谬的事：从
第一次拆分拆错了，我们重做了一版 去年 10 月到今年 2 月，我把单体拆成了 7 个服务。上线稳定运行两个月之后，我自觉地把其中两个又合并了、一个重新划了边界。 原因说出来很打脸：我们造了个 common-service。它承担了字典、地区、短信模板、附件上传、金额计算这些"大家都要用"的能力，被
周会上定的事：6 周内把 Netflix 那一套换成 Alibaba 3 月底的架构周会，我把一张图投到了屏幕上：Spring Cloud Netflix 的组件里，Hystrix、Zuul 1.x、Ribbon、Archaius、Turbine 五个都挂着"maintenance mode"或者干
七个服务七套 JVM 参数，我整理了一份模板 4 月底盘了一遍生产上 7 个微服务的启动参数，发现全是复制粘贴来的，来源各不相同： user-service: -Xms512m -Xmx2g order-service: -Xms4g -Xmx4g -Xmn2g -XX:+UseG1GC
改了 Nacos 配置页面，服务怎么没反应 "我把限流阈值从 500 改成 200 了，Nacos 上点了发布，等了五分钟还是没生效。" 这是组内被问过最多的一个问题，我自己也卡过。Nacos 同时做注册中心和配置中心，但这两块的机制完全不同——注册是实时的，配置热更新是有条件的。这篇把我们落地 N
Seata AT 模式上线两周，我们踩了七个坑 订单库拆出去之后，"创建订单"和"扣减库存"就不再同一个数据库事务里了。以前靠一个 @Transactional 保证的事，现在要跨两个服务两个库。 3 月底到 4 月，我用 Seata 1.1.0 把这条链路补上了。这篇记一下选型过程、AT 模式到底
把 MySQL 5.7 升到 8.0，五个报错排了三天 4 月初，我们把订单库的 MySQL 从 5.7.26 升到了 8.0.19。起因很实际：运营要做"每个用户的消费排名"，5.7 里只能用会话变量写那种很难维护的 SQL，8.0 有窗口函数 ROW_NUMBER()，一行搞定。 升级过程本身（
