欢迎访问

典型事故 业务高峰来临，HPA 根据 CPU 拉副本；同时 VPA 建议提升 requests，导致 Pod 频繁重建。结果不是稳定，而是不断抖动。 协同原则 HPA 负责“横向弹性”（副本数）。 VPA 负责“纵向建议”（资源基线）。 两者不要同时直接控制同一 Deployment 的同一资源维度。 实操模式 在线服务：HPA + VPA(recommendation only)。 离线作业：VPA(auto) + 关闭 HPA。 把 VPA 建议周期性写回 Helm values，再经灰度发布生效。 关键参数 HPA 目标指标建议使用自定义业务指标（QPS、队列深度），不要只盯 CPU。 HPA behavior 里设置 scaleDown 稳定窗口，防止“刚扩就缩”。 VPA 设置 minAllowed/maxAllowed，避免极端建议。 观测面板建议 当前副本数与目标副本数差值。 Pod 重建频率与重建原因。 requests 利用率分布（而非平均值）。 小结 HPA 与 VPA 本质上是两个控制器。让它们协同的关键，不是“都开”，而是“职责分离 + 变更节流 + 可观测闭环”。

背景 Rust 接入存量 C++ 代码是很多团队都会走的一步。 难点通常不在 extern "C"，而在这些边界问题： 谁创建谁释放 错误如何跨边界传递 线程模型是否一致 基本原则 FFI 边界尽量窄 数据结构扁平、可序列化 所有权规则在接口文档里写死 #[no_mangle] pub extern "C" fn sum(a: i32, b: i32) -> i32 { a + b } extern "C" int32_t sum(int32_t a, int32_t b); 总结 FFI 能带来渐进迁移收益，但边界规范必须比普通模块更严格。 跨语言最怕“默认约定”，最好全部显式化。 边界是系统最脆弱的地方，跨语言边界更是。

背景 前端和 BFF 的协作常见问题： 字段命名不统一 可空语义不一致 线上响应结构和文档不一致 契约化思路 以 schema 为单一事实来源 前后端共享类型生成 关键接口做契约测试 export interface UserProfileDTO { id: string name: string email?: string roles: string[] } export async function fetchUserProfile(id: string): Promise<UserProfileDTO> { return http.get(`/api/users/${id}`) } 总结 契约稳定之后，联调成本会明显下降。 接口变更可追踪，线上兼容风险也更低。 协作效率的上限，通常由契约清晰度决定。

为什么“打开 O3”还不够 大型 C++ 服务的热点跨模块分散，单文件优化难以奏效。LTO 能打通跨 TU 优化，PGO 能把优化预算聚焦在真实热路径。 推荐流程 基线版本：记录 p50/p99、CPU、指令数、缓存 miss。 LTO 版本：先验证链接时间与二进制体积变化。 PGO 训练：必须使用“接近线上”的请求分布。 组合验证：LTO + PGO 与基线做 A/B。 CMake 关键配置示例 # LTO set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON) # PGO 两阶段 # 1) -fprofile-generate # 2) -fprofile-use -fprofile-correction 最常见的误区 用单一压测脚本训练 PGO，导致优化偏科。 只看吞吐，不看长尾延迟和抖动。 忽略符号变化对排障工具链（perf、addr2line）的影响。 回归防线 增加“训练集漂移”检测：训练流量和线上流量偏差超阈值就拒绝发布。 将“优化收益”拆解到函数级，防止偶然抖动误判。 为 PGO 单独维护回退开关和构建产物。 小结 LTO/PGO 是生产力工具，不是玄学加速按钮。只有接入真实流量画像和回归防线，优化收益才可持续。

背景 在微服务里，重试是常态；没有幂等，重试就会制造脏数据。 常见重复来源： 客户端重复点击 网关超时后自动重试 消息队列重复投递 一种常见实现 以幂等 key 做唯一约束，先查后写或直接 UPSERT。 type IdempotencyRecord struct { Key string Status string ResultRef string } func (s *OrderService) CreateOrder(ctx context.Context, key string, req *CreateReq) (*Order, error) { if rec, ok := s.repo.FindByKey(ctx, key); ok { return s.repo.FindOrder(ctx, rec.ResultRef) } order, err := s.repo.CreateOrderWithKey(ctx, key, req) if err != nil { return nil, err } return order, nil } 总结 幂等设计本质是在失败重试下维持业务语义稳定。 关键是“唯一键 + 状态机 + 可重放结果”。 高可用系统默认会重试，幂等就是重试的安全带。

背景 同样是自动伸缩，HPA、VPA、KEDA 解决的问题并不一样。 选择思路 请求型 Web 服务：优先 HPA 资源画像长期不准：引入 VPA 做建议或自动调参 事件驱动消费：优先 KEDA 常见组合 HPA + Cluster Autoscaler：最常见 HPA + KEDA：API + 消费任务混合系统 VPA 先建议模式观察，再决定是否自动 总结 不要为“自动化程度更高”盲目上更多组件。 先把指标质量做好，再谈伸缩策略。 伸缩策略的上限，取决于指标体系的下限。

背景 不是所有性能优化都要上自研内存池。很多时候，std::pmr 已经能解决不少问题。 一个实用场景 请求处理阶段会构建很多临时字符串和容器，生命周期一致，适合放在同一块内存资源里。 #include <memory_resource> #include <string> #include <vector> void handleRequest() { std::byte buffer[4096]; std::pmr::monotonic_buffer_resource pool(buffer, sizeof(buffer)); std::pmr::vector<std::pmr::string> fields{&pool}; fields.emplace_back("user", &pool); fields.emplace_back("email", &pool); } 总结 pmr 的价值在于“低侵入地控制分配策略”。 在临时对象密集场景里，收益通常比预想更明显。 能用标准库解决的问题，优先别把复杂度推到自研。

背景 很多部署问题，其实在本地就埋下了： 本地依赖版本和线上不同 环境变量缺省值不一致 本地绕过了鉴权或网络策略 一个简单做法 用 Compose profile 区分场景，但保持核心依赖一致。 services: app: build: . env_file: .env depends_on: [db, redis] db: image: postgres:16 redis: image: redis:7 总结 环境一致性不是“完全一样”，而是“关键契约一致”。 只要契约一致，很多线上问题能在开发期提前暴露。 部署质量往往从本地开发流程就开始决定了。

先澄清核心矛盾 无锁链表里，线程 A 可能刚把节点从链表摘下，线程 B 还在读取它。此时直接 drop 会造成悬垂引用。 两类主流方案 Epoch Based Reclamation（EBR） 线程进入临界区时 pin 当前 epoch。 删除节点先放入 retired 列表。 只有当所有线程都跨过该 epoch，节点才可释放。 Hazard Pointer（HP） 读取前先声明“我正在看这个指针”。 回收线程扫描所有 hazard slot。 未被保护的 retired 节点才能释放。 EBR 的工程特性 吞吐通常更高，读路径开销小。 线程暂停会拖慢全局回收进度。 更适合短临界区、线程活跃的服务。 HP 的工程特性 回收更精细，不容易被慢线程拖住。 读路径需要发布 hazard，CPU 开销更高。 更适合线程生命周期不可控的系统。 Rust 落地建议 // 伪代码：删除节点不立即释放，而是 retire fn remove(node: Shared<Node>, guard: &Guard) { if cas_unlink(node, guard) { guard.defer_destroy(node); // 交给回收器延迟释放 } } 使用经过验证的库（如 crossbeam）而不是手搓回收器。 把“最大 retired 数量”做成指标，防止隐性内存膨胀。 压测时加入 SIGSTOP 慢线程场景，验证回收鲁棒性。 小结 锁不一定是瓶颈，错误回收一定是灾难。无锁结构上线前，先证明回收策略在“慢线程、抖动、长尾”下仍可控。

背景 很多 Go 服务都会做 worker pool，但只做“固定 worker 数量”还不够。 真正决定稳定性的，是池子打满后怎么办。 基础模型 type Job func(context.Context) error type Pool struct { jobs chan Job } func NewPool(workerN, queueN int) *Pool { p := &Pool{jobs: make(chan Job, queueN)} for i := 0; i < workerN; i++ { go func() { for job := range p.jobs { _ = job(context.Background()) } }() } return p } 关键点：拒绝策略 func (p *Pool) TrySubmit(job Job) error { select { case p.jobs <- job: return nil default: return errors.New("worker pool saturated") } } 当队列已满时，快速失败通常比无限排队更可控。 总结 worker pool 的目标不是“永不拒绝”，而是让系统在高峰时有可预测行为。 配合监控和限流，才能构成完整保护链路。 可用系统的关键是边界清晰，而不是无限扛压。