欢迎访问

背景 高并发网络服务里，Reactor 和 Proactor 是两个绕不开的模型。 很多争论其实都在混淆一个问题： 你是在等“就绪事件” 还是在等“异步操作完成事件” 核心差异 Reactor 内核告诉你哪个 fd 就绪 业务线程自己 read/write Proactor 业务先发起异步 IO 内核完成后通知你结果 在 Linux 常规栈里，很多框架本质上还是 Reactor；在 io_uring 这类能力更强的接口下，Proactor 风格更容易落地。 简化示意 // Reactor 风格：事件到达后主动读 void onReadable(int fd) { char buf[4096]; ssize_t n = ::read(fd, buf, sizeof(buf)); if (n > 0) { handleRequest(buf, n); } } // Proactor 风格：提交后等待完成回调 void submitRead(Connection* c) { io_uring_prep_read(c->sqe, c->fd, c->buf, c->cap, 0); } void onReadComplete(Connection* c, int res) { if (res > 0) { handleRequest(c->buf, res); } } 选择建议 现有生态以 epoll 为主：优先 Reactor 追求极致吞吐且能接受复杂度：考虑 Proactor/io_uring 团队经验不足时，别为“更先进”盲目迁移 总结 模型没有绝对优劣，只有场景匹配。 ...

背景 CI 最容易浪费时间的阶段之一，就是镜像构建。 常见慢点： 每次都重新下载依赖 layer 顺序不合理导致缓存失效 多架构构建没有缓存复用 BuildKit 的关键能力 cache mount 并行构建 远程缓存导入导出 # syntax=docker/dockerfile:1.7 FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN --mount=type=cache,target=/go/pkg/mod go mod download COPY . . RUN --mount=type=cache,target=/root/.cache/go-build \ CGO_ENABLED=0 GOOS=linux go build -o app . GitHub Actions 示例 - uses: docker/setup-buildx-action@v3 - uses: docker/build-push-action@v6 with: context: . push: true tags: ghcr.io/org/app:latest cache-from: type=registry,ref=ghcr.io/org/app:buildcache cache-to: type=registry,ref=ghcr.io/org/app:buildcache,mode=max 总结 提速的核心不是换机器，而是设计好缓存路径。 构建系统越早做缓存治理，团队长期效率越高。 CI 慢不是宿命，很多时候只是缓存没被认真设计。

先说结论 多数业务服务里，epoll 依然是稳妥选择。io_uring 在某些高并发 IO 场景能更快，但复杂度也更高。 epoll 的优势 生态成熟，排障资料多 编程模型稳定 与现有网络库兼容性好 对于大部分 API 服务，epoll 足够用。 io_uring 的价值点 减少系统调用次数 提升批量提交与完成处理效率 在特定负载下降低延迟 但它要求你理解提交队列、完成队列、内核版本差异等细节。 选型建议 先压测当前 epoll 方案，定位真实瓶颈 若瓶颈明确在 IO 提交/完成路径，再评估 io_uring 预留回退方案，避免一次性全量切换 团队视角 技术选型不只看 benchmark，还要看： 团队掌握程度 线上问题可定位性 长期维护成本 小结 新能力值得关注，但架构决策应以稳定收益为中心。对大多数团队来说，逐步引入比激进替换更现实。

指标系统最怕什么 很多团队一开始埋点很积极，过一阵就发现存储暴涨、查询变慢。高基数标签通常是罪魁祸首。 典型高危标签： user_id request_id 完整 URL 路径 动态错误信息 设计原则 指标看聚合趋势，不看单请求细节 单请求细节放到 trace 或日志 标签值集合必须可控 一个可行做法 http.route 用模板路由，如 /users/:id 错误类型归类为固定枚举 把业务自定义标签做白名单审核 工程措施 在 SDK 层做标签拦截 给 metric pipeline 增加 cardinality 预算告警 定期扫描 top N label pairs 小结 可观测性不是“埋得越多越好”。指标、日志、追踪各司其职，系统才能长期稳定运行。

为什么协程不是魔法 C++20 协程让异步代码写起来像同步，但它只解决语法组织，不自动提供高性能调度。 真正决定上限的是： 任务队列策略 IO 事件分发 唤醒与线程绑定方式 一个简化示意 task<int> fetch_and_parse(socket& s) { auto buf = co_await async_read(s); co_return parse(buf); } 这段很优雅，但背后必须有 executor 驱动 co_await 的挂起与恢复。 调度层常见坑 所有任务丢进一个全局队列，热点锁竞争严重 IO 线程和计算线程混跑，尾延迟放大 协程对象生命周期管理混乱 实践建议 IO 与 CPU 密集任务分池 减少跨线程恢复，尽量本地唤醒 在高频路径避免动态分配 结语 协程把异步写法变自然，但高性能系统仍然遵循老规律：调度、内存、锁竞争。语法升级不能替代架构设计。

背景 缓存能提升性能，但也最容易制造隐性 bug。 线上常见问题： 数据库已更新，缓存还是旧值 热点 key 失效瞬间把数据库打穿 多服务写入同一份数据，更新顺序错乱 在 Go 服务里，缓存一致性通常不是“技术选型”问题，而是“写路径设计”问题。 常见策略 Cache Aside 最常见模型：读先查缓存，未命中再查库并回填；写时先写库，再删缓存。 func (s *UserService) GetUser(ctx context.Context, id int64) (*User, error) { key := fmt.Sprintf("user:%d", id) if val, ok := s.cache.Get(ctx, key); ok { return decodeUser(val) } user, err := s.repo.FindByID(ctx, id) if err != nil { return nil, err } _ = s.cache.Set(ctx, key, encodeUser(user), 5*time.Minute) return user, nil } func (s *UserService) UpdateUser(ctx context.Context, user *User) error { if err := s.repo.Update(ctx, user); err != nil { return err } key := fmt.Sprintf("user:%d", user.ID) _ = s.cache.Delete(ctx, key) return nil } 这个模型简单、可靠，适合大多数业务系统。 双删策略的取舍 有些场景会用“先删缓存，再写库，延迟再删一次”。 它能降低极端并发下的脏读概率，但不是银弹。更关键的还是： 写操作是否集中在一条服务链路 有没有事件通知机制统一刷新 key 的 TTL 是否合理 避免缓存雪崩 两个实用点： TTL 加随机抖动 热点 key 做单飞保护 var g singleflight.Group func (s *UserService) GetUserWithSingleflight(ctx context.Context, id int64) (*User, error) { key := fmt.Sprintf("user:%d", id) v, err, _ := g.Do(key, func() (interface{}, error) { return s.GetUser(ctx, id) }) if err != nil { return nil, err } return v.(*User), nil } 总结 缓存一致性最重要的不是某个技巧，而是明确一致性目标： ...

成本高不一定是机器贵 很多集群成本高，核心原因是资源配置粗放： request 远大于实际使用 HPA 指标失真导致过度扩容 长尾任务长期占用节点 第一件事：拉齐 request 和真实负载 建议先看 7 到 14 天数据，按 P95 使用量设置 request，再保留安全余量。盲目按峰值配置，浪费通常最大。 第二件事：把弹性策略拆开 在线服务：偏稳定，防抖优先 离线任务：可抢占，成本优先 把工作负载分层后，调参会清晰很多。 第三件事：节点池治理 基础池用稳定机型承载核心服务 弹性池接临时流量和批任务 定期清理空转节点 额外收益点 镜像瘦身缩短拉取时间 减少跨可用区流量 对低优先级任务使用 Spot/抢占实例 小结 成本优化不是一次性动作，而是持续运营。先让容量模型可信，再谈更激进的降本策略。

背景 Rust 的 Result 很强，但很多项目还是会遇到同一个问题： 错误被一路 ? 传上去 日志里只有一个模糊报错 出问题时不知道是哪个环节失败 这通常是错误分层没有做好。 一条实用原则 库层定义结构化错误类型 应用层补充上下文并统一输出 use thiserror::Error; #[derive(Debug, Error)] pub enum RepoError { #[error("record not found")] NotFound, #[error("db error: {0}")] Database(String), } use anyhow::{Context, Result}; pub async fn get_user_handler(id: i64, svc: &UserService) -> Result<UserDto> { let user = svc .find_user(id) .await .with_context(|| format!("get user failed, id={id}"))?; Ok(UserDto::from(user)) } 日志里要带可关联字段 只打印错误文本通常不够，至少带上： 请求 ID 用户或租户标识 关键资源 ID tracing::error!( request_id = %request_id, user_id = user_id, error = %err, "failed to get user" ); 总结 Rust 错误处理做得好，排障效率会明显提升。 ...

背景 裸重启进程很简单，但线上会带来短暂不可用。优雅重启的目标是： 停止接收新连接 等待在途请求处理完 平滑切换到新进程 Go 侧的退出处理 srv := &http.Server{Addr: ":8080", Handler: mux} go func() { if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed { log.Fatal(err) } }() sigCh := make(chan os.Signal, 1) signal.Notify(sigCh, syscall.SIGTERM, syscall.SIGINT) <-sigCh ctx, cancel := context.WithTimeout(context.Background(), 15*time.Second) defer cancel() _ = srv.Shutdown(ctx) Shutdown 会先关闭监听，再等待连接收尾。 systemd 关键配置 [Service] ExecStart=/opt/app/server Restart=always RestartSec=2 TimeoutStopSec=20 KillSignal=SIGTERM KillSignal=SIGTERM 给应用机会走优雅退出逻辑 TimeoutStopSec 要大于应用 Shutdown 超时 发布建议 先在网关层摘流量 再重启实例 观察错误率与连接数回落 小结 优雅重启不是一个函数调用，而是应用与进程管理器协同设计。把退出路径做好，发布风险会明显下降。

先明确目标 “零拷贝”不是为了炫技，而是为了减少： 内存分配次数 数据复制成本 GC 或 allocator 压力 在高吞吐场景里，收益通常很直接。 借用驱动的数据视图 Rust 的借用模型天然适合做零拷贝读取： #[derive(Debug)] struct Header<'a> { trace_id: &'a str, method: &'a str, } fn parse_header<'a>(trace_id: &'a str, method: &'a str) -> Header<'a> { Header { trace_id, method } } 这里没有分配新字符串，只是借用了输入切片。 适用边界 适合： 协议解析 日志处理 消息中间件消费链路 不适合： 需要长期持有数据跨线程传递 接口边界复杂，生命周期管理成本过高 工程上的折中 热路径零拷贝 冷路径允许复制换可读性 用基准测试验证收益，而不是主观判断 小结 零拷贝是性能工具，不是教条。只有在瓶颈路径上，它才是值得支付复杂度的优化。