从今天起开一个固定栏目：每天读一本书，把里面的东西压缩到 20 分钟内读完，再写点自己的看法。方向是金融、AI、历史这三块——前两块是饭碗，最后一块是让人不至于把今年发生的事都看成世界末日。 第一本很适合开栏：《金钱心理学》（The Psychology of Money），摩根·豪泽尔。 它的核心
微服务架构中的韧性设计：Resilience4j 指南 在分布式系统中，网络延迟、服务不可用等问题不可避免。Resilience4j 是一个轻量级的容错库，帮助我们构建更具弹性的应用。 核心模块 Circuit Breaker（熔断器） 当下游服务出现故障时，熔断器会暂时中断调用，避免级联故障。 R
晚上八点半，所有接口一起超时 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
8200 万行的订单表，加个索引要 6 小时 2021 年 2 月，我们的 t_order 表数据量到了 8200 万行，物理大小 68 GB（含索引）。 mysql> SELECT table_name, table_rows, -> ROUND(data_length/1024/10
财务对账少了 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.
风控服务被 Full GC 拖出的长尾 2021 年 1 月底，风控服务的 P99 突然变差。这个服务是同步调用链路上的一环，上游给的超时是 800 ms，一旦它慢了，整个下单流程都会受影响。 当时的配置：JDK 8u272，8 G 堆，CMS + ParNew。 $ jstat -gcutil 1
安全组的一封邮件 2021 年 1 月 20 号上午，公司安全组群发了一封邮件，标题是《关于 fastjson 反序列化漏洞的紧急排查通知》，要求各业务线在周五前上报使用了 fastjson 的服务清单和版本。 我心里咯噔一下。我们三个核心服务全在用 fastjson，版本 1.2.62。 $ mv
review 时和同事吵了一架 1 月中旬做 code review，我写了一段统计订单金额的代码： long total = orders.stream() .mapToLong(Order::getAmount) .sum(); 同事评论："Stream 有性能
一次资损：限领 1 张的券，用户领了 2 张 1 月初的一个上午，运营在群里 @ 我：一张"新客专享 50 元券"，配置的是每人限领 1 张，有用户领到了 2 张，已经核销了一张。 我查了数据库： mysql> SELECT user_id, coupon_id, count(*) c FROM c
商品详情页 P99 1.8 秒，五个 RPC 串行调用 12 月中旬，前端同学甩过来一张截图：商品详情页首屏白屏 2 秒多，用户投诉"点商品没反应"。我去看 SkyWalking 的拓扑，这个接口平均 690 ms，P99 1.8 s，P999 3.2 s。 接口干的事很简单，串着调了 5 个下游：
扩容前的一次基准压测 2020 年 11 月，订单事件 topic 的日均写入量从 3000 万条涨到 1.1 亿条，运维要我给个扩容方案。我没直接拍板加机器，先用 kafka-producer-perf-test.sh 在现有 3 台 broker 上跑了一轮，想摸清单机的真实上限。 机器配置：1
