Airbnb 分享 Kubernetes 动态配置 Sidecar Sitar-agent 的架构

Airbnb 工程师们详细介绍了 Sitar-agent 的架构。这是一个 Kubernetes sidecar，能够将动态配置更新分发到数万个 Pod 中，并且每分钟可以处理多次配置变更。该系统旨在确保服务中断期间仍然可以访问配置数据，同时使更新能在数十秒内钟传播到庞大的微服务集群中。

该公司通过使用 Java 重写、Amazon S3 快照引导以及从 Sparkey 迁移至 SQLite，实现了对 Sitar-agent 的现代化改造。这些改动旨在提高可靠性、启动性能和运营韧性，同时减少对集中式配置基础设施的依赖。

Sitar-agent 是 Airbnb 内部 Sitar 配置系统的一部分。该系统允许工程师通过修改配置而非重新部署服务来调整应用程序的行为。由于在大型微服务环境中，配置更新每分钟会发生多次，所以该公司需要一种机制，既能一致地交付变更，又能最大限度地减少对集中式基础设施的依赖。

Sitar 配置交付生命周期（图片来源：Airbnb 博文）

该 sidecar 与 Kubernetes 中的应用容器并行运行，并通过共享文件系统和内存缓存在本地提供配置数据。应用程序不需要与配置平台直接通信，而是从本地 sidecar 中读取配置值。Airbnb 表示，这种方法使其 Java、Python、Go、TypeScript 和 Ruby 服务实现了语言独立性，同时将配置分发逻辑集中到了单个组件中。

Airbnb 软件工程师 Bo T 在 LinkedIn 的一篇博文中写道：

动态配置是 Airbnb 基础设施的基础能力，它使我们能够快速适应并推出创新。

作为重新设计的一部分，工程师们引入了一种基于快照的启动工作流。系统会定期生成配置快照并将其存储在 Amazon S3 中。当新 Pod 启动时，Sitar-agent 会检索最新快照，然后从 Sitar 后端同步增量更新，之后应用程序才可以开始处理流量。按照 Airbnb 的说法，这不仅降低了启动开销，还可以确保服务在中央配置服务暂时不可用的情况下也能继续运行。

工程团队还重新审视了采用 sidecar 架构而非将配置分发逻辑嵌入应用程序库的决策。虽然基于库的方法可以降低资源消耗，但 Airbnb 认为，维护一个专用的 sidecar 架构能够简化运维、减少重复的实现工作，并确保在多种编程语言中保持行为一致性。

另一项重大变更涉及替换代理程序此前使用的本地数据存储 Sparkey。工程师们评估了 SQLite 和 RocksDB 之后，最终因其并发模型、操作简便性以及对语言生态系统的广泛支持而选择了 SQLite。为了降低迁移风险，团队在将生产环境的工作负载迁移到新数据存储之前，采用了影子读取验证和功能标志控制的分阶段部署策略。

此外，Airbnb 还讨论了他们继续采用基于拉取的配置分发模型的情况。为了获取更新，Sitar-agent 大约每十秒钟会向后端服务发起一次轮询。该公司表示，服务器端缓存和增量变更跟踪有助于减轻后端负载，同时提供适合运营配置管理工作流的更新传播时间。

原文链接：https://www.infoq.com/news/2026/07/sitar-agent-sidecar-config/