Model ambasador

Azure

Vytvoří služby pomocných rutin, které odesílají síťové požadavky jménem aplikace nebo služby uživatele. Službu ambasadoru si můžete představit jako mimoprocesové proxy umístěné společně s klientem.

Tento model může být užitečný pro snižování zátěže při běžných úlohách připojení klienta, jako jsou například monitorování, protokolování, směrování, zabezpečení (například TLS) a modely odolnosti, způsobem, který nezohledňuje jazyk. Často se používá se staršími aplikacemi nebo jinými aplikacemi, které se obtížně upravují, aby se rozšířily jejich síťové možnosti. Tyto funkce může také implementovat specializovaný tým.

Kontext a problém

Odolné cloudové aplikace vyžadují funkce, jako je například jištění, směrování, měření a monitorování a schopnost provádět aktualizace konfigurace související se sítí. Aktualizovat starší verze aplikací nebo existující knihovny kódu za účelem přidání těchto funkcí může být obtížné nebo nemožné, protože kód se již neudržuje nebo ho vývojový tým nemůže snadno upravit.

Volání sítě mohou také vyžadovat delší konfiguraci připojení, ověření a autorizace. Pokud se tato volání používají napříč více aplikacemi, vytvářejí pomocí více jazyků a rozhraní, musí se nakonfigurovat pro každou z těchto instancí. Funkce sítě a zabezpečení může být navíc nutné spravovat centrálním týmem uvnitř vaší organizace. Vzhledem k velikosti základu kódu může být pro tým aktualizace kódu aplikace, který neznají, rizikem.

Řešení

Umístěte klientská rozhraní a knihovny do externího procesu, který funguje jako proxy mezi vaší aplikací a externími službami. Nasaďte proxy do stejného hostitelského prostředí jako vaši aplikaci, abyste umožnili řízení směrování, odolnosti, funkcí zabezpečení a vyhnuli se jakýmkoli hostitelským omezením přístupu. Model ambasador můžete také použít ke standardizaci a rozšíření instrumentace. Proxy může monitorovat metriky výkonu, jako je třeba latence nebo využití prostředků. K tomuto monitorování bude docházet ve stejném hostitelském prostředí, ve kterém je aplikace.

Diagram vzoru ambasadora

Funkce, které přebírá ambasador, můžou být spravovány nezávisle na aplikaci. Model ambasador můžete aktualizovat a upravovat, aniž byste narušili funkce starší verze aplikace. Umožňuje také, aby funkce zabezpečení, sítě nebo autorizace přesunuté do modelu ambasador mohly být implementovány a udržovány samostatnými specializovanými týmy.

Služby ambasador můžete nasadit jako sajdkáru, která bude provázet životní cyklus používání aplikace nebo služby. Pokud se ambasador sdílí několika samostatnými procesy na společném hostiteli, můžete ho také nasadit jako proces démon nebo službu Windows. Pokud je používaná služba kontejnerizovaná, měl by se ambasador vytvořit jako samostatný kontejner na stejném hostiteli s odpovídajícími propojeními nakonfigurovanými pro komunikaci.

Problémy a důležité informace

  • Proxy přidává režijní náklady na latenci. Zvažte, jestli není lepším řešením klientská knihovna vyvolaná přímo aplikací.
  • Vezměte v úvahu případný dopad zahrnutí zobecněných funkcí v proxy serveru. Ambasador by například mohl zpracovat opakování, což by ale nebylo bezpečné, pokud by všechny operace nepoužívaly sekvenci idempotent.
  • Zvažte mechanismus, který klientovi umožní předat určitý kontext proxy serveru a zpět klientovi. Zahrňte například hlavičky požadavků HTTP za účelem vyjádření nesouhlasu, opakování nebo určení maximálního počtu opakování.
  • Zvažte, jak zabalíte a nasadíte proxy server.
  • Zvažte, jestli chcete použít jednu sdílenou instanci pro všechny klienty nebo jednu instanci pro každého klienta.

Kdy se má tento model použít

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

  • Potřebujete vytvořit společnou sadu funkcí připojení klienta pro více jazyků nebo rozhraní.
  • Potřebujete přesunout obecně se vyskytující aspekty připojení klienta na vývojáře infrastruktury nebo jiné více specializované týmy.
  • Potřebujete podpořit požadavky na připojení cloudu nebo clusteru ve starší verzi aplikace nebo aplikaci, kterou je obtížné upravit.

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

  • Pokud je latence síťového požadavku kritická. Proxy představuje určitou režii, i když je minimální a v některých případech to může mít vliv na aplikaci.
  • Pokud jsou funkce připojení klienta přijímána jedním jazykem. V takovém případě je možná lepší možností klientská knihovna, která se vývojovým týmům distribuuje ve formě balíčku.
  • Pokud se funkce připojení nedají zobecnit a vyžadovat hlubší integraci s klientskou aplikací.

Návrh úloh

Architekt by měl vyhodnotit způsob použití vzoru ambasadora 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 spolehlivosti pomáhají vaší úloze stát se odolnou proti selhání a zajistit, aby se po selhání obnovila do plně funkčního stavu. Bod mediace síťové komunikace, který tento model usnadňuje, poskytuje příležitost přidat do síťové komunikace vzory spolehlivosti, jako je opakování nebo ukládání do vyrovnávací paměti.

- RE:07 Sebezáchování
Rozhodnutí o návrhu zabezpečení pomáhají zajistit důvěrnost, integritu a dostupnost dat a systémů vaší úlohy. Tento model poskytuje příležitost k rozšíření zabezpečení síťové komunikace, kterou klient nemohl zpracovat přímo.

- SE:06 Řízení sítě
- SE:07 Šifrování

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

Následující diagram znázorňuje aplikaci vytvářející požadavek na vzdálenou službu prostřednictvím proxy ambasadora. Ambasador poskytuje směrování, jištění a protokolování. Volá vzdálenou službu a pak vrací odpověď klientské aplikaci:

Příklad vzoru Ambasador