小曾博客

AQS框架源码解读——从ReentrantLock说起 引言 先看一段极其常见的代码： public class Counter { private final ReentrantLock lock = new ReentrantLock(); private int count = 0; public void increment() { lock.lock(); try

大模型微调技术对比：LoRA、QLoRA、全参微调 引言 去年冬天，我接手了一个企业知识库问答项目。客户是一家大型律所，他们希望把内部十万份合同、判例、法律意见书灌进模型，让律师用自然语言就能检索和推理。一开始我们选了最直接的路子——调用 GPT-4 的 API，配合 RAG 做检索增强。跑了两周，问题来了：律所对数据出境极其敏感，合同文本不允许发往任何第三方 API；

K8s网络插件CNI原理：Calico vs Flannel 引言 凌晨两点，监控告警炸了。一个部署在K8s集群里的微服务突然出现间歇性超时，但容器本身CPU、内存都正常。排查了半天，最后定位到问题：跨节点Pod通信丢包。 这不是玄学，而是网络插件选型埋下的坑。你可能也遇到过： Flannel的VXLAN模式下，跨节点延迟比同节点高出10倍； Calico的BGP模式看起来很美好

DDD领域驱动设计落地实践与六边形架构 引言 先讲一个我亲身经历过的项目事故。 三年前我接手一个\

Java 21虚拟线程（Virtual Threads）深度解析 引言 2023年9月，Java 21正式发布，虚拟线程（Virtual Threads）作为JEP 444的正式特性落地。这不是一次普通的API更新，而是Java并发模型自1996年以来最重大的变革。 先看一个真实场景。某电商平台的订单查询服务，采用经典的\

Go项目工程化：wire依赖注入与分层架构 引言 先说一个我亲身经历的故事。 三年前，我接手了一个中型 Go 微服务项目，大约 40 个包、200 多个文件。项目最初只有 3 个人写，两年后扩展到 12 个人。上线时一切正常，但当新同事要加一个\

LangChain Memory模块：对话历史管理最佳实践 引言 去年冬天，我帮一家做智能客服的团队做架构评审。他们的系统上线三个月，用户投诉量却一直降不下来。问题很有意思：用户在第一轮对话里说了\

Helm Chart模板开发与Release管理 引言 先说一个我亲身经历过的生产事故。 2023年，我负责的一个微服务集群要从中东机房扩展到欧洲机房。运维同学兴高采烈地跑来说：“Chart 都写好了，改个 values.yaml 就能上。” 结果上线当天，Pod 全部 CrashLoopBackOff。排查了三个小时才发现——中东环境的 values-prod.ya

Sentinel流控降级源码分析 引言 去年双十一大促前夜，我所在团队负责的一个订单查询服务突然在压测中出现雪崩：下游库存服务因为一次慢SQL导致响应时间从50ms飙到3s，订单服务线程池瞬间被打满，紧接着整个调用链路像多米诺骨牌一样倒下。事后复盘时我们发现，如果当时在订单服务对库存接口配置了熔断降级规则，这场事故完全可以避免。 这就是流量治理要解决的

protobuf + gRPC拦截器链实现 引言 想象一下这样的场景：你负责的微服务系统有 30 多个服务，某天凌晨告警群炸了——某个服务的 P99 延迟从 20ms 飙升到 2s。你打开日志系统，发现每个服务的日志格式都不一样，有的用 logrus，有的用 zap，有的直接 fmt.Println；你想追踪一个请求的完整链路，却发现 trace ID 在跨服务

Prompt Engineering最佳实践与链式推理 引言 去年双十一大促前夜，我们的智能客服系统突然集体“降智”：同一个退款问题，上午还能给出准确的三步操作指引，晚上就开始胡编乱造，甚至建议用户“联系火星客服”。排查了半天，模型没换、温度没调、知识库没更新，唯一的变量是——我们在Prompt里加了一句“请尽量简洁地回答用户问题”。 这就是Prompt Engineeri

分布式配置中心架构设计 引言 凌晨两点，线上告警群炸了。某个核心服务的数据库连接池被打满，排查发现是一位同事把连接池上限从 200 改成了 20——他改的是配置文件，但忘了通知运维重新发布。更糟的是，这个配置分散在 12 个实例上，运维只能一台台登录机器去改，改完还得一台台重启。 这个场景几乎每个做微服务的团队都经历过。配置，这个看起来最不起

FastAPI依赖注入系统设计剖析 引言 去年我接手了一个日活百万的AI服务网关，代码基于FastAPI构建。上线三个月后，一个诡异的线上问题让我彻夜难眠：在QPS突破8000时，部分请求的数据库连接竟然串了——A用户的请求拿到了B用户的租户上下文，导致跨租户数据泄露。 排查了两天，最终定位到问题根源：一个使用了Depends的依赖函数内部持有可变状态，

Spring Boot自动配置原理与自定义Starter 引言 先讲一个我亲身经历的线上事故。 三年前，我负责的一个订单服务在凌晨两点突然出现大量超时告警。排查发现，一个刚入职的同事为了让日志链路追踪生效，在 pom.xml 里引入了公司内部的 trace-log-starter，但忘了在 application.yml 里配置 trace.sample-rate。结果这个

Channel底层实现与select多路复用 引言 先说一个我真实踩过的坑。 几年前我负责一个订单对账服务，需要同时监听三个上游：Kafka 消费到的订单变更、定时器触发的对账批处理、以及运维下发的紧急停止指令。当时年轻气盛，直接写了三个 goroutine，每个 goroutine 各自处理自己的 channel，然后用一堆 sync.Mutex 和一个共享的