本文源码基线为 Go 1.26.2、Linux/amd64。调度器变化频繁；函数名、队列容量和分支顺序均以固定版本源码为准。 Go 调度器解决的核心问题是：怎样把大量 goroutine 映射到较少的 OS 线程，同时控制竞争、阻塞和调度延迟。 理解调度器不需要记住所有函数。先抓住三件事：执行资格属于 P，等待发生在 G 上，真正运行机器指令的是 M。 先观察：两个P为什么会有更多线程 下面的程序把 GOMAXPROCS 设为 2，同时制造 runnable G、Timer 和一个阻塞 syscall： GOpackage main import ( "runtime" "syscall" "time" ) func main() { runtime.GOMAXPROCS(2) for range 20 { go func() { for { runtime.Gosched() } }() } var pipe [2]int if err := syscall.Pipe(pipe[:]); err != nil { panic(err) } defer syscall.Close(pipe[0]) defer syscall.Close(pipe[1]) go func() { var b [1]byte _, _ = syscall.Read(pipe[0], b[:]) }() time.AfterFunc(500*time.Millisecond, func() { _, _ = syscall.Write(pipe[1], []byte{1}) }) time.Sleep(3 * time.Second) } 先构建再观察调度快照，避免把 go run 自身的编译进程混入输出： ...

本文源码基线为 Go 1.26.2、Linux/amd64。源码链接固定到 go1.26.2 tag；其他操作系统、架构和构建模式的入口汇编会不同。 一个 Go 程序可以只有几行代码，但它的第一条指令并不属于 main.main。在用户函数开始前，可执行文件必须先建立线程本地状态、调度资源、栈和堆等运行环境。 本文先从 ELF 入口这个可观察事实出发，再沿 Linux/amd64 启动链追踪到 main.main。重点不是背诵初始化函数，而是回答：每一步补上了什么运行前提，编译器、链接器、runtime 和操作系统各自负责哪一段。 一个最小Go程序 以下程序表面上只有 goroutine、Channel 和一次函数返回： GOpackage main func main() { ch := make(chan int) go func() { ch <- 1 }() println(<-ch) } 这段程序的启动和运行依次经过编译、链接与操作系统装载。执行期间，runtime 把操作系统提供的线程、虚拟内存、信号和 I/O 事件转换成 Go 的调度、栈、堆和阻塞语义： TEXTGo源码 -> 编译器：机器码 + 类型/栈图/init task 等元数据 -> 链接器：用户包 + 标准库 + runtime -> ELF可执行文件 -> OS loader：建立初始线程和进程地址空间，跳到ELF入口 -> runtime启动：rt0 -> schedinit -> runtime.main | +-- 执行：G / M / P / runq +-- 栈：stack check / morestack / copystack +-- 内存：mcache / mcentral / mheap / GC +-- 等待：gopark / goready / timer / netpoll / syscall -> package init -> main.main 这里没有一个独立安装、解释字节码的“Go 虚拟机”：CPU 执行的是提前编译并链接好的本地机器码，runtime 也是可执行文件的一部分。标准库提供稳定 API，并在内部接入 runtime，例如 net.Conn 通过 internal/poll 使用 netpoll，sync 通过 runtime 等待设施挂起和唤醒 G。 ...

一次 Go 程序执行会经过编译器、链接器、标准库、runtime 与操作系统。下面从一段程序开始，依次展开各层的职责与协作关系。 一个程序的执行路径 下面的程序把本系列的主要公共抽象放进同一条调用链，并由每个语句引出后续的系统问题： GOpackage main import ( "context" "fmt" "net" "time" ) func main() { ctx, cancel := context.WithTimeout(context.Background(), time.Second) defer cancel() result := make(chan error, 1) go func() { var d net.Dialer conn, err := d.DialContext(ctx, "tcp", "127.0.0.1:8080") if err == nil { err = conn.Close() } result <- err }() select { case err := <-result: fmt.Println(err) case <-ctx.Done(): fmt.Println(ctx.Err()) } } 从这段程序及其运行环境，可以继续追问一组系统问题： ...

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 走： ...