排查一次下单失败，登了 7 台机器 4 月初有用户反馈下单失败，报错是"系统繁忙"。这个接口要经过 7 个服务：网关 → 订单 → 库存 → 价格 → 风控 → 优惠券 → 支付。 我们的排查方式是：先猜可能是哪个服务，登录它的机器 grep 日志，找不到就换下一个。那天从晚上八点查到十点半，最后在
安全组的一封邮件 2021 年 1 月 20 号上午，公司安全组群发了一封邮件，标题是《关于 fastjson 反序列化漏洞的紧急排查通知》，要求各业务线在周五前上报使用了 fastjson 的服务清单和版本。 我心里咯噔一下。我们三个核心服务全在用 fastjson，版本 1.2.62。 $ mv
起因：前后端又为接口字段吵起来了 九月末的一次需求联调，前端同学找我："你这个接口的 amount 字段到底是字符串还是数字？我这边拿到的有时候是 "19.90"，有时候是 19.9。" 查了一下，是 BigDecimal 序列化的问题，有些地方用了 @JsonSerialize(ToStringS
新人装环境装了两天，我写了份 docker-compose.yml 组里 2 月来了个新同事。第一天拉代码，第二天还在拉代码——不是网速问题，是在装环境：MySQL 8.0、Redis 5.0、RocketMQ 4.6.1、Nacos 1.1.4、Elasticsearch 7.5，一个一个装，中间
一个 780 MB 的镜像，让每次发布多等三分钟 我们去年底把服务容器化了，当时赶时间，Dockerfile 写得非常粗糙： FROM openjdk:8-jdk WORKDIR /app COPY target/order-service.jar app.jar EXPOSE 8080 ENTRY
交接过来的 Jenkins 里躺着两个 Freestyle 任务 12 月中旬，运维同事离职，他把公司那台 Jenkins 丢给了我。机器上跑的是 Jenkins 2.190.3，装在一台 4 核 8G 的 CentOS 7 虚拟机上，加起来只有两个 Freestyle 任务：一个构建后端 jar，
运维问我们：服务器上装的 JDK 要不要交钱 11 月底，运维在群里发了张截图，是某篇公众号文章的标题："Oracle JDK 开始收费，你们公司准备好被起诉了吗"。他问我们的服务器要不要处理。 我把许可协议翻了一遍，发现事情没那么吓人，但确实得做个决定。这篇是整理出来的结论。 到底改了什么 201
我给一个祖传方法补单测，改到怀疑人生 9 月初，师兄让我给订单模块的几个核心方法补单元测试，说是要接入 SonarQube 看覆盖率。我挑了个"看起来最简单"的方法开工，然后就掉坑里了。 方法长这样： @Service public class OrderService { public
第一次独立部署：catalina.out 里那几行看不懂的报错 九月份，师傅让我自己往测试服务器部署一次项目。我以为就是把 war 包扔进去，结果从下午两点折腾到晚上八点。这篇把我那天遇到的四个坑和后来整理的排查顺序记下来，免得下次再花六个小时。 环境：CentOS 7.4，JDK 8u151，To
本地跑得好好的，一上测试环境就 NoSuchMethodError 那次是给项目加了个 HTTP 工具类，本地单元测试全绿，提交完心情不错。结果测试环境部署完，一调用就炸： java.lang.NoSuchMethodError: org.apache.http.impl.client.Closea
