李科燃的主页

“我们是不是应该写一个 Operator？” 这个问题在架构评审里出现的频率，远超 Operator 实际应该被使用的频率。Operator 是一个功能强大但成本不低的扩展机制——它值得被认真对待，不值得被滥用。 先想清楚为什么要写Kubernetes 原生提供的控制器（Deployment、StatefulSet、CronJob）已经能处理大多数无状态服务和简单有状态应用的生命周期管理。 Op

“云原生”这个词被滥用得已经没什么意义了。每个厂商都说自己的产品是云原生的，每篇架构文章都声称某方案”符合云原生理念”。但真正用过这套东西的人知道，云原生不是一个技术标签，它是一种对系统如何失败和恢复的不同假设。 一个根本性的假设转变传统运维假设基础设施是稳定的。机器不会随机消失，网络是可靠的，服务一旦部署就应该持续运行。运维的工作是在出问题时把系统恢复到正常状态。 云原生的基础假设是反过来的：

在 WSL2 里配置代理，绕不开的问题是：WSL2 和 Windows 宿主机不共享网络栈，WSL2 的 IP 每次启动都可能变化，宿主机的 IP 同样如此。 常见的方案是解析 /etc/resolv.conf 里的 nameserver： 123hostip=$(cat /etc/resolv.conf | grep -oP '(?<=nameserver ).*')e

调试容器网络问题的时候，大多数人习惯先跑 docker inspect，看一眼 IP，ping 一下，然后开始凭感觉排查。这个方式不是不行，只是效率很低。 真正有效的调试姿势，是理解 Docker 的默认网络模型建立在哪几块 Linux 内核原语上，以及这些原语之间是怎么拼在一起的。docker0 网桥是一个很好的入口。 三块拼图Docker 默认网络模式（bridge 模式）本质上是三个 Li

容器镜像构建这件事看起来简单，实际上坑不少。 选错工具不会立刻爆炸，但会在 CI/CD 流水线里积累隐患：构建速度慢、安全审计无从下手、在集群环境里需要挂载 Docker socket 导致权限失控。这篇文章不做工具大全，只讲几个真正值得关注的决策点。 核心问题：要不要依赖 Docker daemonDocker 的构建模型需要一个常驻的 daemon 进程（dockerd），并通过 /

在 Go 里，struct 和 map 各有用途：struct 是强类型、编译期检查的领域模型，map 是动态键值对，适合序列化、动态字段处理、模板渲染等场景。当两者之间需要互转时，有三条路可走，选哪条取决于你对类型信息、性能和字段控制的要求。 一个前置约束无论用哪种方法，struct 里参与转换的字段首字母必须大写（exported）。小写字段对包外代码（包括 reflect 和 encodin

API 文档和代码之间的漂移是微服务项目的慢性病。接口签名改了，文档没跟上，调用方踩坑，全靠口口相传。Swag 解决这个问题的思路是：把文档写进代码注释，工具来生成 Swagger 规范文件。 代价是你必须学一套注解语法。这篇文章把最常用的部分梳理清楚，跳过官方文档里那些模糊的示例。 项目级注解在 main.go 或路由初始化文件的顶部写一次，描述整个服务： 12345// @title

单例模式（Singleton Pattern）的意图只有一句话：确保某个类只有一个实例，并提供全局访问点。它是 GoF 23 种设计模式中最被滥用、也最常被误解的一个。 本文梳理 Python 中几种实现方式的本质差异，以及在 AI 基础设施工程中真实触发这个模式的场景。 四种实现方式1. Metaclass 拦截通过自定义元类拦截 __call__： 12345678910111213class

抽象工厂（Abstract Factory）解决的问题和工厂方法不同。 工厂方法管的是”怎么创建某一类对象”；抽象工厂管的是”如何保证一组相关对象来自同一个家族”。两者是层次性的差别，不是程度性的差别。 核心约束：产品族一致性假设你在构建一个 RAG 系统，需要三个组件：LLM 客户端、Embedding 模型、Tokenizer。 来自不同厂商的组件混用会出问题： OpenAI 的 embe

简单工厂模式（Simple Factory）不在 GoF 的 23 种设计模式之列，但它是很多人第一个真正用到的”模式”。它的意图只有一句话：把”该创建哪种对象”的判断逻辑，从调用方剥离出来，集中到一个工厂函数里。 理解这句话之前，先看它解决的是什么问题。 问题：创建逻辑散落在调用方假设你在写一个多模型推理路由，调用方需要根据配置决定用哪个 LLM 客户端： 1234567# 没有工厂的写法 ——