Model Snižování zátěže pomocí brány

Přesměrovává zpracování sdílených nebo specializovaných funkcí služby na proxy brány. Tento model může zjednodušit vývoj aplikací přesunutím funkce sdílené služby, třeba používání certifikátů SSL, z jiných částí aplikace na bránu.

Kontext a problém

Některé funkce se běžně používají ve více službách a tyto funkce vyžadují konfiguraci, správu a údržbu. Sdílená nebo specializovaná služba, která se distribuuje s každým nasazením aplikace, zvyšuje administrativní zátěž a pravděpodobnost chyby nasazení. Jakékoli aktualizace sdílené funkce se musí nasadit ve všech službách, které funkci sdílejí.

Správné zpracování záležitostí zabezpečení (ověřování tokenů, šifrování, správa certifikátů SSL) a další složité úlohy můžou vyžadovat, aby členové týmu měli vysoce specializované znalosti. Například certifikát vyžadovaný aplikací musí být nakonfigurovaný a nasazený ve všech instancích aplikace. Certifikát se musí spravovat s každým novým nasazením, aby se zajistilo, že nevyprší jeho platnost. Všechny běžné certifikáty, kterým se blíží vypršení, se u každého nasazení aplikace musí aktualizovat, otestovat a ověřit.

Další běžné služby jako ověřování, autorizace, protokolování, monitorování nebo omezování využití sítě můžou být náročné z hlediska implementace a správy v rámci velkého počtu nasazení. Může být lepší tento typ funkcí konsolidovat, aby se snížila zátěž a riziko chyb.

Řešení

Přesměrovává některé funkce do brány, zejména aspekty křížového zpracování, jako je správa certifikátů, ověřování, ukončení protokolu SSL, monitorování, překlad protokolů nebo omezování.

Následující diagram znázorňuje bránu, která ukončuje příchozí připojení SSL. Požaduje data jménem původního žadatele z jakéhokoli nadřazeného serveru HTTP brány.

K výhodám tohoto modelu patří:

• Můžete zjednodušit vývoj služeb odstraněním potřeby distribuovat a spravovat podpůrné prostředky, jako jsou certifikáty webových serverů a konfigurace pro zabezpečené weby. Jednodušší konfigurace vede k jednodušší správě a škálovatelnosti a zjednodušuje upgradování služeb.

• Implementaci funkcí, které vyžadují specializované znalosti, třeba zabezpečení, můžete svěřit vyhrazeným týmům. Hlavní tým se tak může zaměřit na fungování aplikace a tyto specializované záležitosti, které mají vliv na ostatní funkce, přenechat relevantním odborníkům.

• Umožňuje zajistit do určité míry konzistentní protokolování a monitorování žádostí a odpovědí. I v případě, že služba není správně instrumentovaná, může se brána nakonfigurovat, aby se zajistila minimální úroveň monitorování a protokolování.

Problémy a důležité informace

• Ujistěte se, že je brána vysoce dostupná a odolná vůči selhání. Vyhněte se kritickým bodům selhání spuštěním několika instancí brány.
• Ujistěte se, že je brána navržená pro požadavky na kapacitu a škálování vaší aplikace a koncových bodů. Zajistěte, aby se brána nestala kritickým bodem pro aplikaci a byla dostatečně škálovatelná.
• Přesměrovávejte jenom funkce, které jsou používané celou aplikací, například zabezpečení nebo přenos dat.
• Obchodní logika by se nikdy neměla přesměrovávat na bránu.
• Pokud potřebujete sledovat transakce, zvažte generování ID korelace pro účely protokolování.

Kdy se má tento model použít

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

• Nasazení aplikace má sdílenou funkci, třeba certifikáty SSL nebo šifrování.
• Funkce, která je společná pro nasazení aplikací, které můžou mít různé požadavky na prostředky, jako jsou paměťové prostředky, kapacita úložiště nebo připojení k síti
• Chcete odpovědnost za otázky, jako je zabezpečení sítě, omezení využití sítě nebo jiné záležitosti ohraničení sítě, přesunout na specializovanější tým.

Tento model nemusí být vhodný, pokud by zaváděl párování napříč službami.

Návrh úloh

Architekt by měl vyhodnotit, jak se dá model snižování zátěže brány použít v návrhu úloh k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:

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í konfigurace pomocí Nginx jako zařízení pro snižování zátěže SSL ukončí příchozí připojení SSL a distribuuje připojení na jeden ze tří nadřazených serverů HTTP.

upstream iis {
        server  10.3.0.10    max_fails=3    fail_timeout=15s;
        server  10.3.0.20    max_fails=3    fail_timeout=15s;
        server  10.3.0.30    max_fails=3    fail_timeout=15s;
}

server {
        listen 443;
        ssl on;
        ssl_certificate /etc/nginx/ssl/domain.cer;
        ssl_certificate_key /etc/nginx/ssl/domain.key;

        location / {
                set $targ iis;
                proxy_pass http://$targ;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header Host $host;
        }
}

V Azure toho můžete dosáhnout nastavením ukončení protokolu SSL ve službě Application Gateway.

Související prostředky

• Model Back-endy pro front-endy
• Model Agregace pomocí brány
• Model Směrování prostřednictvím brány