在開發微服務架構時，工程師常面臨一個棘手問題：每個服務都需要日誌記錄（Logging）、監控（Monitoring）、認證（Authentication）與配置管理等功能。如果將這些功能直接寫在每個微服務的業務邏輯中，會導致程式碼重複、維護困難，且一旦日誌系統崩潰，可能會直接拖垮整個業務服務。
為了解決這個問題，我們可以引入 Sidecar 模式。
什麼是 Sidecar 模式
Sidecar 模式的名字源自於機車旁的邊車（Sidecar）。在軟體設計中，它指的是將輔助功能（橫切關注點，Cross-cutting Concerns）從主應用程式中抽離，部署在一個獨立的進程或容器中，並與主應用程式運行在一起。
簡單來說，主容器負責處理核心業務邏輯，而 Sidecar 容器則負責處理那些不屬於業務邏輯但又是系統運行必需的輔助任務。
Sidecar 模式的核心優勢
對於 Junior 工程師來說，可以將 Sidecar 理解為一個專屬的助手。它的好處包括：
解耦與簡化：主程式不需要知道日誌是如何傳送到 Elasticsearch 的，它只需要把資料交給助手即可。 語言無關性：主服務可以用 C# 寫，但 Sidecar 可以用 Go 或 Python 寫，只要兩者能溝通即可。 提高可靠性：如果 Sidecar 容器在處理日誌傳輸時崩潰，主服務的業務請求依然可以正常運作，不會因為輔助功能的失效而導致系統全面停擺。 易於擴展：當需要更換監控工具或更新安全策略時，只需更新 Sidecar 鏡像，無需重新編譯與部署主業務程式。
實務案例：實作分散式日誌收集系統
為了讓大家理解如何實作，我們以一個簡單的庫存管理系統為例。該系統包含兩個部分：Transactions API（主服務）與 Sidecar API（助手服務）。
傳統做法：Transactions API 直接呼叫 Elasticsearch API 寫入日誌。缺點是網路延遲會增加 API 回應時間，且若 Elasticsearch 暫時不可用，API 可能會報錯。
Sidecar 做法： Transactions API 將日誌放入記憶體佇列（ConcurrentQueue）。 一個背景服務（Background Service）將佇列中的日誌寫入到一個共享資料夾的文字檔中。 Sidecar API 獨立運行，定期掃描該共享資料夾，讀取日誌並將其批次傳送到 Elasticsearch。
這樣設計的關鍵在於主服務與 Sidecar 之間透過共享儲存（Shared Volume）進行非同步溝通，主服務的 HTTP 回應速度完全不會受到日誌傳輸速度的影響。
實作中的技術要點
在 .NET 實作中，可以使用 BackgroundService 來處理非同步的日誌讀寫，並利用 SemaphoreSlim 確保多執行緒寫入檔案時的執行緒安全（Thread-safe）。
在部署層面，Docker Compose 是本地開發的理想選擇。透過在 docker-compose.yml 中定義相同的 volume 映射（例如將 ./logs 映射到兩個容器的 /app/logs），主服務與 Sidecar 就能共享同一個檔案路徑。
從 Docker Compose 到 Kubernetes
雖然 Docker Compose 可以模擬 Sidecar，但真正的 Sidecar 模式在 Kubernetes (K8s) 中才發揮最大威力。
在 K8s 中，Sidecar 容器與主容器被封裝在同一個 Pod 內。這意味著它們共享同一個網路命名空間（Network Namespace），可以直接透過 localhost 互相溝通，且共享相同的生命週期（同時啟動、同時停止），這比單純的 Docker 容器映射更高效且穩定。
選擇實作路徑的建議
根據需求複雜度，你可以選擇不同的實作方式：
自定義實作：適用於需求簡單、希望完全掌控邏輯且不想引入額外依賴的場景。 使用 Dapr (Distributed Application Runtime)：Dapr 是一個成熟的開源 Sidecar 框架，提供了服務呼叫、狀態管理與事件驅動等標準 API，能讓工程師跳過撰寫重複的基礎設施程式碼，專注於業務價值。 使用 Serilog 與 Elasticsearch Sink：如果你只需要日誌功能且全部使用 .NET，直接使用成熟的日誌庫可能是最快路徑。 K8s DaemonSet：若需要在每個節點運行一個日誌收集器（而非每個 Pod 一個），則適合使用 DaemonSet。
效能考量與限制
Sidecar 並非沒有代價。由於增加了額外的網路跳轉（Network Hop）或磁碟 I/O（如上述檔案共享案例），對於極端要求低延遲（Ultra-latency sensitive）的場景，Sidecar 可能會引入額外開銷。在實務上，建議使用批次處理（Batching）來減少與後端儲存系統的互動次數，以提升整體吞吐量。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。