將應用程式的元件部署到個別的進程或容器，以提供隔離和封裝。 此模式也可以讓應用程式由異質元件和技術組成。
這種模式名為 Sidecar ，因為它類似於附加在摩托車上的側車。 在模式中，側車會附加至父應用程式，並提供應用程式的支援功能。 Sidecar 也會與父應用程式共用相同的生命週期，與父應用程式一起建立和淘汰。 側車模式有時稱為側車模式，而且是分解模式。
內容和問題
應用程式和服務通常需要相關的功能，例如監視、記錄、組態和網路服務。 這些周邊工作可以實作為個別的元件或服務。
如果它們緊密整合至應用程式，則可以在與應用程式相同的進程中執行，以有效率地使用共用資源。 不過，這也表示它們並未完全隔離，而且其中一個元件的中斷可能會影響其他元件或整個應用程式。 此外，通常需要使用與父應用程式相同的語言來實作它們。 因此，元件和應用程式彼此之間具有密切的相依性。
如果應用程式分解成服務，則可以使用不同的語言和技術來建置每個服務。 雖然這可提供更大的彈性，但表示每個元件都有自己的相依性，而且需要特定語言的連結庫才能存取基礎平臺和與父應用程式共用的任何資源。 此外，將這些功能部署為個別服務可能會為應用程式增加延遲。 管理這些語言特定介面的程式代碼和相依性，也可以增加相當的複雜度，特別是裝載、部署和管理。
解決方案
與主要應用程式共置一組聯合工作，但將它們放在自己的進程或容器內，為跨語言的平臺服務提供同質介面。
側車服務不一定是應用程式的一部分，而是與其連線。 它會在父應用程式所在的位置進行。 Sidecars 支援使用主要應用程式部署的進程或服務。 在摩托車上，側車連接到一輛摩托車，每個摩托車都可以有自己的側車。 同樣地，側車服務會共用其父應用程式的命運。 針對應用程式的每個實例，側車的實例會一併部署並裝載。
使用側車模式的優點包括：
Sidecar 與運行時間環境和程式設計語言的主要應用程式無關，因此您不需要為每個語言開發一個側車。
Sidecar 可以存取與主要應用程式相同的資源。 例如，側車可以監視側車和主要應用程式所使用的系統資源。
由於其與主要應用程式的鄰近性，因此在主要應用程式之間通訊時不會有顯著的延遲。
即使對於未提供擴充性機制的應用程式，您也可以使用側車，將它附加為與主要應用程式相同的主機或子容器中自己的進程來擴充功能。
側車模式通常與容器搭配使用，稱為側車容器或 sidekick 容器。
問題和考量
- 請考慮您將用來部署服務、進程或容器的部署和封裝格式。 容器特別適合側車模式。
- 設計側車服務時，請仔細決定進程間通訊機制。 除非效能需求不切實際，否則請嘗試使用語言或架構無關的技術。
- 將功能放入側車之前，請考慮它是否能更好地作為個別的服務或更傳統的精靈。
- 也請考慮是否可以將功能實作為連結庫或使用傳統的擴充機制。 特定語言連結庫的整合層級可能更深入，而且網路負荷較低。
使用此模式的時機
當下列情況時，請使用此模式：
- 您的主要應用程式會使用一組異質的語言和架構。 使用不同架構以不同語言撰寫的應用程式可以使用側車服務中的元件。
- 元件是由遠端小組或不同的組織所擁有。
- 元件或功能必須與應用程式位於相同的主機上。
- 您需要共用主要應用程式整體生命週期但可以獨立更新的服務。
- 您需要更精細地控制特定資源或元件的資源限制。 例如，您可能想要限制特定元件所使用的記憶體數量。 您可以將元件部署為側車，並獨立於主要應用程式管理記憶體使用量。
此模式可能不適合：
- 需要優化進程間通訊時。 父應用程式和 Sidecar 服務之間的通訊包含一些額外負荷，尤其是呼叫中的延遲。 這可能不是聊天介面可接受的取捨。
- 對於針對每個實例部署側車服務的資源成本不值得隔離的小型應用程式。
- 當服務需要與主要應用程式不同或獨立調整時。 如果是，最好將功能部署為個別服務。
工作負載設計
架構設計人員應該評估 Sidecar 模式如何用於其工作負載的設計，以解決 Azure 架構架構支柱中涵蓋的目標和原則。 例如：
| 要素 | 此模式如何支援支柱目標 |
|---|---|
| 安全性 設計決策有助於確保 工作負載數據和系統的機密性、 完整性和 可用性 。 | 藉由封裝這些工作並將其部署為跨進程，您可以將敏感性進程的介面區減少為僅完成工作所需的程序代碼。 您也可以使用側車，將跨領域安全性控件新增至未以該功能原生設計的應用程式元件。 - SE：04 分割 - SE：07 加密 |
| 營運卓越可透過標準化的流程和小組凝聚力，協助提供工作負載品質。 | 此模式提供在工具整合中實作彈性的方法，可增強應用程式的可檢視性，而不需要應用程式採用直接實作相依性。 它可讓側車功能獨立發展，並獨立於應用程式的生命周期進行維護。 - OE：04 工具和程式 - OE：07 監視系統 |
| 效能效率 可透過調整、數據、程式代碼的優化，有效率地協助您的工作負載 符合需求 。 | 您可以將跨領域工作移至單一進程，以跨多個主要進程的實例進行調整，這可減少為每個應用程式實例部署重複功能的需求。 - PE：07 程式代碼和基礎結構 |
如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。
範例
側車模式適用於許多案例。 一些常見的範例：
- 基礎結構 API。 基礎結構開發小組會建立與每個應用程式一起部署的服務，而不是語言特定的用戶端連結庫來存取基礎結構。 服務會載入為側車，並提供基礎結構服務的通用層，包括記錄、環境數據、組態存放區、探索、健康情況檢查和監視程序服務。 Sidecar 也會監視父應用程式的主機環境和進程（或容器），並將信息記錄到集中式服務。
- 管理 NGINX/HAProxy。 使用可監視環境狀態的側車服務部署 NGINX，然後更新 NGINX 組態檔，並在需要狀態變更時回收程式。
- 大使側車。 將大使服務部署為側車。 應用程式會透過大使呼叫，以處理要求記錄、路由、斷路器和其他連線相關功能。
- 卸除 Proxy。 將 NGINX Proxy 放在node.js服務實例前面，以處理服務的靜態檔案內容。