Git Submodule：原理与协作流程 git submodule 将一个独立 Git 仓库挂载到另一个仓库的工作树中。被挂载的仓库称为 submodule，外层仓库称为 superproject。父仓库记录的不是子模块文件副本或分支名，而是子仓库的某个提交 ID。 本文以 Git 官方文档 gitsubmodules 为准，使用一个最小的 app 与 libfoo 仓库示例说明其工作原理、日常操作和适用边界。 工作树（working tree） 是当前 commit 被检出到文件系统中的文件集合，也就是用户实际查看和修改的目录。它与暂存区和 Git 元数据目录不同： TEXT工作树 -- git add --> 暂存区（.git/index） 暂存区 -- git commit -> 提交对象（.git/objects/） 例如，third_party/libfoo 是 submodule 的工作树；该目录中的文件可以被编辑，但它们的提交历史、索引和对象保存在对应的 Git 目录中。 Submodule 结构 设主仓库为 app，其中有一个子模块 third_party/libfoo。它们是两个相互独立的仓库： TEXTapp (superproject，父仓库) ├── .gitmodules # 受版本控制的子模块声明 ├── src/ └── third_party/libfoo # submodule 工作树，也是独立 Git 仓库 └── ... 父仓库的一个提交中，third_party/libfoo 对应的树项模式是 160000，Git 称它为 gitlink。其对象 ID 是子仓库的 commit ID，例如： ...

Istio 流量管理教程 适用范围 本文基于 Istio 1.30.3 官方文档，说明 Sidecar 模式下的流量管理模型和核心 API。重点是理解 Istio 如何在不修改业务代码的前提下控制服务间流量。 本文覆盖： Gateway：网格边缘的入站或出站代理入口。 VirtualService：流量匹配、路由、超时、重试、故障注入、镜像。 DestinationRule：服务子集、负载均衡、连接池、熔断、异常实例剔除、TLS 策略。 ServiceEntry：把网格外服务加入 Istio 服务注册表。 Sidecar：限制 Envoy Sidecar 的入站端口和出站可见服务范围。 数据面排障思路：从路由、cluster、endpoint、listener 四类 Envoy 配置定位问题。 本文不覆盖 Istio 安装、Bookinfo 部署、Ambient 模式、授权策略、Telemetry API、多集群和生产发布流程。 流量管理模型 Sidecar 模式下，每个业务 Pod 注入一个 Envoy 容器。业务进程仍然访问 Kubernetes Service 或外部域名，真实转发行为由 Envoy 根据 Istio 配置决定。istiod 负责监听 Kubernetes 和 Istio 配置资源，把它们转换为 Envoy xDS 配置，并下发给数据面代理。 flowchart LR C[Client] --> IG[Istio Ingress Gateway / Envoy] IG --> A1[Service A Sidecar] A1 --> A2[Service A App] A2 --> A3[Service A Sidecar] A3 --> B1[Service B Sidecar] B1 --> B2[Service B App] ISTIOD[istiod] -. xDS .-> IG ISTIOD -. xDS .-> A1 ISTIOD -. xDS .-> A3 ISTIOD -. xDS .-> B1典型 HTTP 调用路径： ...

Envoy 请求生命周期与静态代理配置教程 适用范围 本文基于 Envoy v1.39.0 官方文档的 Life of a Request、快速开始、HTTP 路由、Admin、xDS 和访问日志文档，说明 Envoy 作为 HTTP 反向代理时的核心模型、静态配置方式、请求处理流程和排障入口。 示例目标： 本地启动一个后端 HTTP 服务。 Envoy 监听 10000 端口。 Envoy 将所有 HTTP 请求转发到 backend:80。 Envoy Admin 监听 9901 端口，用于查看运行时配置和指标。 核心术语 downstream：连接到 Envoy 的一侧。对于边缘代理，通常是外部客户端；对于 sidecar，可能是本地应用或服务网格内的其他代理。 upstream：Envoy 转发请求的目标端。通常是业务服务实例。 listener：绑定 IP 和端口，接收 TCP 连接或 UDP 数据报。一个 Envoy 进程可以有多个 listener。 filter chain：Envoy 的处理管线。listener filter 处理连接元数据，network filter 处理 L3/L4 字节流，HTTP filter 处理 HTTP 请求/响应流。 HTTP connection manager：HTTP 代理场景中的核心 network filter，负责协议编解码、路由匹配、HTTP filter chain 管理、访问日志、统计指标和本地响应。 ...

Blogs LLM Powered Autonomous Agents | Lil’Log - Lilian Weng 关于 LLM Agent 的经典综述，覆盖规划、记忆和工具使用。 Function calling | OpenAI API - OpenAI API 关于函数调用和工具调用的官方文档。 Model Context Protocol - MCP 官方文档，关注模型应用如何连接外部工具、数据和上下文。 A2A Protocol - Agent 与 Agent 之间通信和互操作的协议文档。 Equipping agents for the real world with Agent Skills | Anthropic - Anthropic 关于 Agent Skills 的官方博客，介绍能力封装和按需加载的思路。- The Agent Skills Directory Introduction - Agent Client Protocol - Agent Client Protocol 官方入门文档，定义客户端应用与 Agent 之间的标准交互方式。 Codex 应用服务器 | ChatGPT 学习 - Codex App Server 官方文档，介绍如何把 Codex 作为本地服务接入自定义客户端，支持会话、审批和事件流。 企业级 Agent 多智能体架构与选型指南 – 来自 1000+ 行业应用实践积累 - 面向企业级场景的多智能体架构和技术选型经验。 Projects openclaw/openclaw: Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞 NousResearch/hermes-agent: The agent that grows with you bytedance/deer-flow: An open-source long-horizon SuperAgent harness that researches, codes, and creates. With the help of sandboxes, memories, tools, skill, subagents and message gateway, it handles different levels of tasks that could take minutes to hours. ultraworkers/claw-code: An agent-managed museum exhibit, built in Rust with Gajae-Code / LazyCodex — developed and maintained with no human intervention. openai/codex: Lightweight coding agent that runs in your terminal multica-ai/multica: The open-source managed agents platform. Turn coding agents into real teammates — assign tasks, track progress, compound skills.

Redis Cluster：从 Sentinel 到分片与故障转移 Redis 高可用有两个常见答案：Sentinel 和 Cluster。它们并不是同一套方案的两个名字。 Sentinel 解决的是一组主从节点如何自动切主；Cluster 除了故障转移，还要把数据和请求分散到多个 master。理解 Cluster，只需要先抓住一条主线： TEXTkey -> hash slot -> master -> 执行命令 | +-> replica 复制并在故障后接管 下文先完成选型，再沿着一次请求看 slot 路由，最后解释迁移和故障转移。 1. Sentinel 和 Cluster 怎么选 Sentinel（哨兵模式）由两部分组成： TEXTRedis 数据节点：1 个 master + 若干 replica，彼此保存同一份完整数据 Sentinel 进程：监控 master，协商故障状态，选择并提升 replica Sentinel 进程不保存业务数据，也不负责分片。切主以后，客户端需要发现新 master 并重新连接。它提高了可用性，但单个复制组的容量和写入吞吐仍受一个 master 限制。 所谓“哨兵集群”，通常是用多个 Sentinel 共同监控主从复制组，常见部署是 3 个。达到配置的 quorum 后，master 才会被判为客观下线；真正发起故障转移还需要获得 Sentinel 多数授权。 Cluster 则把数据拆到多个 master： ...

Redis 持久化：从一条 SET 命令看 RDB 与 AOF 沿着下面这条命令观察数据怎样进入内存、AOF 和 RDB，最后又怎样在重启时恢复： REDISSET token abc EX 60 它表达了两项状态： TEXTvalue(token) = "abc" expire(token) = 当前时间 + 60 秒 Redis 有两种方式把这两项状态保存到磁盘： TEXTRDB：保存某个时刻的 value + expire 快照 AOF：保存能够重建 value + expire 的写命令 主要源码入口： 环节 源码 SET 执行与过期时间改写 src/t_string.c:setGenericCommand 写命令传播 src/server.c:call、propagateNow AOF 编码、写入与刷盘 src/aof.c:feedAppendOnlyFile、flushAppendOnlyFile RDB 编码、保存与加载 src/rdb.c:rdbSave*、rdbLoadRio* AOF rewrite 与加载 src/aof.c:rewriteAppendOnlyFileBackground、loadAppendOnlyFiles 自动持久化调度 src/server.c:serverCron 下文每个 C 代码块首行都标注 源码文件:函数；/* ... */ 表示省略了与当前链路无关的源码。 ...

Redis 过期和淘汰：从 SET token abc EX 60 开始 先固定一条命令： TEXTSET token abc EX 60 这条命令写入了一个 key，并给它挂上 TTL。之后 token 会遇到两条删除路径： 路径 触发点 对 token 的影响 expire 过期 到达 EX 60 对应的过期时间 读路径把它视为已过期，后台扫描也可能删除它 eviction 淘汰 Redis 内存超过 maxmemory 按 maxmemory-policy 判断它是否进入淘汰候选 全文围绕这条 token 主线展开：TTL 写到哪里、到期后怎样被发现、删除时发生什么、 内存压力下又怎样被淘汰策略处理。 文中的源码摘录保留主线分支，省略 Cluster、module、统计细节和错误处理。 SET token abc EX 60 写入了什么 Redis 的 DB 里有两套和 token 相关的索引： C/* server.h，省略其他字段 */ typedef struct redisDb { kvstore *keys; /* 当前 DB 的全部 key */ kvstore *expires; /* 设置了 TTL 的 key */ unsigned long expires_cursor; } redisDb; 执行 SET token abc EX 60 后，token 会出现在 db->keys 中；因为带 TTL， 它也会出现在 db->expires 中。两套索引指向同一个 kvobj，过期时间跟着 kvobj 走： ...

Redis 事件循环 这篇不按 API 一个个介绍，而是跟着一个具体请求读源码。先固定场景： TEXT系统：Linux，使用 epoll 连接：普通 TCP，不考虑 TLS 线程：io-threads = 1 监听 socket：fd = 6 客户端 socket：fd = 8 客户端发送：SET name alice 要追的不是一堆互相独立的函数，而是下面两次唤醒： TEXT第一次 epoll_wait 返回 fd=6 可读 -> accept 新连接 -> 得到 fd=8 -> 给 fd=8 注册读回调 第二次 epoll_wait 返回 fd=8 可读 -> 读请求 -> 执行 SET -> 生成 +OK -> 下一轮 beforeSleep 写回客户端 主要源码按这个顺序看： ...

Redis 复制 用这条命令看 Redis 复制的数据流： BASHSET token abc EX 60 它在 master 上执行一次，随后进入复制流。replica 重放的命令会被改写为： TEXTSET token abc PXAT <absolute-millisecond-timestamp> 主线： TEXTREPLICAOF -> connectWithMaster -> syncWithMaster -> PSYNC -> CONTINUE：补 backlog -> FULLRESYNC：加载 RDB 基线 SET token abc EX 60 -> 改写 PXAT -> 写入复制流 -> backlog + replica 输出缓冲 -> replica 以 CLIENT_MASTER 身份重放 以下代码均为源码截取，只保留影响这条路径的判断和赋值。 复制历史 部分重同步依赖 replid + offset + backlog。 ...

Redis 命令执行 这篇看一条命令从客户端发到 Redis 后，源码里大概怎么走。例子还是： BASHSET name alice 客户端一般发的是 RESP： TEXT*3\r\n$3\r\nSET\r\n$4\r\nname\r\n$5\r\nalice\r\n 主线可以压成这一条： TEXTreadQueryFromClient -> processInputBuffer -> processMultibulkBuffer / processInlineBuffer -> preprocessCommand -> processCommandAndResetClient -> processCommand -> call -> setCommand -> addReply -> handleClientsWithPendingWrites / writeToClient 主要源码： 环节 源码 读请求、协议解析、回写 src/networking.c 查命令、校验、调度 src/server.c / src/server.h 命令声明 src/commands/*.json / src/commands.def SET 实现 src/t_string.c 写入数据库 src/db.c client：一条连接的执行现场 先看 server.h 里的 client，删掉大量无关字段后是这样： ...