Šablona Sidecar

Nasaďte komponenty aplikace do procesu nebo kontejneru odděleně od hlavní aplikace, abyste zajistili izolaci a zapouzdření. Tento model umožňuje vytvářet aplikace z různých komponent a technologií.

Podobně jako přídavný modul se tyto komponenty připojují k nadřazené aplikaci a sdílejí její životní cyklus, takže je vytváříte a vyřazujete společně. Tento model se také označuje jako model Sidekick a podporuje rozklad aplikací.

Kontext a problém

Aplikace a služby často vyžadují související funkce, jako je monitorování, protokolování, konfigurace a síťové služby. Tyto úlohy periferních zařízení můžete implementovat jako samostatné komponenty nebo služby.

Úzce integrované komponenty běží ve stejném procesu a efektivně využívají sdílené prostředky, ale nemají izolaci. Výpadek v jedné komponentě může ovlivnit celou aplikaci. Vyžadují také implementaci v jazyce nadřazené aplikace, která vytváří vzájemnou závislost.

Pokud aplikaci rozložíte do služeb, můžete každou službu sestavit pomocí různých jazyků a technologií. Tento přístup poskytuje větší flexibilitu. Každá komponenta má ale vlastní závislosti a pro přístup k platformě a sdíleným prostředkům vyžaduje knihovny specifické pro jazyk. Když tyto funkce nasadíte jako samostatné služby, přidáte latenci. Kód a závislosti specifické pro jazyk také zvyšují složitost hostování a nasazení.

Řešení

Nasaďte soudržnou sadu úloh společně s primární aplikací v samostatném procesu nebo kontejneru. Tento přístup poskytuje konzistentní rozhraní pro služby platformy napříč jazyky.

Diagram znázorňující vzor Sidecar

Služba typu sidecar se připojí k aplikaci, aniž by byla její součástí, a je nasazena současně s ní. Každá instance aplikace získá vlastní instanci pomocné aplikace, která sdílí její životní cyklus.

Vzor sidecar poskytuje následující výhody:

  • Nezávislost jazyka: Sidecar funguje nezávisle na běhovém prostředí a programovacím jazyce primární aplikace. Jednu implementaci sidecaru můžete použít napříč aplikacemi psanými v různých programovacích jazycích.

  • Sdílený přístup k prostředkům: Sidecar má přístup k těm stejným prostředkům jako hlavní aplikace. Například sidecar může monitorovat systémové prostředky, které obě komponenty používají.

  • Nízká latence: Blízkost komponenty sidecar k primární aplikaci minimalizuje komunikační latenci.

  • Vylepšená rozšiřitelnost: Aplikace, které nemají nativní mechanismy rozšiřitelnosti, můžete rozšířit připojením sidecar jako samostatného procesu na stejném hostiteli nebo podkontejneru.

Nejběžnější implementace tohoto modelu používá kontejnery, které jsou také nazývány jako sidecar kontejnery nebo sidekick kontejnery.

Problémy a důležité informace

Při implementaci tohoto modelu zvažte následující body:

  • Zvažte formát balení a nasazení pro nasazení služeb, procesů nebo kontejnerů. Kontejnery dobře fungují pro vzor Sidecar.

  • Při návrhu služby sidecar pečlivě zvolte mechanismus meziprocesní komunikace. Používejte technologie nezávislé na jazyce nebo na architekturu, pokud nejsou požadavky na výkon pro tento přístup nepraktické.

  • Než přidáte funkčnost do sidecaru, vyhodnoťte, zda funguje lépe jako samostatná služba nebo tradiční démon.

  • Zvažte, jestli chcete implementovat funkce jako knihovnu nebo prostřednictvím tradičního mechanismu rozšíření. Knihovny specifické pro konkrétní jazyk poskytují hlubší integraci a méně režijní náklady na síť.

Kdy použít tento vzor

Tento model použijte v těchto případech:

  • Vaše primární aplikace používá různé jazyky a architektury. Sajdkáře poskytují konzistentní rozhraní, které mohou různé aplikace používat bez ohledu na jejich jazyk nebo architekturu.

  • Samostatný tým nebo externí partner vlastní komponentu.

  • Komponentu nebo funkci musíte nasadit na stejného hostitele jako aplikaci.

  • Potřebujete službu, která sdílí celkový životní cyklus hlavní aplikace, ale můžete ji aktualizovat nezávisle.

  • Potřebujete jemně odstupňovanou kontrolu nad limity prostředků pro konkrétní prostředek nebo komponentu. Komponentu můžete například nasadit jako sidecar, která omezuje a spravuje využití paměti nezávisle na hlavní aplikaci.

Tento vzor nemusí být vhodný v těchto případech:

  • Potřebujete optimalizovat komunikaci mezi procesy. Sidecary přidávají režii, zejména latenci, což je nevhodné pro aplikace s častou komunikací mezi komponentami.

  • Vaše aplikace je malá. Náklady na prostředky nasazení sajdkáře pro každou instanci můžou převažovat nad výhodami izolace.

  • Komponentu musíte škálovat nezávisle. Pokud je nutné škálovat komponentu odlišně od hlavní aplikace, nasaďte ji místo toho jako samostatnou službu.

  • Vaše platforma poskytuje ekvivalentní funkce. Pokud vaše aplikační platforma už nativně poskytuje potřebné funkce, nasazení sidecarů přidává zbytečnou složitost.

Návrh úloh

Vyhodnoťte, jak použít vzor Sidecar při návrhu zátěže k řešení cílů a principů v pilířích Azure Well-Architected Framework. Následující tabulka obsahuje pokyny, jak tento model podporuje cíle jednotlivých pilířů.

Pilíř Jak tento model podporuje cíle pilíře
Rozhodnutí o návrhu zabezpečení pomáhají zajistit důvěrnost, integritu a dostupnost dat a systémů vaší úlohy. Když tyto úlohy zapouzdřete a nasadíte je v samostatných procesech, omezíte prostor pro útoky jenom na potřebný kód. Sajdkáře můžete také použít k přidání průřezových bezpečnostních prvků do komponent aplikací, které nemají nativní podporu těchto funkcí.

- SE:04 Segmentace
- SE:07 Šifrování
Efektivita provozu pomáhá poskytovat kvalitu úloh prostřednictvím standardizovaných procesů a týmové soudržnosti. Tento model umožňuje pružně integrovat nástroje pozorovatelnosti bez přidání závislostí do kódu aplikace. Sajdkáru můžete aktualizovat a udržovat nezávisle na aplikaci.

- OE:04 Nástroje a procesy
- OE:07 Monitorovací systém
efektivita výkonu pomáhá vašim úlohám efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu. Tento model nabízí možnost centralizovat úlohy napříč celou aplikací ve sidecars, které se škálují napříč několika instancemi aplikací. Pro každou instanci aplikace nemusíte nasazovat duplicitní funkce.

- PE:07 Kód a infrastruktura

Pokud tento model představuje kompromisy v rámci pilíře, zvažte je proti cílům ostatních pilířů.

Example

Můžete aplikovat Sidecar pattern v mnoha scénářích. Zvažte následující příklady:

  • Abstrakce závislostí: Nasaďte vlastní službu společně s každou aplikací, která poskytuje přístup ke sdíleným možnostem závislostí prostřednictvím konzistentního rozhraní API. Tento přístup nahrazuje klientské knihovny specifické pro jazyk sidecarem, který se zabývá úlohami, jako je protokolování, konfigurace, zjišťování služeb, správa stavu a kontroly stavu.

    Sajdkára distribuovaných aplikací (Dapr) tento případ použití ilustruje.

  • Datová rovina meshové sítě služeb: Nasaďte sidecar proxy vedle každé instance služby, abyste mohli zpracovávat průřezové síťové záležitosti, jako je směrování provozu, opakování, vzájemné zabezpečení přenosové vrstvy (mTLS), vynucení zásad a telemetrie.

    Sítě služeb, jako Istio, používají proxy servery s modelem sidecar pro implementaci těchto funkcí bez nutnosti změn v kódu aplikace.

  • Ambassador sidecar: Nasaďte službu ambassador jako sidecar. Aplikace směruje volání přes ambasadora, který zpracovává protokolování požadavků, směrování, přerušení okruhu a další funkce připojení.

  • Adaptéry protokolu: Nasaďte sajdkáře pro překlad mezi nekompatibilními protokoly nebo datovými formáty nebo přemostěním systémů zasílání zpráv. Tento přístup umožňuje aplikaci používat jednodušší nebo starší rozhraní.

  • Rozšiřování telemetrie: Před předáním dat do externích monitorovacích systémů nasaďte sajdkáru k předzpracování nebo obohacení telemetrických dat, jako jsou metriky, protokoly a trasování. Komponenty, jako je OpenTelemetry Collector, se můžou spouštět jako doprovodné procesy pro normalizaci, rozšiřování nebo směrování telemetrie odděleně od aplikace.

Další kroky

  • Last updated on