Upravit

Sdílet prostřednictvím


Model sajdkára

Azure

Nasazuje komponenty aplikace do samostatného procesu nebo kontejneru s cílem poskytnout izolaci a zapouzdření. S tímto modelem také může být možné vytváření aplikací z heterogenních komponent a technologií.

Model se nazývá sajdkára, protože připomíná postranní vozík připojený k motocyklu. V tomto modelu se sajdkára připojuje k nadřazené aplikaci a obsahuje pomocné funkce pro aplikaci. Protože se vytváří a vyřazuje současně s nadřazenou aplikací, sdílí také stejný životní cyklus. Model sajdkára se někdy označuje jako model pomocník a představuje dekompoziční model.

Kontext a problém

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

Pokud jsou úzce integrované do aplikace, můžou běžet ve stejném procesu jako aplikace a efektivně využívat sdílené prostředky. To ale také znamená, že nejsou dobře izolované a výpadek v jedné z těchto komponent může ovlivnit jiné komponenty nebo celou aplikaci. Navíc je obvykle potřeba je implementovat ve stejném jazyce, jako používá nadřazená aplikace. V důsledku toho na sobě komponenta a aplikace úzce vzájemně závisí.

Pokud se aplikace rozloží na služby, bude možné vytvořit jednotlivé služby s použitím různých jazyků a technologií. I když se takto dosáhne větší flexibility, znamená to, že jednotlivé komponenty mají svoje vlastní závislosti a vyžadují knihovny pro konkrétní jazyky pro přístup k základní platformě a všem prostředkům sdíleným s nadřazenou aplikací. Kromě toho se může při nasazení těchto funkcí jako samostatných služeb zvýšit latence aplikace. U správy kódu a závislostí pro tato rozhraní používající konkrétní jazyk se může také významně zvýšit složitost, zejména u hostování, nasazení a správy.

Řešení

Umístěte spojené sady úloh společně s primární aplikací, ale do jejich vlastních procesů nebo kontejnerů a zajistěte tak službám platforem napříč různými jazyky homogenní rozhraní.

Diagram vzoru sajdkáře

Služba sajdkárna není nutně součástí aplikace, ale je k ní připojená. Probíhá stejně jako nadřazená aplikace. Modely sajdkára jsou podpůrné procesy nebo služby, které se nasazují s primární aplikací. U motorek se sajdkára připojí k jednomu stroji a každá motorka má svoji vlastní sajdkáru. Stejným způsobem pracuje služba sajdkára stejně jako její nadřazená aplikace. S každou instancí aplikace je nasazená a hostovaná jedna instance sajdkáry.

Výhody použití modelu sajdkára:

  • Sajdkára nezávisí na primární aplikaci, co se týče běhového prostředí a programovacího jazyka, takže není nutné vytvářet sajdkáru pro každý jazyk.

  • Sajdkára může získat přístup ke stejným prostředkům jako primární aplikace. Může například monitorovat systémové prostředky, které používá sajdkára i primární aplikace.

  • Vzhledem k blízkosti primární aplikace není při komunikaci mezi nimi žádná významná latence.

  • Dokonce i pro aplikace, které neposkytují mechanismus rozšiřitelnosti, můžete pomocí sajdkáře rozšířit funkce tak, že ji připojíte jako svůj vlastní proces ve stejném hostiteli nebo dílčím kontejneru jako primární aplikace.

Model sajdkára se často používá s kontejnery a označuje se jako kontejner sajdkára nebo kontejner pomocník.

Problémy a důležité informace

  • Zvažte, jaký formát nasazení a balení použijete k nasazení služeb, procesů nebo kontejnerů. Pro tento model sajdkára se hodí zejména kontejnery.
  • Při navrhování služby sajdkára pečlivě zvažte, jaký mechanismus komunikace mezi procesy použít. Pokud to nebude nepraktické z hlediska požadavků na výkon, zkuste použít technologie nebo rozhraní nerozlišující jazyk.
  • Před umístěním funkce do sajdkáry zvažte, jestli by lépe fungovala jako samostatná služba nebo tradičnější proces démon.
  • Zvažte také, jestli se dá funkce implementovat jako knihovna nebo jestli se má použít tradiční mechanismus rozšíření. Knihovny jazyka specifické pro jednotlivé jazyky můžou mít hlubší úroveň integrace a menší nároky na síť.

Kdy se má tento model použít

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

  • Vaše primární aplikace používá heterogenní sadu jazyků a architektur. Komponentu umístěnou ve službě sajdkára můžou využívat aplikace napsané v různých jazycích a používající různá rozhraní.
  • Komponentu vlastní vzdálený tým nebo jiná organizace.
  • Komponenta nebo funkce musí být umístěné společně na stejném hostiteli jako aplikace.
  • Potřebujete službu, která sdílí celý životní cyklus s vaší hlavní aplikací, ale dá se nezávisle aktualizovat.
  • U určitého prostředku nebo komponenty potřebujete mít důkladnou kontrolu nad limity prostředků. Můžete například chtít omezit velikost paměti, kterou používá určitá komponenta. Můžete nasadit komponentu jako sajdkáru a spravovat využití paměti nezávisle na hlavní aplikaci.

Tento model nebude pravděpodobně vhodný v následujících případech:

  • Když je nutná optimalizace komunikace mezi procesy. Komunikace mezi nadřazenou aplikací a službami sajdkára má jistá negativa, zejména je to latence volání. Může se jednat o kompromis, který nebude přijatelný u rozhraní s rozsáhlou komunikací.
  • U malých aplikací, kde náklady na nasazení prostředku ve formě služby sajdkára u každé instance neodpovídají výhodám, které přinese izolace.
  • Když služba potřebuje škálovat jinak než hlavní aplikace nebo nezávisle na nich. V takovém případě může být lepší nasadit funkci jako samostatnou službu.

Návrh úloh

Architekt by měl vyhodnotit způsob použití modelu sajdkáry v návrhu úloh k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:

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. Zapouzdřením těchto úloh a jejich nasazením mimo proces můžete snížit plochu citlivých procesů jenom na kód potřebný k provedení úkolu. Sajdkáře můžete také použít k přidání ovládacích prvků zabezpečení napříč řeznými prvky do komponenty aplikace, která není nativně navržena s danou 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 poskytuje přístup k implementaci flexibility v integraci nástrojů, který může zlepšit pozorovatelnost aplikace, aniž by aplikace vyžadovala přímé závislosti implementace. Umožňuje, aby se funkce sajdkáře vyvíjely nezávisle a byly udržovány nezávisle na životním cyklu aplikace.

- OE:04 Nástroje a procesy
- OE:07 Monitorovací systém
Efektivita výkonu pomáhá vaší úloze efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu. Úkoly křížového dělení můžete přesunout do jednoho procesu, který se dá škálovat napříč několika instancemi hlavního procesu, což snižuje potřebu nasadit duplicitní funkce pro každou instanci aplikace.

- PE:07 Kód a infrastruktura

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

Příklad

Model sajdkára se dá použít u řady scénářů. Některé běžné příklady:

  • Rozhraní API infrastruktury: Tým pro vývoj infrastruktury vytvoří službu, která se nasadí společně s každou aplikací, místo toho, aby se pro přístup k infrastruktuře použila klientská knihovna specifická pro konkrétní jazyk. Tato služba se načte jako sajdkára a poskytne společnou vrstvu pro služby infrastruktury, včetně protokolování, dat prostředí, úložiště konfigurace, zjišťování kontroly stavu a služeb sledování zařízení. Sajdkára také sleduje hostitelské prostředí a proces (nebo kontejner) nadřazené aplikace a protokoluje informace do centralizované služby.
  • Správa NGINX/HAProxy: Nasaďte NGINX se službou sajdkára, která sleduje stav prostředí, pak aktualizuje konfigurační soubor NGINX a pokud je nutná změna stavu, recykluje proces.
  • Sajdkára u služby ambasador: Nasazení služby ambasador formou sajdkáry. Aplikace provádí volání prostřednictvím služby ambasador, která zpracovává protokolování žádostí, směrování, přerušení obvodů a další funkce související s připojením.
  • Snižování zátěže proxy serveru: Pokud chcete zpracovat poskytování obsahu statického souboru službě, umístěte proxy server NGINX před instanci služby node.js.