Airbnb 分享 Sitar-Agent 动态配置 Sidecar 在 Kubernetes 服务中的架构

2026年7月8日 · 2分钟阅读 · 作者 Leela Kumili（首席工程师）

Airbnb 工程师详细介绍了 Sitar-agent 的架构，这是一个 Kubernetes sidecar，用于在数万个 Pod 之间分发动态配置更新，每分钟处理多次配置变更。该系统设计为在服务中断期间保持配置数据可用，同时使更新能够在数十秒内传播到庞大的微服务集群。Airbnb 通过 Java 重写、Amazon S3 快照启动引导以及从 Sparkey 迁移到 SQLite，对 Sitar-agent 进行了现代化改造。这些变更旨在提升可靠性、启动性能与运营韧性，同时减少对集中式配置基础设施的依赖。

Sitar-agent 是 Airbnb 内部 Sitar 配置系统的一部分，允许工程师通过配置变更而非服务重新部署来修改应用行为。由于配置更新每分钟发生多次，且环境包含大量微服务，Airbnb 需要一种机制，在尽量减少对集中式基础设施依赖的前提下，一致地交付变更。

[LOADING...]
Sitar 配置交付生命周期（来源：Airbnb 博客文章）

该 sidecar 与 Kubernetes 中的应用容器一起运行，通过共享文件系统和内存缓存本地提供配置数据。服务无需直接与配置平台通信，而是从本地 sidecar 读取配置值。Airbnb 表示，这种方法在 Java、Python、Go、TypeScript 和 Ruby 服务之间提供了语言无关性，同时将配置交付逻辑集中到单个组件中。

动态配置是 Airbnb 基础设施的基础能力，使我们能够快速适应并交付创新。
——Bo T，Airbnb 软件工程师，在 LinkedIn 帖子中

作为重新设计的一部分，工程师引入了基于快照的启动工作流。配置快照定期生成并存储在 Amazon S3 中。当新 Pod 启动时，Sitar-agent 会检索最新的快照，然后从 Sitar 后端同步增量更新，之后才允许应用开始处理流量。据 Airbnb 称，这减少了启动开销，并使得即使中央配置服务暂时不可用，服务也能继续运行。

工程团队还重新审视了使用 sidecar 架构而非将配置交付逻辑嵌入应用库的决策。虽然基于库的方法可以减少资源消耗，但 Airbnb 得出结论，维护一个专用的 sidecar 简化了运维，减少了重复实现工作，并确保跨多种编程语言的行为一致性。

另一项重大变更是替换了代理原先使用的本地数据存储 Sparkey。工程师在评估了 SQLite 和 RocksDB 后选择了 SQLite，原因是其并发模型、运维简单性以及广泛的语言生态系统支持。为降低迁移风险，团队在生产工作负载切换到新数据存储之前，使用了影子读取验证和功能标志控制的灰度发布。

Airbnb 还讨论了其持续使用的拉取式配置分发模型。Sitar-agent 每大约 10 秒轮询一次后端服务以获取更新。该公司报告称，服务端缓存和增量变更跟踪有助于降低后端负载，同时提供适用于运营配置管理工作流程的更新传播时间。

关于作者

[LOADING...]
Leela Kumili是星巴克的首席软件工程师，在构建可扩展的云原生系统和分布式平台方面拥有深厚专业知识。她负责驱动奖励平台的架构、交付和运营卓越，领导系统现代化、提升可扩展性和可靠性的工作。除了技术领导力，她还担任组织的 AI 倡导者，识别利用基于 LLM 的工具提升开发人员生产力和工作流程的机会，并建立 AI 采用的最佳实践。她热衷于构建可投入生产的系统、提升开发人员体验，并指导工程师在技术和战略影响力方面成长。她的兴趣包括平台工程、分布式系统、开发人员生产力以及将技术解决方案与业务和产品目标相结合。