工程实践 PlanetScale Blog 2026/09/28
文章以 PlanetScale 的 Neki 分片方案为背景，讨论多租户场景下的热分片问题：按 tenant_id 均匀分布租户在业务增长后会失效，出现超大租户压垮单个分片、跨租户查询增多等情况，即租户均匀不等于数据均匀。作者引用 Slack 使用 Vitess 的真实案例，说明 messages 表从按 workspace 分片改为按 channel 分片后，把常用的单分片查询保持在一起、把跨分片查询限制在批量或管理路径，从而降低热点并获得 CPU 与存储余量。文中给出三级处置路径：纵向扩容、按 key range 隔离大租户，以及最终按访问模式和查询形状重新分片部分表，并说明 Neki 用声明式 data topology 与在线 Reshard 在不停机的情况下迁移数据。边界在于内容带有产品宣传色彩，缺少性能基准和失败案例，Postgres 与 MySQL 的表述也略有出入，读者需结合自身系统验证。
推荐收录：文章把热分片的成因与三类处置路径（扩容、按 key range 隔离大租户、按访问模式重分片）讲得具体，并给出 Slack/Vitess 的迁移决策依据与 key range 配置示例，可迁移到多租户 SaaS 的分片键复审。适合负责分库分表、租户隔离与在线扩容的工程师和架构师；但结论围绕厂商产品，缺少量化基准，引用前需自行压测验证。
工程实践 Salesforce Engineering 2026/09/24
文章以 Salesforce Cloud Atlas 身份数据存储为例，讨论 Tier-0 身份服务在流量突增和上游重试下如何演变为级联故障。团队原有每实例限流在自动扩缩容和多租户场景中暴露阈值失真、全局容量不可见和 noisy neighbor 问题。重构方案包含基于队列时延提前感知压力、优先削减低优先级请求的智能负载卸载，以及无中心协调器的全局配额管理，由各服务器共享客户用量并独立限流。文章据此总结保护服务而非单机、先观测后执行、优雅降级、简化配置、纵深防御和可逆发布等原则。局限是问答形式偏高层，缺少具体算法、参数、实验数据和故障演练细节，读者难以直接复现，但架构权衡和原则仍有迁移价值。
推荐收录。文章直接呈现 Tier-0 身份平台从每实例限流到智能负载卸载与无协调器全局配额的工程演进，并给出队列时延、优先降级、多租户公平和纵深防御等可迁移取舍。适合 SRE、分布式系统与高可用平台工程师阅读，用于设计限流、过载保护和级联故障防护。局限是未展开算法与实验数据，需结合团队实际验证。
工程实践 Meta Engineering 2026/09/21
Meta 开源了内部使用九年多的通用指派问题求解库 Rebalancer，并配套 OSDI'24 论文。文章把指派问题抽象为对象、箱子、约束与目标，核心设计是解耦问题描述与求解过程：先用维度、分区、作用域、利用率等建模原语刻画现实策略，再通过表达式 API 与高层 spec API 表达约束和目标，最终编译成表达式图 DAG。求解提供两条路径：最优解器把图翻译成 MIP，靠变量聚合、可互换性与对称性破缺压缩模型，最坏规模为 O(|objects|*|bins|)；局部搜索解器直接在图上游走，邻域最坏 O(|objects|+|bins|)，可并行、每秒数百万次评估并支持剪枝。文中给出生产数据（每日约 4000 万次求解、30 多种问题形式、P99 12 秒）以及调试用 Web UI Rebalancer Explorer，并以 Apache 2.0 开源。
推荐收录：文章提供了可复用的优化系统设计证据——描述与求解解耦的建模原语、表达式图，以及 MIP 与局部搜索两条路径的复杂度、规模上限和选型建议，还有每日 4000 万次求解、P99 12 秒等生产数据与 OSDI'24 论文支撑。适合从事资源调度、容量规划、负载均衡和组合优化落地的工程与算法读者，其中“先用最优解器原型、再迁移到局部搜索”的经验可直接迁移。
工程实践 Meta Engineering 2026/09/21
Meta 介绍规划中的跨洋海缆 Petal：连接法国与美国约 7000 公里，目标 2029 年投运，实现 1 Pbps 容量，成为首个皮比特级跨洋系统。其核心是采用 2-core fiber，在 24 光纤对中达到等效 48 对的空分复用容量，并通过超纯石英、折射率控制和反向传输来降低衰减与串扰。中继器使用 96 芯单体内放大和 FIFO 将双芯转换为单芯再恢复，结合泵浦共享把功耗控制在 18 kV 供电限制内。文章还梳理从 Marea、Amitié、Anjana 到 Petal 的容量演进及 NEC、住友电工、Orange 的分工。不足是公告性强，缺少独立测试、成本和长期运维数据。
推荐收录。文章虽带有 Meta 基础设施发布色彩，但给出了 Petal 的容量目标、2-core fiber 与 24 对光纤等效 48 对的 SDM 设计、FIFO 中继器、96 芯放大和 18 kV 供电边界等具体工程约束。适合网络基础设施、光通信与海缆系统读者参考，其容量扩展路径和功耗/工艺取舍可迁移到大规模互联系统评估。
工程实践 Elastic Security Labs 2026/09/18
文章介绍 Elastic Cloud Serverless 上用跨项目搜索（CPS）实现集中式 SOC 告警分诊。作者把 1 个源项目连接 100 个关联项目，在源项目运行约 2100 条预置检测规则，验证检测、分诊、调查与响应全流程。结论是该集中模型在规模下可行：规则和告警集中在源项目，数据仍留在各项目，分析人员用统一队列查看跨项目上下文。文章给出 ES|QL 查询模式、告警按项目汇总和列投影等性能建议，指出成本主要取决于单项目数据量与查询形态，而非关联项目数量。同时列出边界：响应动作、关联项目自生告警、Attack Discovery 等不跨项目聚合，需坚持“集中分诊、本地响应”。适用于多团队/区域/客户需数据隔离但共享检测分诊的组织。
推荐收录：文章基于 1 个源项目连接 100 个关联项目、运行约 2100 条检测规则的真实压测，给出 ES|QL 查询模式、性能取舍和 CPS 能力边界表，属于可迁移的集中式安全运营工程经验。适合安全平台、SOC、云原生安全架构读者评估多租户检测与分诊方案；主要风险是功能强绑定 Elastic Serverless，落地时需核对响应动作不能跨项目等限制。
工程实践 Oxide Public RFDs
本文是 Oxide Omicron 控制面数据库的设计 RFD，围绕强一致性与可扩展性，给出多租户 API 资源（Project、Instance、VPC 等）的建模与查询模式。作者采用 UUID 主键、身份元数据、按父作用域与 name 的唯一部分索引，支持分页、重命名和软删除，并避免显式外键。文章用条件 UPDATE、CTE、generation number 与 rcgen 处理并发更新和检查-使用竞态，也比较事务、CTE、saga 的适用场景。最后分析读-改-写、长事务、双管理员并发及集合删除/创建竞态，并指出实现尚不完整、方案依赖 CockroachDB SERIALIZABLE 与具体 API 约束。
推荐收录。文章不是泛泛介绍数据库范式，而是给出可核验的表结构、唯一部分索引、条件 UPDATE/CTE、rcgen 和 saga 选择规则，并明确 CockroachDB SERIALIZABLE、软删除与双管理员并发下的边界。适合控制面、分布式数据库和后端架构读者，其中的并发控制与一致性模式可迁移到多租户 API 设计；风险是方案与 Oxide/CockroachDB 强耦合且实现未完成。
工程实践 Oxide Public RFDs
该 RFD 界定 Oxide 控制平面持久化数据存储需求：需存储实例、虚拟磁盘、网络资源、服务器、用户/SSH 密钥等对象，支持持久 CRUD、分页一致性枚举和乐观并发控制，并讨论 ACID 是否必需。非功能要求包括强一致、有限故障下可读写、零计划停机、无人值守、可诊断、安全、开源与低成本，且把逻辑复制和在线 schema 迁移列为一等能力。文中估算单机架约万级实例、约 100 GiB 数据，外部 API 延迟需数百毫秒内、数据库访问约 150ms 内，短生命周期负载可达千级 rps；作者据此主张先评估现有系统，并给出从调研、Jepsen 失败分析到部署、故障与长时压测的漏斗式选型方法。候选聚焦 CockroachDB、Yugabyte、TiKV/TiDB、VoltDB 等 NewSQL，排除传统 RDBMS、NoSQL、FoundationDB 与 ZooKeeper/Etcd 类系统；但该文仍是早期需求框架，未给出最终基准和选型结果。
推荐收录。该文不是产品宣传，而是把控制平面数据存储的功能/非功能需求、规模与延迟估算、自研与采购取舍、候选 NewSQL 及排除项、以及分阶段评估方法写得很具体，对设计高可用控制平面、做分布式数据库选型或需要向团队说明存储约束的工程师有直接参考价值。局限是它属于早期 RFD，未给出实测基准和最终选型，读者应把它当作需求清单和评估框架而非结论。
工程实践 Oxide Public RFDs
RFD 70 提出多租户基础设施中容量、分配与利用率的管理框架，先区分 in-use、provisioned、reserved、capacity，并定义 utilization、threshold、overprovisioning、bursting。其核心原则是用透明、可操作的数据帮助用户和运维决策：展示容量仪表盘与按用户/团队/项目下钻视图，设置阈值告警，提供一键调整实例或磁盘、通知项目成员的流程，并用配额防止过度分配。文档明确反对超售，强调扩容与缩容并重、按实际使用率优化，并建议将利用率与成本节省纳入账单，甚至用排行榜激励良好使用习惯。它属于早期设计讨论稿，给出术语、原则、指标和交互场景，但缺少实现细节、规模化验证和预测模型的量化评估。适用于云平台、SRE 与基础设施容量治理场景。
推荐收录：它把容量治理从“看监控”推进到可操作流程，明确区分 in-use、provisioned、reserved、capacity，并给出仪表盘、阈值告警、配额、扩缩容和账单联动等机制。对云平台、SRE 和基础设施团队，反对超售、以利用率驱动资源调整的原则可直接迁移到多租户容量规划。风险是它仍是 RFD 设计稿，缺少落地数据与实现验证，部分激励机制需按组织裁剪。
技术文章 Kubernetes Blog 2026/09/10
Kubernetes v1.37 引入调度器抢占以支持就地 Pod 资源调整（Alpha）。此前运行中 Pod 申请扩容若超出节点余量，Kubelet 会将其标记为 Deferred 并无限等待；新特性让调度器跟踪此类 Pod，并在其所在节点上抢占低优先级 Pod 释放容量，使高优先级应用的扩容得以完成。抢占严格限于同一节点，扩容资源被视为已消费以避免重复分配，且决策统一交由调度器以遵循全局优先级、PDB 与优雅终止策略，并支持节点级关闭。文章含 kind 集群验证示例，但该特性仍为 Alpha，要求 v1.37+ 且全组件启用门控，若无合适抢占对象则扩容仍保持 Deferred。
推荐收录：文章来自 Kubernetes 官方博客，系统解释了 v1.37 就地 Pod 扩缩容的调度器抢占机制，包括 Deferred 状态处理、同节点抢占边界、资源预留和与 Kubelet 的职责分离，并给出可复现的 kind 验证步骤和节点级关闭配置。适合平台工程师、SRE 和集群运维人员评估在资源高利用率场景下如何安全使用就地扩缩容；其架构权衡与验证方法可迁移到其他调度策略设计。需注意该特性仍为 Alpha，且要求 v1.37+ 全组件启用门控，后续版本可能调整。
工程实践 Meta Engineering 2026/09/03
ZGateway 是 Meta 为 ZippyDB 键值存储新增的无状态代理层，目的是改变超百万客户端直接连数据库产生的稠密连接网格及其可靠性风险。它把客户端与后端收敛成两跳，使连接扇入扇出规模由代理层可控，并通过跨客户端批处理和合并降低 RPC 开销、缓解热键冲撞。代理层同时承载租户级准入控制、按 CPU 自适应的负载均衡、带实时失效的读缓存，以及可配置的跨区域容灾；迁移采用分服务、分前缀的百分比开关实现可逆灰度。文章给出的实测边界是：ZGateway 承载约 40% ZippyDB 流量、平均约 6% 计算开销，压测中丢弃只作用于少数噪声租户，其他租户成功率保持 99.9%。最后作者展望了多进程隔离、控制面外置与 AI 辅助调优等方向。
本文来自 Meta 生产环境的系统级工程复盘并包含明确数据和机制，不只是架构简介。它展示了一个代理层如何同时解决连接管理、高可用、租户隔离与流量治理，适合关注分布式系统、基础架构和可靠性设计的读者。文中的扇入扇出建模、灰度迁移和自适应负载均衡思路可以迁移到其他大规模代理或网关场景，但需注意 Meta 内部基础设施的耦合与规模化条件。
技术文章 Kubernetes Blog 2026/09/02
文章介绍 Kubernetes v1.37 中 HorizontalPodAutoscaler（HPA）支持将工作负载缩容到零副本的 Beta 特性。作者首先解释了为什么缩零必须使用 object 或 external metric，因为 CPU/内存这类资源指标来自运行中的 Pod，副本为零时无法提供扩容信号；而队列长度等外部指标可以在无 Pod 时继续读取。随后给出了基于 Prometheus external metric 的配置示例，包括 metrics adapter 规则、验证指标可用性的 kubectl 命令以及 HPA 清单。文章重点说明了 ScaledToZero 状态条件如何区分控制器自动缩零与运维人员手动暂停，并列出升级、回滚或禁用特性时的注意事项。最后讨论了冷启动延迟和适用场景：该特性最适合队列消费者、批处理等可容忍延迟的工作负载，而 HTTP 请求型负载需要额外的缓冲层。
本文是 Kubernetes 官方博客对 HPA 缩零 Beta 特性的权威说明，不仅包含配置示例，还深入解释了对象/外部指标的必要性、ScaledToZero 条件设计以及版本升级时的风险控制，信息密度高且可长期参考。适合平台工程师、SRE 和云原生应用开发者阅读，可直接指导基于队列的弹性伸缩部署。
工程实践 PlanetScale Blog 2026/09/01
文章深入解析了 PlanetScale 的 Neki 路由器在分片 PostgreSQL 数据库中的核心作用与实现机制。它指出分片数据库的难点在于决定查询应路由到哪些分片，Neki 为此引入了双层计划：先由路由器基于数据拓扑生成 Neki 计划，再将改写后的 SQL 交给各分片上的 PostgreSQL 生成传统执行计划。文章通过单点路由和 scatter-gather 两个具体示例，展示了路由器如何识别分片键、绑定参数、推送 limit、汇总多分片结果，并利用侧车进程通过 gRPC 转发工作。同时说明了路由器无状态、可独立扩展的特点，以及与 PgBouncer 等连接池工具的差异。文章还点明了 Neki 的两个缩放维度：分片扩展数据和 PostgreSQL 引擎，路由集群扩展分布式查询处理与连接管理。整体对理解分布式数据库查询路由与分片架构具有很好的参考价值。
推荐收录。文章不是抽象的理论介绍，而是直接展示 Neki 路由器的双层计划、分片路由和 scatter-gather 的具体实现，包含 EXPLAIN 输出和架构组件说明，证据具体。适合数据库内核工程师、分片库用户及分布式系统架构师阅读；其中关于无状态路由器、连接处理与查询处理分离的设计思路，可迁移到其他分布式数据库或网关类系统。
工程实践 ClickHouse Engineering 2026/08/27
本文是 ClickHouse 团队对 Mat Duggan、Charity Majors 提出的“ClickHouse 正在赢得可观测性战争”观点的回应与剖析，明确“胜利”仅限定在存储与查询层。文章解释列式架构为何契合可观测性数据：按列存储与排序键利于压缩编码，稀疏主索引与跳数索引减少 I/O，向量化执行、SIMD 与跨分片并行加速聚合，并缓解高基数问题。还讨论了全文检索倒排索引、单库承载日志/追踪/部分指标、SQL 表达力与 Apache 2.0 许可带来的采纳优势。作者也坦承边界：Prometheus 式指标的 PromQL 兼容仍是最大缺口，TimeSeries 引擎与 API 尚不稳定，数据库本身不等于好的可观测性产品，小团队或自建引擎的厂商未必适用，并指出 Agent 工作负载带来低延迟、高并发与全保真留存的新要求。
推荐收录。文章虽出自厂商博客，但系统梳理了列式存储契合可观测性数据的机制——压缩、索引裁剪、向量化、并行聚合与高基数处理，并较诚实地指出 PromQL 兼容、ordering key 与 schema 设计等边界，适合负责可观测性平台或日志/追踪存储选型的工程师参考。其架构权衡与“何时不适用”的判断有可迁移价值，但读者需注意其自证立场与客户证言带来的偏向。
工程实践 ClickHouse Engineering 2026/08/25
ClickHouse 团队复盘内部可观测性平台 LogHouse 的 OpenTelemetry 摄取管道三次演进。第一版 agent+gateway 架构在 5000 万 events/s 规模下无法承受 ClickHouse 反压而频繁 OOM；第二版启用 collector 本地 WAL，需改造成 StatefulSet，1TiB 积压约需 4 小时排空，且 FIFO 顺序阻塞最新数据，只能截断 WAL 丢数据。团队放弃引入 Kafka，改用基于 S3 的优先级故障转移：仅在 ClickHouse 反压时由 failover connector 溢出到对象存储，再通过 SQS 事件通知由独立 catchup collector 回灌，规避常态 PUT 成本。文中给出完整 collector 配置与一小时停机 gameday 验证结果，也指出恢复期无法定位具体缺失数据、新区域需额外基础设施等局限。
推荐收录：文章完整呈现从默认两层采集架构到自研 S3 溢出方案的取舍链条，给出 5000 万 events/s、1TiB 积压需 4 小时排空、每年 10-50 万美元 PUT 成本等具体数字，并用一小时停机 gameday 验证无数据丢失。对负责可观测性采集、高吞吐数据管道或 ClickHouse/OTel 落地的工程师，其 failover connector 的队列开关顺序、优先级路由和 catchup 回灌设计可直接迁移。
工程实践 PlanetScale Blog 2026/08/25
文章围绕 Postgres 大表引发的工程问题展开，先从真实案例说明级联删除导致 WAL 放大、网络饱和和副本延迟，最终演变为业务中断。随后系统剖析大表在 autovacuum 启动阈值过高与执行缓慢、空间回收失败与 bloat、长查询占用连接、备份与恢复变慢、索引膨胀以及宽行 TOAST 的 OID 限制等方面的详细机制。作者对比分区、垂直扩展和分片三种解决方案的适用边界，指出分区能细分堆并改善 vacuum，垂直扩展仅能临时缓解，而分片可将大数据表拆到独立集群，避免单集群的全局性限制。文章也提醒分区不能解决 xmin 的集群级快照钉扎，分片需要选好 shard key。适合需要设计高可扩展数据库架构的工程师参考，但结尾对自有产品 Neki 的推广属于商业内容。
本文不是泛泛的问题清单，而是通过真实故障案例和具体参数（如 autovacuum 阈值、32 位 XID、TOAST OID）揭示大表问题的本质，对分区、垂直扩展和分片做了清晰的权衡对比。适合数据库管理员、SRE 和高并发应用后端工程师，文中诊断大表问题的框架和解决方案取舍可以迁移到自有系统中。注意文章末尾有产品推广，但技术分析独立完整，是长期有效的参考资料。
工程实践 Meta Engineering 2026/08/24
Meta发布自研RDMA传输协议MetaRoCE，面向AI规模GPU集群，运行于普通以太网，并计划通过OCP开放规范、参考实现和一致性测试套件。其核心是将网络智能从交换机移向NIC，支持原生乱序投递、逐路径喷发、免PFC的丢失容忍传输，以及发送端AIMD与接收端速率提示的拥塞控制。在64节点AMD GPU集群测试中，相比RoCEv2，MetaRoCE在all-reduce和all-to-all上吞吐更高、流完成时间更低，1%丢包时保持约86%吞吐，多平面扩展近线性，平面故障可自动恢复。现有RDMA Verbs应用无需修改即可使用，文章也承认在机内、跨数据中心和存储/KV缓存等场景仍需后续优化。
推荐收录。文章来自Meta工程博客，详细阐述了MetaRoCE的动机、设计权衡和实测数据，包括与RoCEv2的对比、损失下的优雅降级和多平面弹性，证据链完整。适合网络协议开发者、AI基础设施架构师和分布式系统工程师参考，其端点智能、逐路径拥塞控制等思路可迁移到其他高性能网络设计。需要注意文章同时是产品发布稿，基准规模和场景有限，实际部署效果需独立验证。
技术文章 PlanetScale Blog 2026/08/24
文章回顾了Postgres分片技术二十年来的演进。作者先从“shard”一词在Ultima Online游戏中的起源讲起，说明MySQL因LAMP生态先行形成了Vitess等成熟方案，而Postgres则长期依赖各公司自建。随后梳理了Skype的PL/Proxy、Instagram的逻辑分片、Citus扩展、PgDog代理、Aurora以及Spanner/CockroachDB/Yugabyte等Postgres兼容分布式数据库，逐一分析其架构与取舍。核心观点是显式分片比自动分片更可预测，原生Postgres集群比兼容层更可控。文章最后介绍PlanetScale推出的Neki，宣称结合历史经验提供显式分片、水平扩展路由器并托管备份恢复，但该部分带有明确的产品推广色彩。整体适合作为了解Postgres分片方案演进的入门综述，但对Neki的介绍需要以批判视角审视。
推荐收录，因为文章系统梳理了Postgres分片从PL/Proxy到Citus再到Spanner兼容方案的完整脉络，并给出了每个方案在运维复杂度、路由瓶颈、跨分片查询上的具体取舍，能帮助数据库团队在做分片决策时建立历史坐标系。适合数据库工程师、架构师阅读。需注意文章后半部分是PlanetScale自家产品Neki的推广，作为技术评述存在立场偏差，读者应区分事实与产品主张。
工程实践 vLLM Blog 2026/08/17
本文介绍 vLLM-Omni 的分布式逐层卸载（DLO），用于在多 NPU/GPU 上运行超出单卡 HBM 的 DiT 模型（如 64B/124GB Cosmos3-Super）。方案结合 meta device+mmap 加载、权重分片+AllGather 重建、双缓冲预取与计算重叠、DP 多并发。实测 Ascend 910B3 上冷启动 cgroup 峰值由 178GB 降至 47GB，主机内存从 O(dp×model) 降为 O(model+dp×常数)，4 并发吞吐达 HSDP 单请求的 3.3 倍；B300 上 DLO+AG DP4 吞吐为 HSDP+USP4 的 1.39 倍且 HBM 仅 30%。MiniMax-H3 表明 DLO 模式依赖拓扑：DP1×SP8 宜用 AllGather，DP8×SP1 宜用 rank-local。但 400GB 外推未实测，最大块尺寸、带宽与输出质量在该规模仍未验证。
推荐收录：文章给出可复现的系统级设计，四项技术分别对应明确的内存/吞吐瓶颈，并附 Ascend 与 B300 实测数据及失败边界。对从事大模型推理基础设施、显存受限模型部署和分布式并发的工程师有直接迁移价值；需注意 400GB 外推未实测，拓扑结论限于单节点单输入集，不能直接当作通用生产结论。
工程实践 LinkedIn Engineering - Architecture
文章复盘LinkedIn消息系统从邮件式单体架构到全新架构的设计阶段。旧系统最初使用单一Oracle数据库和分片复制，消息量五年增长四倍后，产品向聊天体验演进但代码复杂度剧增，导致开发效率下降。作者提出产品与工程需求，特别强调迁移自定义业务逻辑需要近60个转换器，并决定将数据持久化拆分到多个服务以独立扩展，同时接受分布式事务代价。团队通过高层架构文档、设定设计原则和赋权技术负责人并行推进，制定正确性优先、构建正确、再求快等原则。文章还总结了迁移策略、异步处理、团队结构和项目组织方面的经验教训，但未深入具体实现细节。
推荐收录：这是LinkedIn真实消息系统重构的工程案例，包含从单体到分片再到新架构的演进、明确需求和设计原则，以及迁移与团队组织的教训。适合架构师、后端工程师和技术负责人参考大型系统重新设计、跨团队协作和数据迁移的可迁移方法。
工程实践 LinkedIn Engineering - Architecture
本文介绍 LinkedIn 将身份服务中的 midtier 和 data service 两层合并为一个服务的实践。原架构中 data service 仅提供数据验证和 Espresso 存储访问，业务逻辑薄弱但维护成本高，且增加网络跳数。团队在保持对外 API 不变的前提下，先将 data service 的 REST API 作为本地库嵌入 midtier，随后通过 T-REX 框架逐步灰度、下线旧服务并清理技术债。性能测试使用 Dark Canary 复制生产流量对比，结果显示 p50、p90、p99 延迟分别降低 14%、6.9%、9.6%，内存分配率下降 28.6%。最终下线整个 data service 集群，节省超过 12000 核和 13000GB 内存。文章强调这是针对特定场景的权衡，并非所有微服务都应合并。
推荐收录，因为文章提供了完整的工程案例：从问题动机、架构决策、灰度实施到性能验证，数据详实。直接证据包括 p50/p90/p99 延迟改善、内存分配下降和资源节省。适合关注微服务粒度、性能优化和成本控制的架构师与后端工程师。可迁移价值在于展示了当数据服务逻辑薄弱时合并服务的考量方法，以及利用灰度发布和流量镜像降低高风险变更的实践。
工程实践 LinkedIn Engineering - Scalability
文章介绍 LinkedIn 为替代 Kafka 而自研的可扩展日志存储系统 Northguard，以及其上的虚拟化发布订阅层 Xinfra。Northguard 通过分段、范围、主题的数据模型，基于 Raft 的动态分片元数据状态机（DS-RSM）和 SWIM 去中心化成员协议实现高可扩展性与可运维性。核心设计是以段为复制单元的日志条带化，自然均衡负载、避免资源倾斜，并论证范围模型相比固定分区能减少流处理中的 shuffle。评测对比显示 Northguard 在元数据可扩展性、集群数量、负载均衡、自愈、一致性和持久性上均优于 Kafka，且通过 Xinfra 虚拟化和双写实现了透明迁移。文章主要面向大规模日志存储和分布式系统工程，技术细节以高层设计为主，缺少底层实现参数和故障恢复的深入展开。
本文来自 LinkedIn 真实生产环境，规模达 32T 记录/天、17PB/天，详细展示了从 Kafka 迁移到自研系统的完整工程决策与权衡，包括数据模型、复制单元选择、元数据分片和虚拟化迁移。适合分布式存储、基础设施和架构师参考，尤其关注日志存储、自动负载均衡和大规模系统演进。其可迁移价值在于以细粒度分段替代整日志复制来改善可运维性和可用性的思路，但读者需注意文章未公开具体实现代码和完整故障处理细节。
工程实践 LinkedIn Engineering - Architecture
文章介绍了 LinkedIn 开源的新组件 iris-message-processor，用于替换原有 Iris 事件管理系统中单 leader 的 Python 子进程 iris-sender。旧架构串行处理消息、依赖 Galera 强一致数据库作为消息队列，在高负载下出现延迟激增和复制死锁。新服务用 Go 编写，采用分布式 bucket 动态分配，节点可水平扩展，数据库不再充当队列。压测显示高负载下性能提升约 86 倍，6000 条突发消息处理时间从近 30 分钟降至 10 秒内，节点失效后 30 秒内自动重平衡。该组件已生产运行一年无中断，并与现有 Iris-api 保持兼容，支持渐进式切换。
推荐收录，因为文章提供了从单点瓶颈到分布式架构的完整演进案例，包含明确的问题定位、设计取舍、压测数据和生产验证。对负责高吞吐消息处理、事件驱动系统或 on-call 基础设施的工程师有直接参考价值，特别是水平扩展、去数据库队列和渐进式上线策略可迁移到类似场景。
工程实践 LinkedIn Engineering - Scalability
文章复盘了LinkedIn My Network页面加载缓慢和内容跳动的问题，旧架构中移动端与Web端并行请求多个API，独立渲染不同推荐区块，导致首屏等待近两秒并出现UI闪烁。作者团队将多端点统一为单一API并引入分页，把无限滚动的PYMK拆成多个小cohort，预构建后放入缓存，后续按页获取；同时采用渲染模型，由API定义通用banner和内容容器，减少客户端业务逻辑。优化后P90延迟下降43%，成本节省七位数，Web端LCP和FID显著改善，会员参与度提升。文章未深入讨论缓存一致性、失败处理和更复杂个性化场景，但提供了可工程迁移的架构权衡。
推荐收录，因为文章给出了完整的性能优化工程案例：从多端点并行到统一API、分页和预构建缓存，再通过渲染模型简化客户端，并用量化指标验证收益。适合后端、前端及系统设计工程师参考，其中缓存设计、API收敛和渲染模型解耦的思路可直接迁移到类似推荐流或内容聚合页面的优化中。
工程实践 LinkedIn Engineering - Scalability
文章介绍了 LinkedIn 用 Rust 构建的通用检索引擎 FishDB，替换了运行近十年的 Java 系统 FollowFeed。文章首先分析了旧系统的局限：Java 对象内存开销大、GC 导致高尾延迟、数据模型僵化且业务逻辑耦合，限制了推荐系统的扩展和迭代。随后解释了选择 Rust 的原因，并通过对比实验展示 Rust 在内存效率上的显著优势。FishDB 采用 scatter-gather 架构和 lambda 架构，提供了灵活的命令式查询语言和多种索引结构，包括倒排索引、前向索引、引用索引和基于 RocksDB 的属性存储，以支持图状数据模型和高效过滤排序。迁移采用分层渐进方式，通过 JNI 桥接保持 API 不变，实现了零中断切换，最终取得 2 倍效率、减少 50% 硬件、p99 延迟 40ms 的成果，并将实验周期从数周缩短到数天。文章也指出当前查询语言仍为命令式，未来计划引入声明式语言和向量搜索。
本文是一份高度完整的工程案例，从问题诊断、技术选型、系统架构、索引设计到灰度迁移提供了详实细节和量化结果，展示了如何用内存安全的高性能语言重构大规模检索基础设施。适合负责推荐系统、搜索引擎、分布式存储或性能优化的工程师阅读，可迁移的经验包括内存数据结构设计、Rust 在服务端的应用模式、分层迁移策略以及如何平衡灵活性与性能。
工程实践 LinkedIn Engineering - Scalability
本文复盘了LinkedIn职位摄取系统的设计，该系统每日处理数百万职位、超20TB原始数据。文章先梳理异构源、传输协议、安全、数据新鲜度等挑战，再介绍模块化事件驱动流水线和Job Intake、Job Processing Pipeline两大阶段。重点阐述Job Pull的orchestrator与专用Mining Node分离、抽取逻辑配置化、AI辅助Sitemap创建，以及基于START/JOB/END状态机的Mining Task和优先级队列。处理层通过静态/动态Job Field Processor和pre/mid/post三层实现清洗、增强与校验，并通过multiplexing生成衍生职位。文章以配置驱动扩展、上游背压和让用户掌控平台为关键经验，但偏高层架构，未深入具体实现与性能数据。
收录的直接证据在于文章展示了从异构数据摄取到标准化处理再到发布的全链路架构，包括orchestrator/worker分离、配置驱动抽取、优先级队列和动态处理器等可迁移设计。适合分布式系统、数据平台或集成工程师借鉴，尤其对需要快速接入多源数据、控制上游负载和将定制能力下放给非工程团队的系统有启发。风险是偏高层描述，缺少细粒度实现和量化验证，但整体技术深度满足长期参考要求。
工程实践 LinkedIn Engineering - Scalability
本文介绍 LinkedIn 基于 cert-manager 构建的 Kubernetes 工作负载身份安全框架。系统通过 CSI 驱动将证书以只读卷挂载到容器，私钥仅存内存，并利用 Identity Registry 进行身份证明和签发，防止身份冒用。针对多集群和 25 万 Pod 规模，团队发现开源 approver-policy 无法满足 5 万并发 CertificateRequest 的 SLO（P95 60 秒），遂自研 lipki-controller 作为审批和签发器，并通过 API QPS/并发调优、分区 sharding 实现水平扩展。文章还介绍了 Kyverno 策略限制签发源、渐进式迁移和 Java/Go/Rust 认证库集成。测试显示 54K 请求审批与签发 P90 为 19.3 秒，但水平扩展目前仅用于容灾，尚未实现动态扩缩。
推荐收录。文章不是简单的工具介绍，而是完整展示了 LinkedIn 在超大规模 Kubernetes 集群中落地 cert-manager 的真实工程路径：从身份注册、CSI 挂载、Kyverno 策略到自研 lipki-controller，并给出 54K CertificateRequest 下 P90 19.3 秒的实测数据。适合负责容器平台安全、PKI/证书生命周期、服务网格 mTLS 或大规模 Kubernetes 运维的工程师借鉴，其控制器调优、分区 sharding 和渐进式迁移策略具有可迁移价值；主要边界是 LinkedIn 内部系统和规模假设，且水平扩展暂仅用于容灾。
工程实践 LinkedIn Engineering - Scalability
文章介绍了LinkedIn Hiring Assistant中基于语义搜索的AI代理检索与排序系统MUSE。面对自然语言招聘查询与十亿级会员画像的匹配问题，团队构建了LLM-as-a-judge驱动的教师模型，生成海量资格匹配标签，训练双塔Transformer嵌入模型，并采用Matryoshka嵌入同时服务检索与排序。生产系统采用Lambda架构，结合批量重建与CDC增量推理，通过IVFPQ索引和优化管道实现亚秒级检索。离线回放与在线A/B测试表明，MUSE提升了候选相关性和招聘者参与度，但近似检索与后过滤的损失叠加仍是后续优化方向。
本文详细披露了LinkedIn大规模语义搜索系统的设计与实现，覆盖教师监督、双塔嵌入、十亿级向量检索和在线评估等关键环节，技术细节丰富且可验证。适合搜索推荐、AI基础设施和MLOps方向的工程师参考，其Matryoshka嵌入分层服务、CDC增量更新和IVFPQ优化等实践可直接迁移到类似规模系统。
工程实践 LinkedIn Engineering - Scalability
文章介绍了LinkedIn在管理约5EB数据和100亿对象的HDFS集群时，如何通过重新设计块放置策略来加速维护操作。默认BPP在维护时会导致大量数据复制和网络拥塞，而采用升级域BPP并定义20个升级域，将同一机架节点归入同一升级域，可以消除维护时的数据复制需求。文章详细描述了对3+EB存量数据进行分批再分布的过程，以及发现开源升级域BPP的写性能问题并开发新BPP排除已选升级域节点的改进。最终实现了每天升级约4.5%节点，显著提升了可靠性和安全性。
推荐收录，因为文章提供了真实超大规模HDFS集群维护中的完整工程案例，包含问题定义、架构取舍、数据迁移方案和性能优化细节，证据充分。适合负责分布式存储、大规模基础设施或HDFS运维的读者参考，其中升级域划分、利用维护模式减少复制和分批迁移的策略可直接迁移到类似系统。
工程实践 SelectDB 技术分享
文章讨论云数仓资源管理中长期存在的矛盾：业务负载波动大，固定规格资源常按峰值锁定，导致平均利用率低；传统存算分离架构弹性慢，扩容伴随缓存预热和数据重分布，容易引发查询延迟抖动。作者提出 SelectDB Serverless 的解决方案，通过计算、缓存、存储三层独立解耦，支持秒级原地纵向伸缩，单集群最高16倍弹性区间，并采用“扩快缩慢”策略——CPU 5秒均值或内存瞬时利用率超过60%触发扩容，CPU与内存同时低于30%且持续1分钟才渐进缩容，同时引入AI辅助决策。文章还给出选型参考：峰谷特征明显、可释放计算资源超过28%时Serverless才具成本优势；纵向弹性有16倍边界，极端场景需横向伸缩约3分钟。内容主要基于产品设计与机制说明，缺少独立用户验证数据。
推荐收录，因为它不只是产品宣传，而是提供了具体的弹性架构设计：三层资源解耦、扩缩容触发阈值、原地纵向伸缩机制和选型成本阈值，对云数仓、Serverless 或弹性架构设计的读者有直接参考价值。可迁移的是“扩快缩慢”的弹性策略和计算/缓存/存储解耦思路；需注意其厂商视角，部分性能数据未经独立验证。
工程实践 TiDB 社区博客 - 实践案例 2026/08/13
文章复盘学科网阅卷系统从 MySQL 迁移到 TiDB 的实践，背景是业务具有峰谷特征、单机 MySQL 主备集群出现容量与性能瓶颈，同时研发资源有限无法改造代码。作者详细说明选型 TiDB 的关键理由：高度兼容 MySQL 实现零代码迁移、在线 DDL 不阻塞业务、弹性扩缩容适配流量波动、Raft 多副本保证数据强一致。迁移采用分批策略，优先将大表和主从延迟严重的表迁入，收益包括缓解并发压力、消除切换数据不一致风险、节省磁盘空间并避免分库分表改造。文中还总结了扩容规划、小表热点处理、低峰版本升级和索引优化等运维经验。该方案尤其适合教育行业等需要兼容 MySQL 且短时高并发的场景，但需注意跨 AZ 缩容的数据分布和热点小表的处理。
推荐收录，因为文章提供了真实业务约束下的数据库选型、迁移和运维全过程，包含零代码改造、在线 DDL、强一致、扩容规划、小表热点等具体细节，不是泛泛的技术宣传。适合数据库架构师、SRE 以及教育行业技术负责人参考，其“先兼容迁移、争取时间”的平滑演进思路可迁移到其他受限于 MySQL 单机瓶颈且短期无法大改代码的团队。
工程实践 Netflix TechBlog 2026/08/07
本文详细介绍了Netflix实时分布式图（RDG）的查询服务层设计，阐述如何在高吞吐、低延迟要求下高效查询包含数十亿节点和边的图。文章首先分析了浅宽与深窄两类查询场景的挑战，随后说明广度优先遍历、异步优先架构、选择性缓存等关键设计决策及其取舍。接着以具体查询为例，逐步展示请求解析、存储读取、层次化遍历、并行执行、智能过滤和缓存等环节的实现与优化。最后给出系统性能指标（P50/P99延迟、缓存命中率）和经验总结，强调前沿思维、尽早过滤、有界并行和缓存策略等通用原则。其方法适用于高并发、IO密集型的分布式图查询系统，但一致性模型为最终一致，且依赖特定内部存储。
本文是Netflix技术博客的深度工程案例，展示了在真实约束下构建高性能图查询层的完整思考过程，包含具体的设计权衡、量化效果和可迁移原则。适合分布式系统工程师、架构师以及需要处理图数据查询的开发者参考。文中的广度优先遍历策略、异步执行模型和智能缓存方法可直接应用于类似的大规模在线服务场景，有效降低延迟和资源消耗。
工程实践 知乎 - 携程技术 2026/08/07
文章系统回顾了携程从Kubefed到Karmada的多集群治理演进，重点围绕架构选择、生产落地和规模化优化展开。核心方法是在联邦层保留低频全局能力（资源分发、策略表达、跨集群迁移），将高频局部能力（实时扩缩容、流量切换）留在成员集群，并通过权重驱动的状态机实现数十万Pod的平滑跨集群迁移。文中详细分析了Karmada控制面在几十万级资源规模下遇到的高频状态同步、启动延迟和200G内存尖峰等问题，以及通过折叠Work、降低更新频率、分批对账、watch list等优化手段。适用边界是交易型业务的Kubernetes多集群场景，强调联邦控制面不应成为运行时强依赖。
本文是来自携程生产一线的深度工程案例，不仅解释了为什么从Kubefed切换到Karmada，更给出了清晰的架构原则、迁移机制和规模化治理细节。文中200G内存尖峰、每秒数百次Work更新导致409冲突等具体数据有很强说服力，优化思路可直接指导类似场景。适合云原生平台团队、SRE和架构师参考，可迁移的职责边界划分和控制面优化方法在多集群治理领域有长期参考价值。
工程实践 PlanetScale Blog 2026/08/07
文章复盘了一次 MySQL 生产事故：一个长事务导致 InnoDB 版本历史膨胀，使读查询成本随并发量平方级增长，最终拖垮数据库。作者运用 Gunther 通用可伸缩性定律解析了争用系数 α 与一致性开销系数 β，阐明为何超过临界并发数后吞吐量反而下降。解决方案是将 Vitess 事务池从一万降低到约一千并引入排队，模拟原有线程池的反压行为，从而避免大量并发请求涌入存储引擎。配置变更后，系统在类似流量尖峰下吞吐稳定、无报错，MySQL 内部并发数控制在两百以内。文章强调此策略适用于悲观锁、热点行等高争用场景，且思路可迁移至 Postgres 等系统。
推荐收录，因为文章通过真实事故展示了并发与吞吐的逆向关系，并用通用可伸缩性定律提供量化分析。对负责高并发数据库、稳定性工程及反压机制设计的读者具有直接参考价值，可迁移到类似数据库和分布式系统中。文中提供的实验数据和配置对比使其结论可信，且明确给出了适用边界。
工程实践 Meta Engineering 2026/08/05
本文介绍了 Meta 广告排序系统在大规模序列学习上的两项架构创新：多阶段序列模型将计算密集的离线用户建模与对延迟敏感的在线排序解耦，通过异步处理长用户历史并缓存嵌入，在不线性增加服务资源的前提下提升模型容量；密集 tokenization 和目标感知多头注意力让模型直接从数据中学习稀疏特征与行为序列的交互，取代手动特征工程。该设计带来了可预测的 LLM 式扩展规律，即性能随计算量呈对数线性增长，并总结出模型形状平衡、多阶段可调性、序列组成多样性和语义特征表征四个扩展杠杆。文章给出了在 Instagram 和 Facebook 上的转化率与点击率提升数据，并指出该架构已作为 GEM 模型的核心组件，可泛化至各类广告排序任务。
推荐收录，因为文章不仅公开了关键技术细节（离线/在线解耦、密集 tokenization、目标感知注意力），还系统论证了在广告推荐领域建立起可预测扩展规律的方法与实验证据。对于推荐系统、广告架构及大规模模型服务的工程师和研究者，文中分离建模阶段以平衡复杂度与延迟的思路具有很强的可迁移性，而扩展规律的识别路径可为探索其他大规模机器学习系统提供参考。
工程实践 Salesforce Engineering 2026/08/05
Salesforce内部可观测平台Argus需处理每分钟40亿指标，原单区域架构导致全局可用性风险及高昂的数据传输成本。团队采用地理本地化策略，将指标就近处理和存储，避免全量复制，并通过联盟查询层与Elasticsearch元数据映射实现智能路由，仅查询数据所在区域，减少跨区域开销。同时引入HTTP 206部分响应和UI提示来处理部分地域不可用，保障用户体验。文章还介绍了通配符查询的元数据缓存优化，以及持续容量规划和架构审查来维持隔离边界。该方案已在五个生产区域中的四个上线，显著降低爆炸半径，但跨区域延迟和流量成本仍为后续关注点。
这篇工程案例详实记录了如何将单区域可观测平台迁移到多地理架构，解决全局不可用风险并控制成本，包含查询联邦、部分失败处理和元数据缓存等关键设计，为构建高可靠、大规模可观测系统的团队提供了可复用的架构思路和实践参考。
工程实践 ClickHouse Engineering 2026/08/04
文章复盘 ClickHouse Cloud 如何把自动扩缩容推荐服务从固定定时轮询改造成秒级反应式架构。原实现按固定节奏扫描全部服务，导致周期之间发生 OOM 或负载突增时必须等到下一次 tick 才能扩容，问题本质是延迟而非推荐逻辑错误。作者复用 Kubernetes 生态的 controller-runtime 作为通用事件处理引擎，把周期性扫描与反应式快路径都抽象为 source，统一投递到带键去重、指数退避和并发上限的工作队列，由同一个幂等 reconcile 函数产出推荐，因此无需自研触发协调机制。反应式信号以事件行写入 ClickHouse 专用小表，由物化视图在写入时过滤越阈指标，source 每几秒执行一次五分钟窗口查询，使关键事件在数秒内触发扩容；周期性全量扫描仍保留作为安全网与缩容兜底。文章也明确边界：工作队列仅存在于单进程内存，无持久化与重放，它是电平触发的 reconcile 引擎而非流处理器，不支持事件时间窗口、join 或跨事件聚合，轮询间隔构成反应速度下限；若未来需要保证投递、严格顺序或状态化窗口关联，应迁移到流式平台。
推荐收录：文章给出完整的问题定义、架构改造路径和可复现的 Go 与 SQL 片段，把“用 controller-runtime 当通用事件引擎、用 ClickHouse 存反应式信号”这一非显然选择连同去重、退避、并发控制的收益讲清楚。对做自动扩缩容、Kubernetes 控制器或实时信号管道的工程师有直接迁移价值；同时明确标注内存队列无持久化、轮询间隔是延迟下限等约束，避免读者误用。
工程实践 Meta Engineering 2026/08/03
本文介绍了Meta如何将广告推荐基础模型GEM的训练规模提升至LLM级别，并在12个月内将端到端训练效率提升一倍至20-25%模型算力利用率（MFU），同时训练算力规模扩大4倍。文章从计算效率和扩展效率两个维度分别展开：计算效率通过定制化推荐内核库（Jagged Flash Attention、Generalized Dot-Product Attention、BlockAttention）和混合超低精度训练（MXFP8注意力与MLP）实现；扩展效率则依靠拓扑感知的5D并行策略（2D FSDP加专家并行处理稠密参数，全分片2D模型并行处理稀疏参数）配合SM-free通信、自动激活检查点及序列长度感知负载均衡。所提方案针对推荐系统特有的变长序列、非对称交互和数值敏感性等挑战进行了专门设计，其方法论和具体技术对大规模推荐模型训练具有参考价值，但部分优化（如内核定制）与特定GPU架构强相关，迁移时需适配自身硬件和数据特性。
本文是真实的工业级工程案例，完整展示了在数千GPU上训练万亿参数推荐模型的全栈优化过程，涵盖内核、精度、并行、网络和内存的协同设计，而非孤立技巧罗列。适合负责大规模深度学习训练、推荐系统基础设施或GPU性能优化的工程师，可迁移价值在于其将MFU分解为计算效率和扩展效率的分析框架，以及针对混合架构和变长数据的特定解决方案，对类似规模系统的构建与调优具有直接借鉴意义。
技术文章 Cloudflare Blog 2026/08/03
文章介绍了 Cloudflare 推出的 @cloudflare/computer 早期预览版，这是一个面向 AI 代理的运行时库，其核心是基于 SQLite 的持久化共享文件系统，并支持在 isolate 和容器等多种执行后端之间按需切换。作者阐述了传统容器化在代理规模化时面临的扩展性瓶颈，并对比了 isolate 在启动速度、水平扩展和成本上的优势，提出了以 isolate 为主、容器仅用于必要任务的混合架构。文中给出了从 npm 安装到配置 workspace、绑定工具集和集成 agent 循环的代码示例，并解释了 FUSE 挂载、动态 worker 命令转译等实现机制。其目标是让代理 90% 以上的工作负载在 isolate 中完成，从而大幅降低对容器平台的需求，但目前仍处于实验阶段。
推荐收录，因为文章不仅停留在产品发布，而是深入讨论了 isolate 与容器作为代理计算基元的架构取舍，并给出了可落地的设计思路和代码示例。对正在构建大规模代理系统、关注基础设施效率和成本控制的后端工程师或平台工程师而言，文中关于水平扩展、文件系统抽象和执行后端分离的经验可迁移至类似场景。
科研议题 ACM Queue Articles 2026/07/22
本文提出基于通用可扩展性定律（USL）的大语言模型（LLM）计算动力学模型，用以解释OpenAI在训练LLM时观察到的计算高效前沿（CEF）。USL在标记化的神经网络景观中定义了双稳态极小值，其中更深的极小值决定了LLM实例可达到的最低损失。作者指出，规模更大的LLM具备与CEF幂律斜率对齐的更深的全局最小值，这表明CEF是更大规模模型捕获跨语料相关性的自然结果。文章为LLM可扩展性提供了理论框架，但模型依赖于对神经网络景观和标记化的假设，可能未涵盖所有实证因素。
该文章从通用可扩展性定律出发，为LLM训练中的计算高效前沿提供了新颖的理论解释，对理解缩放法则具有长期参考价值。适合关注LLM可扩展性、深度学习理论和性能建模的研究者与工程师阅读。其跨领域迁移价值在于将经典可扩展性理论与现代AI模型相结合，但需注意模型的理论假设可能与实际训练细节存在差距。
工程实践 Spotify Engineering 2026/07/20
本文是 Spotify 工程团队对 2026 年 6 月 24 日播客视频发布延迟事故的完整复盘。事故由四个因素叠加造成：视频转码基础设施余量不足、定时批处理任务争用容量、为提升画质降低码率而抬高的单项处理成本，以及硬件迁移后调度 bug 导致约 10% 算力未被利用，最终形成数小时的发布积压并引发创作者重复上传。文章给出精确到分钟的 UTC 时间线，指出从首批告警到正式响应延误约四小时，并列出已采取的处置动作（停止批处理、修复调度 bug、扩容、次日凌晨清空队列）与整改计划（容量提升约 67%、改进监控、优先级调度、限流与背压、创作者通知）。局限在于仅覆盖单一公司管线，未披露具体架构细节与量化验证结果。
推荐收录：这是一份结构完整、证据具体的事故复盘，明确列出四个叠加根因、分钟级时间线与处置及整改动作，展示了容量规划、队列优先级和背压设计的真实取舍。适合负责媒体处理、数据管线或高可用服务的工程师参考，其中告警与响应脱节、批处理与实时流量争抢资源的教训可直接迁移。
工程实践 Dropbox Tech 2026/07/20
文章回顾了 Dropbox 内部内容处理平台 Riviera 近十年的演进历程。平台最初为解决多文件格式预览需求而设计，关键思路是将每项任务拆解为可复用的转换片段（如 PowerPoint→PDF→图像），从而避免为每个产品单独构建管道。架构上采用中心调度器与插件化后端 worker 分离的模式，中心负责请求验证、缓存与编排，worker 按转换类型独立扩展，现已支持 300+ 文件格式与 100 多种转换能力，每秒处理数十万请求。随着产品线扩展，Riviera 被搜索、视频审阅、电子签名及 AI 产品 Dash 等团队复用，为 AI 模型统一提供文档提取与格式转换。文章最后说明了平台向外部开发者开放 API 和 MCP 工具的策略，体现了“一次构建、多方受益”的平台工程价值。文章侧重于架构决策与规模效益，未深入具体实现细节或失败案例。
推荐收录。文章提供了真实的大型内容处理平台从单点服务到多产品基座的演进案例，清晰展示了复用、分离关注点和插件化架构如何支撑规模增长与业务扩展。适合平台工程、基础设施设计以及需为 AI 准备非结构化数据的工程师参考，其架构思维和平台化策略具有直接迁移价值。不足之处在于缺少性能瓶颈、失败处理或维护成本的讨论，但整体工程经验仍具有长期参考意义。
工程实践 Marc Brooker 2026/07/19
Marc Brooker在这篇博客中介绍了Aurora DSQL论文，重点阐述了系统的整体目标：构建一个简化应用构建与运维、无需关心规模与可靠性的关系型数据库。文中强调了架构解耦的设计思想，将查询处理、事务、复制和控制面拆分为独立服务，并总结了来自Aurora与DynamoDB等系统的运营教训，如避免大缓存、提供强一致可扩展读、将昂贵操作下推到存储层。作者还讨论了乐观并发控制（OCC）在避免客户端阻塞和减少尾延迟方面的优势，以及多区域场景下的快速读写能力。博客最后指出，硬件与数据中心设计的进步使得强一致性成为更优选择，并提供了论文链接供进一步阅读。
作为Aurora DSQL系统的核心设计者之一，作者以第一视角提炼了论文的关键设计决策与运营经验，浓缩了现代分布式OLTP数据库的核心理念。文章对解耦架构、一致性选择、多区域扩展等问题的论述既权威又简明，适合分布式系统工程师、架构师及关注数据库技术演进的研究者快速获取全局认知，其总结的教训可迁移至其他大规模系统设计。
工程实践 Meta Engineering 2026/07/15
本文介绍了 Meta 广告漏斗深度优化中的层级兴趣表征系统，旨在通过统一嵌入连接用户、广告主与产品。系统基于大规模异构交互图，融合多模态世界知识（由 LLM 处理）以缓解稀疏信号问题，并采用 Transformer 架构实施层级编码：引入图结构偏差的注意力机制（使用 FlexAttention 实现内存高效计算）、自监督跨视图蒸馏（结合 Sinkhorn-Knopp 均衡）与交互预测联合训练。最终输出通用嵌入和“意义包”离散令牌，可服务于检索、排序等下游任务。文章详细阐述了图构建、在线基础设施、因果性保证与规模化训练流水线，提供了工业级推荐系统在复杂图学习上的工程实践，但方法高度依赖 Meta 内部平台与数据规模，迁移时需考虑领域适配。
推荐收录。本文来自 Meta 工程博客，系统披露了用于大规模广告推荐的上游层级兴趣表征系统，完整覆盖从图构建、多模态知识融合、Transformer 层级编码到在线推理的工程细节，并公开了 FlexAttention、跨视图蒸馏等具体设计决策与缩放经验。适合推荐系统、图学习及大规模 ML 基础设施方向的研究者和工程师参考，可迁移至处理稀疏信号、层级表征与工业级图应用的场景。需注意部分架构深度绑定 Meta 生态，但核心思想与权衡思路具备通用价值。
技术文章 PlanetScale Blog 2026/07/15
文章从数据库扩展瓶颈出发，解释了单节点和只读副本在写入吞吐、数据容量和备份速度上的局限，进而说明为何分片是超越数TB数据的必需方案。以存储1PB数据、跨越256个分片共768台服务器的场景为例，文章重点阐述代理层如何通过查询解析、路由规划和连接池，将众多分片对外表现为单一数据库。文中介绍了基于哈希的分片策略、JSON拓扑配置，并给出从应用经网络负载均衡到代理再到分片的完整数据流。文章主要提供架构层面的概览与工具选择（Neki for Postgres、Vitess for MySQL），而非深入实现细节，适合正在规划数据库扩展的工程师建立整体认知。
该文以清晰的架构图和具体规模为例，系统梳理了数据库分片的核心挑战与代理层设计，对理解分片系统的整体运作有实际参考价值。适合需要应对数据量增长的研发、DBA和基础设施工程师，可迁移的分层架构与路由思想能直接指导技术选型和方案设计。
工程实践 Netflix TechBlog 2026/07/13
本文详细介绍了Netflix构建实时服务拓扑系统的完整工程历程，涵盖架构设计、生产环境挑战与持续优化。系统采用流式优先的三阶段分布式聚合流水线，结合反向压力、动态一致性哈希和时间窗口聚合器，实现了对网络流日志、IPC指标的高吞吐处理与历史拓扑查询。文章重点分析了Kafka消费滞后、热点节点、内存与GC压力、响应式流复杂性等关键问题，并通过重分布、使用可变数据结构替代不可变对象、更换通信协议等务实手段解决。作者强调，在超大规模下测量驱动迭代优化比遵循教条更重要，同时也指出了响应式流心智模型的高成本。该案例为构建大规模分布式数据流水线提供了可迁移的架构模式与性能调优经验，但部分技术选型需结合自身场景评估。
本文收录理由在于它提供了从0到1构建大规模服务拓扑系统的完整工程案例，而非浅层介绍。作者坦诚分享了架构权衡、失败教训和优化方法论，对分布式系统、流处理和可观测性领域的工程师有直接参考价值。可迁移的核心经验包括多阶段重分布解决数据倾斜、背压实现优雅降级以及性能优化时的务实取舍，但采用时需结合自身规模与技术栈做适配。
工程实践 知乎 - 腾讯技术工程 2026/06/26
本文拆解了腾讯混元 Hy3 preview 在 Hopper 96G 上的推理全栈优化，围绕算子优化与融合、并行策略、多级缓存、MTP 异步调度、量化与稀疏五个方向展开。作者针对 Attention、MoE、Router、采样、AllReduce 等关键路径做了动态调度、双 BF16 GEMM、FusedMoE、通算融合和算子级融合，显著减少 HBM 往返与 Kernel 启动开销。系统层面又通过 TPSP、DP+EP、三级缓存和按最大接收长度预组装输入，缓解长上下文、MoE 与 MTP 带来的通信、显存和 CPU 气泡问题。文中给出了真实请求集与多组实测指标，如 TTFT 降幅约 24.5%~29.9%、端到端吞吐提升 15.7%~44.7%、量化后吞吐提升 28%+、稀疏注意力在 128K 上将 Prefill 延迟降低 3.6 倍。整体方法高度依赖 Hopper 架构、自研 kernel 与腾讯内部基础设施，迁移到其他模型或硬件时需要重新验证边界与收益。
收录，因为文章给出了真实请求集、Hopper 96G 和 W8A8C8 约束下的系统性优化路径，并明确量化了 TTFT、吞吐和单算子加速收益。适合做大模型推理、GPU Kernel 融合、并行与缓存设计的参考，但方案强依赖特定硬件与自研栈，迁移时需重做适配验证。
工程实践 Netflix TechBlog 2026/06/22
这篇文章介绍了 Netflix 如何把自研的批处理计算系统 CMB 迁移到 Kubernetes 生态中的 Kueue，以替换原有的排队、调度和容量管理逻辑。作者不仅解释了迁移动机，还详细说明了租户层级、保留容量与共享容量的语义、Cohort/ClusterQueue/LocalQueue 的映射关系，以及如何在不改变用户 API 的前提下完成透明迁移。文章最后总结了高 QPS 配置、先迁最复杂客户、以及引入公平共享和抢占机制等经验，并说明这些改造已在生产中支撑数百万批任务运行。
推荐收录，因为它展示的是一次真实的大规模批处理平台重构，而不是单纯介绍一个开源工具。文章对多租户容量管理、调度语义迁移、灰度与回滚、以及生产吞吐保障都有具体做法，具备很强的可迁移参考价值。
工程实践 OpenAI Research 2026/06/04
这篇文章介绍了 ChatGPT 记忆系统从“手动保存记忆”演进到基于后台自动归纳的 dreaming 机制，重点解决记忆陈旧、正确性和规模化成本三个问题。文章还给出了评估记忆质量的三个维度：持续携带上下文、遵循偏好与约束、随时间保持最新，并说明新架构如何通过记忆摘要页让用户查看和管理被合成的记忆。整体上它展示的是一个已经进入产品化部署的 AI 个性化系统设计，而不是单纯的功能宣传，适合作为 AI 工程与产品化记忆系统的参考案例。
推荐收录，因为它把“记忆”从概念层面落到了可评估、可更新、可扩展的系统设计，覆盖了上下文继承、偏好跟随和时间衰减这类真实问题。对做 AI 产品、个性化系统或长上下文状态管理的人来说，这篇文章有较强的迁移价值。
工程实践 Instacart Tech Blog 2026/06/02
文章复盘了 Instacart 广告召回系统从“对固定候选集打分”转向“按 token 自回归生成”的重构过程。作者先分析了旧式 BERT 检索在词表膨胀、冷启动和候选结构漂移上的瓶颈，再介绍用 Semantic IDs 作为新产品词汇、用上下文模板组织训练输入、以及通过 beam search 生成候选并映射回商品索引的完整方案。为了支撑新模型，团队还重建了 GPU serving 栈（TensorRT-LLM、Triton、Go-native 服务），最终在两条发现型广告位上取得了约 +5% CTR、+34% add-to-carts 的线上收益，并显著提升了长尾类目和品牌多样性。
推荐收录，因为它不是单纯的产品宣传，而是把广告召回从建模、表示、训练、检索到推理基础设施完整串起来，呈现了一个可迁移的工业级重构范式。对于做推荐系统、检索系统和大模型推理落地的读者，这篇文章能直接提供“何时从打分转向生成”“如何重做表示层”“如何为生成式召回重建 serving 栈”的判断框架。
工程实践 Datadog Engineering 2025/06/17
这篇文章讲 Datadog 如何在大规模生产环境中拆解一个共享数据库，核心目标是把原本耦合的业务边界重新切开，同时尽量不影响线上稳定性。作者强调先定义清晰的所有权边界，再通过分阶段迁移、风险隔离和回滚预案降低改造成本，而不是一次性“硬拆”。文中还介绍了用于自动化迁移、校验一致性和减少人工操作的配套工具，以保证解耦过程可重复、可持续。它的重点不在数据库原理本身，而在多团队共用核心存储时如何平衡组织边界、迁移风险和工程效率。其适用前提是已有足够的监控、测试和发布控制能力，若系统变更链路薄弱，收益会被迁移复杂度抵消。
文章直接围绕“shared database at scale”的拆分实践展开，给出了边界划分、风险控制和自动化工具这三类可迁移做法，明显属于可长期参考的工程案例。适合正在做服务解耦、数据库分片/迁移或多团队协作治理的读者，但需要注意其前提是具备较成熟的发布与验证体系。
工程实践 Datadog Engineering 2025/06/17
这篇文章讲的是 Datadog 如何把按租户划分的配置数据，稳定、低延迟地分发到成千上万的工作负载容器中，以支撑实时日志处理场景。核心问题不是单纯“把配置发出去”，而是在容器规模快速增长、租户数量多、更新频繁的情况下，同时保证可用性、传播时延和配置一致性。文章强调了面向大规模分发系统的工程化设计思路，包括可靠传输、失败恢复以及对性能目标的持续验证。它的价值在于展示了一个典型的基础设施系统如何在多租户和高吞吐约束下做取舍，并把配置分发变成可运营、可扩展的能力。适用读者主要是做平台、基础设施、可观测性或大规模后台系统的工程师。其边界在于这是特定于配置分发与实时日志处理的经验，迁移时仍需结合自身配置变更频率、容器生命周期和一致性要求。
推荐收录，因为标题与摘要直接表明它解决的是“千级容器配置分发”的真实工程问题，且明确关注低延迟与高可靠两类核心指标。对平台、可观测性和多租户后台系统的读者，这类分发架构、稳定性设计和扩展性权衡具有较强迁移价值。
工程实践 PlanetScale Blog 2024/08/19
文章围绕数据库在云上扩容时最容易被忽视的 IOPS 和吞吐量成本展开，先解释 AWS EBS 中 IOPS 的计量方式、顺序/随机读写对有效带宽的影响，以及 gp3、io1、io2 的配额与价格差异。随后作者用 RDS、Aurora 和 PlanetScale 的月费对比，说明当单体数据库从中等规模增长到 8 倍需求时，单机方案往往要付出显著更高的 I/O Premium。文章的核心观点是：对 I/O 密集型数据库，分片可以把计算、存储和 I/O 压力拆散到多个 primary 上，从而继续使用更便宜的存储层。文中还指出分片带来的额外收益包括故障隔离、备份更快和长期线性扩展，但没有给出实际压测结果，因此结论更偏成本与架构层面的比较，而非纯性能评测。
文中直接用 EBS 的 IOPS/吞吐限制和三种数据库方案的月费对比，证明了单体扩容会迅速推高 I/O 成本，而分片能把需求摊平到多个 shard 上。适合做数据库容量规划、云成本评估和分片选型的读者；但价格结论依赖区域、流量形态和分片键设计，落地时需要按自身 workload 复算。
技术文章 PlanetScale Blog 2024/07/10
文章以一个健身应用中的 exercise_log 大表为例，解释为什么少数高增长表会先成为数据库瓶颈：写入频繁、历史数据持续被查询，最终把存储、内存和 IO 都推到极限。作者先讨论纵向扩容，即通过增加 CPU、内存和磁盘来延长单机数据库的可用寿命，但指出当数据达到多 TB 时，成本和资源争用会迅速上升。接着介绍垂直分片，把大表从主库中拆出到独立 keyspace，并借助 Vitess 的 MoveTables 平滑迁移和切流，使主业务表与日志表可以分别扩展。最后给出水平分片方案：按 user_id 做哈希分布、使用 sequence 生成全局 ID，再通过 Reshard 把单表扩到多个 shard。文章还总结了分片带来的吞吐提升、备份加速、故障隔离和成本优化，同时提醒分片键选择会直接影响查询局部性和性能。
推荐收录，因为文章明确给出了大表扩容的三级演进路径，并直接展示了 Vitess 的 MoveTables、Reshard 和分片键设计等可操作证据。适合做数据库架构、MySQL 扩容和日志/消息类大表治理的参考，但读者需要结合自身读写模式谨慎选择分片键。
技术文章 PlanetScale Blog 2024/07/08
这篇文章系统介绍了数据库分片的三种常见策略：directory/lookup-based、range-based 和 hash-based，并用示例说明它们如何根据 shard key 将数据分散到不同分片。作者分别分析了每种方法的优缺点：目录式分片便于按业务规则精确路由，但依赖额外的查表步骤，且容易因数据倾斜或热点访问造成单分片压力；范围分片实现直观，但如果范围划分不合理，很容易出现分布不均，需要通过 reshard 调整；哈希分片通常能获得更均匀的数据分布，代价是要做哈希计算，并且仍需谨慎选择高基数且符合访问模式的 shard key。文章还强调，分片方案不是点击按钮即可完成，真正落地时要结合数据分布、访问模式和后续扩容计划一起考虑。PlanetScale 的倾向是把 hash-based 作为默认选择，因为它通常最均衡、复杂度也更低，但这并不意味着它适合所有场景。
文章直接给出了三类分片策略的机制、优缺点和适用边界，属于数据库扩展的基础参考，而不是单纯的产品介绍。适合正在设计 MySQL/分库分表方案、评估 shard key 或做容量规划的读者阅读。
工程实践 Datadog Engineering 2021/02/22
文章复盘 Datadog 将内部 job system 迁移到 Kubernetes 后，如何压低平台引入的额外开销。作者指出瓶颈并不只在业务计算本身，而常出现在容器启动、调度等待、资源分配和节点利用率等环节。随后通过调整任务模型、批量与复用策略、以及更合理的资源请求配置来减少空转和抖动。文中强调迁移收益不能只看单点指标，而要结合吞吐、尾延迟和资源成本做端到端评估。它适合需要把批处理或异步任务迁到容器编排平台的工程团队参考，但具体方案仍受作业形态与隔离要求限制。
推荐收录，因为标题直接指向“minimized the overhead”和“moving a jobsystem to Kubernetes”，属于典型的真实工程优化案例。对做批处理平台、容器化迁移和成本优化的读者尤其有价值，可迁移的方法是用端到端指标分析调度与资源开销，而不是只盯业务代码。