从今天起开一个固定栏目：每天读一本书，把里面的东西压缩到 20 分钟内读完，再写点自己的看法。方向是金融、AI、历史这三块——前两块是饭碗，最后一块是让人不至于把今年发生的事都看成世界末日。 这个栏目不打算做成读书笔记的搬运。我做了八年 Java 和 AI，又自己跑过出海盘子、也清零过两次，读这些书
为什么我们决定在非 LTS 版本上跑生产 JDK 24 今年三月发布，是非 LTS 版本。我们公司原来的规矩是只用 LTS，所以 JDK 24 刚出来时没人提议升级。 改变想法是因为三个具体需求：AI 服务里的虚拟线程 pinning 问题、推理结果回写服务的大堆小对象内存压力、以及函数计算场景的冷
语义缓存一直跑在 Redis Stack 上，Redis 8 说要合并进来 我们的语义缓存从 2024 年 9 月开始就跑在 Redis Stack 上（就是那个带 RediSearch 模块的发行版）。这套方案最大的别扭之处是：它跟官方主线版本是两套东西，运维要单独装，升级要跟 Stack 的节奏
冷启动 4.2 秒，函数计算按毫秒计费 我们有一部分服务跑在函数计算上（内部 FaaS 平台），按实际运行时间计费。其中一个是文档解析入口，Spring Boot 3.5 应用，冷启动实测 4.2 秒——也就是说每次冷启动，用户先付 4.2 秒的钱，其中真正干活的只有不到 1 秒。 去年我们试过 G
供应商挂了，我们的降级逻辑一行没生效 六月下旬的一个晚上，模型供应商华东区域故障，持续 23 分钟。我们有完整的降级设计（规则引擎兜底、熔断、重试），理论上最多影响一部分请求的响应时间。实际结果是：全线报错，客服系统完全不可用。 事后复盘，原因特别打脸：降级逻辑的入口写在了 catch (Model
知识库从 5 万文档涨到 320 万，第一版设计撑不住了 我们公司的知识库最早是给客服用的，5 万篇 FAQ，存储设计得很随意：一张 kb_doc 表，切片直接以 JSON 数组的形式塞在 chunks 字段里，向量存在 Milvus 里，两边用 doc_id 关联。 这个设计在 5 万篇的时候完全
我们有个 WebFlux 服务，没人愿意改它 我们有个网关服务是 2021 年用 WebFlux 写的，三个接口、两千多行，但组里除了我没人愿意碰它。原因很简单：那套 Mono/Flux 的链式调用，加上 .flatMap() 里嵌套 .zip() 的写法，改起来要花两倍时间，而且出错后堆栈完全看不
一次发版，37 个跑了两小时的任务全没了 五月底的一次例行发版，我们的合同审核 Agent 服务重启。重启完没多久，业务部门来问："我昨天下午提交的那批合同怎么一直显示'审核中'？" 查了一下，那次重启时正在执行的 37 个长任务全部丢失，其中最长的已经跑了 2 小时 17 分钟，完成了 60 多个
财务拿着一张 14.7 万的账单来找我 六月初，财务同事拿着模型账单发消息给我："你们那个智能运维 Agent，上个月花了 14.7 万？预算不是 5 万吗？" 我一看确实超了快三倍，而且这个 Agent 上线才一个月，日均任务量只有 420 个左右。 我花了两天把账单拆开分析，发现问题比想象的有意
三个团队写了三套几乎一样的东西 今年三月做季度复盘时，我们数了一下公司的 AI 建设：客服知识库、智能质检、合同审核，三个项目分属三个团队，各自实现了一遍模型调用封装、限流、审计日志、向量库接入、prompt 管理。代码重复度我粗略估了一下有 40% 以上。 更现实的问题是：三个项目都踩了同样的坑（
公司要求数据不出境，得换模型 四月底法务下了个通知：客服对话数据不能出境，我们正在用的海外模型必须换掉。当时系统基于 Spring AI 写的，第一反应是"换个 base-url 应该就行"，实际折腾了两周才稳定上线。 这篇记录接入国内模型的过程，主要是 Spring AI Alibaba 和 Op
我们用传统架构设计 AI 应用，处处别扭 过去一年半我做了三个 AI 项目：客服知识库、智能质检、合同审核助手。回头看，第一个项目（2023 年底的知识库）踩的坑最多，原因不是技术不熟，而是我在用设计传统后端系统的方式设计它。 具体表现是：设计了标准的三层架构（Controller / Servic
3200 行的 OrderService，AI 说拆成六个类 四月初我接手了一个历史模块的重构。OrderServiceImpl 单个文件 3218 行，包含下单、支付回调、退款、履约、对账、通知六种职责，方法之间互相调用，改一个地方要心惊胆战地检查半小时。这活儿我拖了两周没敢动。 后来试着把整个文
CR 时跟同事吵了一架 上周做订单模块的代码评审，同事设计的新表里有个 ext_data 字段，类型 json，里面塞了发票信息、优惠券信息、配送偏好、渠道来源，一共十几个子字段。他的理由是"这些字段每个订单不一定都有，建十几个列太浪费"。 我在评论里提了反对意见，他回了一句"MySQL 8 原生支
风控要在 200ms 内给出决策，而模型要 150ms 我们电商风控原来是一套 Drools 规则引擎，几百条规则，命中就拦截。去年底开始加模型：用用户最近 5 分钟的行为序列算实时特征，喂给一个轻量模型打分，超过阈值就拦截。 难在时间预算。风控决策必须在用户下单后 200ms 内返回，而模型推理本
订单系统线程池被一个"智能"功能打满 三月下旬的一个下午，监控突然报警：订单履约服务的 Tomcat 线程池活跃数从平时的 40 冲到 200（最大值），接口 P99 从 180ms 涨到 12s，大量订单卡在"待履约"状态。 排查过程很快。看线程 dump，200 个线程里有 187 个卡在同一个
