在微服務架構中，當我們需要調整系統行為（例如更改限流閾值、切換功能開關或調整超時時間）時，最理想的方式是動態配置，而不是每次都重新編譯程式碼並重新部署整個服務。然而，當服務規模達到數萬個 Pod 且配置更新頻率每分鐘多次時，如何確保配置能快速、可靠且不對中央伺服器造成過大壓力地分發，就成了一個巨大的工程挑戰。
Airbnb 針對這個問題開發了 Sitar-Agent，這是一個運行在 Kubernetes 中的 Sidecar 容器。對於不熟悉 Sidecar 模式的工程師來說，你可以將其想像成一個隨身助理，它與你的應用程式容器運行在同一個 Pod 中，共享網路與儲存空間。應用程式不再直接向遠端配置伺服器請求數據，而是從這個本地的助理（Sitar-Agent）獲取配置。
這種設計的核心目的在於解耦。由於 Sitar-Agent 負責所有與配置平台溝通的邏輯，無論應用程式是用 Java、Python、Go 還是 Ruby 編寫，都能透過統一的本地介面獲取配置，實現了語言無關性，避免了在每種語言的 SDK 中重複實作複雜的分發邏輯。
為了提升系統的可靠性與啟動速度，Airbnb 對 Sitar-Agent 進行了重大重構，其中最關鍵的改進在於啟動流程的優化。在舊有模式下，如果 Pod 啟動時必須從中央伺服器抓取全量配置，會造成啟動緩慢且增加伺服器壓力。現在他們引入了基於 Amazon S3 的快照機制（Snapshot Bootstrapping）。系統會定期將配置快照存儲在 S3 中，新 Pod 啟動時先從 S3 下載最新的快照，再向後端請求啟動後的增量更新。這樣即使中央配置服務暫時不可用，服務依然能依靠快照正常啟動並運行。
在本地數據儲存的選擇上，Airbnb 將原本的 Sparkey 替換為 SQLite。在評估過程中，他們對比了 RocksDB 與 SQLite，最終選擇 SQLite 是考量到其併發處理模型、維運的簡單程度以及極廣的生態支援。為了確保這次遷移不會導致生產環境崩潰，團隊採取了影子讀取（Shadow-read）驗證，即在切換前讓新舊儲存系統同時運行並比對結果，並配合功能開關（Feature Flag）逐步推送。
關於配置的同步方式，Sitar-Agent 採用的是拉取模式（Pull-based model），大約每十秒輪詢一次後端。雖然推送模式（Push-based）理論上更快，但拉取模式在面對數萬個節點時更具可控性。透過伺服器端快取與增量追蹤技術，Airbnb 在維持低後端負荷的同時，將配置傳播時間控制在數十秒內。
總結來說，Sitar-Agent 的設計體現了分佈式系統中一個重要的權衡：透過增加一個 Sidecar 的資源開銷，換取了跨語言的一致性、更強的容錯能力（即便中央服務掛掉也能啟動）以及更簡單的應用開發體驗。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。