Microservices

2 篇内容

工程实践Oxide Public RFDs

RFD 0419: Only YOU can prevent unwinding sagas

本文是 Oxide Computer 的公开 RFD 419,探讨如何为分布式 saga 编写正确的节点。文章首先定义正确 saga 节点需满足的四个属性:补偿动作应尽量回滚前向动作或使系统保持一致、前向动作必须幂等、原子性(避免多步状态变更)以及必须得到已知结果。随后列举常见陷阱,包括在参数中使用名称引发 TOCTOU、动态状态变更的循环、无补偿动作的节点、中间状态可见导致并发 saga 冲突,以及删除与创建 saga 交错执行。文章强调 saga 并非事务,节点执行间隔可能很长,作者必须考虑重复执行、并发执行和跨时间重复的“企鹅”问题,并建议通过软删除和幂等端点来支持重试。最后指出这些约束需扩展到被调用的守护进程及其嵌套路径,但未给出强制机制,依赖代码作者和评审者的纪律。

推荐收录。本文系统总结了分布式 saga 节点正确性的四个核心属性(补偿、幂等、原子、已知结果),并列举了大量来自 Oxide 真实工程(如磁盘删除、快照创建、NIC 附加)的陷阱与应对模式,如避免参数用名、处理动态步数、防范并发 saga 交错。对设计分布式任务编排、微服务补偿流程或需要保证最终一致性的后端工程师极具参考价值,可直接迁移其检查清单。主要不足是缺少自动化强制手段,依赖作者与评审者纪律。

工程实践LinkedIn Engineering - Architecture

How we reduced latency and cost-to-serve by merging two systems

本文介绍 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 延迟改善、内存分配下降和资源节省。适合关注微服务粒度、性能优化和成本控制的架构师与后端工程师。可迁移价值在于展示了当数据服务逻辑薄弱时合并服务的考量方法,以及利用灰度发布和流量镜像降低高风险变更的实践。