Aspekty n-úrovňových architektur

• 7 min

Podívali jsme se na to, co tvoří n-úrovňovou architekturu, a nasadili jsme příklad třívrstvé architektury. Teď si pojďme přiblížit některé z jejich výhod i problémů a ukázat osvědčené postupy, které zajistí jejich optimální výkon a zabezpečení.

Výhody

Výhody architektury tohoto stylu tkví v její jednoduchosti. Její schéma je hojně využívané a dobře definované jak pro místní, tak i cloudová nasazení, a lze ji použít u řady nejrůznějších aplikací.

Tato architektura není závislá na konkrétní platformě a dobře funguje s aplikacemi nasazenými ve Windows i v Linuxu. Jak jsme si ukázali v ukázkovém prostředí, služby PaaS nebo IaaS lze využívat na jakékoli úrovni.

Díky rozdělení aplikace na úrovně lze každou z těchto úrovní škálovat, aktualizovat nebo upgradovat nezávisle. Pokud se požadavky na náš web zvýší, můžeme k zatížení přidat další webové servery, aniž by to ovlivnilo ostatní úrovně. Stejným způsobem můžeme s vyšším počtem požadavků proti datové vrstvě provést škálování databáze, abychom získali pro jejich zpracování větší kapacitu.

Přirozeným vedlejším produktem architektury tohoto stylu je oddělení sítě. Vzhledem k tomu, že je aplikace rozdělená do vrstev, měli bychom každou úroveň izolovat a povolit pouze nezbytný síťový přístup. Prezentační vrstva může být přístupná z internetu, ale databáze – stejně jako funkce aplikace – může být plně zabezpečená za několika síťovými úrovněmi. Zabezpečením síťového přístupu mezi vrstvami snížíme úroveň útoku na aplikaci a zvýšíme její zabezpečení.

Problémy a důležité aspekty

Když rozdělíte aplikaci do několika úrovní, mějte na paměti, že střední úrovně nemají provádět jen databázové operace. Každá úroveň by měla přinášet konkrétní hodnotu. Další úrovně přidávají složitost, dobu zpracování, latenci a nakonec zpoždí uživatele.

Vzhledem k tomu, že rozhraní API pro každou doménu na úrovni aplikace nejsou rozdělená do jednotlivých služeb, musí se škálovat společně. Pokud jedna aplikační metoda vyžaduje více výpočetního výkonu nebo zpracovává větší počet požadavků než jiné, je potřeba škálovat aplikační úroveň jako celek pro danou zátěž, nikoliv jako jednu službu.

V některých případech můžete vytvořit aplikaci s n-úrovňovou architekturou, ale současně provádět nasazení v jednom bloku. Pokud jednotlivé úrovně zcela oddělíte, byste měli každou z nich nasazovat zvlášť. To obnáší odebrání sdílených závislostí a větší význam volání rozhraní API mezi úrovněmi. Správně provedené oddělení je ale zárukou flexibility nasazení vaší aplikace.

Aplikace v n-úrovňové architektuře se často nasazovat na virtuální počítače. To je dobrý první krok. Vývoj aplikace tak, aby využívala služby PaaS, ale přináší i řadu výhod v oblasti zabezpečení, škálovatelnosti a správy. Tento vývoj se často přehlíží a n-úrovňové architektury zůstávají na virtuálních počítači.

I když n-úrovňová architektura představuje klasický styl architektury, byla v mnoha scénářích nahrazena jinými moderními způsoby návrhu, jako je například architektura mikroslužeb. Často se vyplatí věnovat čas zhodnocení ostatních architektur pro případ, že by pro vaši aplikaci byly lepší volbou.

Osvědčené postupy pro n-úrovňové architektury

Pokud si chcete být jistí, že vaše n-úrovňová architektura bude fungovat nejlepším možným způsobem, je potřeba udělat několik věcí. Následující diagram znázorňuje možnosti vylepšení těchto architektur.

Optimalizace výkonu

Pojďme se podívat, jak lze u n-úrovňové architektury dosáhnout optimálního výkonu a zabezpečení.

Automatické škálování

Když je aplikace rozdělená na úrovně, můžeme použít cloudové funkce, jako je automatické škálování, a přizpůsobit se zatížení systému. S vyšším počtem uživatelů nebo požadavků lze pomocí automatického škálování na více úrovních přidávat další prostředky, které požadavky zpracují. Pokud počet požadavků poklesne, automatické škálování omezí výpočetní prostředky, čímž se také sníží vaše náklady. Automatické škálování usnadňuje zajištění nejlepšího prostředí pro uživatele a nízké náklady. Azure Virtual Machine Scale Sets lze použít pro úlohy založené na virtuálních počítačech a řada služeb PaaS, jako je Azure App Service, má integrované možnosti automatického škálování.

Vyrovnávání zatížení

Při škálování aplikace pomocí funkce automatického škálování se vyrovnávání zatížení stává nezbytnou součástí vaší architektury. Jeho princip je následující – když do vrstvy přidáte další výpočetní prostředky, přidají se do distribuce nástroje pro vyrovnávání zatížení, kde využívají dodatečný výpočetní výkon. Pokud naopak dojde k selhání systému, dojde k jeho odebrání ze zatížení, aby se minimalizoval dopad na uživatele díky špatnému výkonu nebo chybným požadavkům. Tím je zajištěno, že požadavky uživatelů budou do systému přicházet v dobrém stavu. Nástroj pro vyrovnávání zatížení Azure je integrovaná funkce možností sítě, Application Gateway pak nabízí řešení pro vyrovnávání zatížení HTTP s ještě větším množstvím funkcí.

Zasílání zpráv

Použití služby zasílání zpráv mezi úrovněmi má pozitivní dopad na výkon, zejména na požadavky, které jsou ze své podstaty asynchronní. Zpráva se umístí do fronty, kde zůstane, dokud se nezpracuje, a tím se vynuluje dopad podřízeného zatížení. Kromě toho je zajištěno, že zpráva bude zpracována i v případě výpadku systému. Zůstane ve frontě a zpracuje se, až bude systém zase online. V Azure si můžete vybrat z několika řešení pro zasílání zpráv podle vašich potřeb. Zmínit lze například služby Azure Service Bus, fronty služby Azure Storage nebo Azure Event Hubs.

Ukládání dat do mezipaměti

Ukládání do mezipaměti se využívá u často používaných dat s nízkou frekvencí změn nebo u dat s krátkodobou platností (například stav relace). Systémy pro ukládání do mezipaměti se nacházejí mezi vrstvami a zkracují u těchto dat dobu načítání. Pro tento scénář se skvěle hodí služba PaaS Azure Cache for Redis.

Optimalizace zabezpečení

Při optimalizaci zabezpečení se často jedná o úlohu, která se nikdy "nedokonal". I když je aplikace rozdělená na úrovně, musí být součástí architektury i dobře naplánované postupy zabezpečení. S větším počtem přidaných úrovní roste i nutnost zabezpečení, stejně jako složitost celého systému. Abyste měli jistotu, že vaše architektura představuje bezpečné prostředí pro aplikaci, je potřeba udělat několik věcí.

Izolace sítě

U n-úrovňové architektury spuštěné na virtuálních počítačích se ujistěte, že se každá úroveň nachází ve vlastní podsíti. Tato podsíť funguje jako hranice zabezpečení a umožňuje izolovat připojení prostřednictvím seznamů řízení přístupu k síti, ale usnadnění správy tím, že zajišťuje, aby nové systémy v podsíti obdržely stejná pravidla. V Azure se to provádí nativně pomocí skupin zabezpečení sítě (NSG). Stejné aspekty bychom měli vzít v úvahu i u služeb PaaS. Možnosti integrace sítě se ale u nich liší a měly by být posuzovány samostatně. Obecně se doporučuje zajistit, aby každá úroveň směla komunikovat jen s úrovní bezprostředně pod sebou. Prezentační úroveň by měla komunikovat jen s aplikační úrovní a aplikační úroveň s datovou úrovní. Taková minimalizace připojování představuje vícevrstvý přístup k zabezpečení sítě a zvyšuje celkový stav zabezpečení architektury.

Brána firewall webových aplikací

Když máte nastavenou bezpečnostní izolaci mezi podsítěmi, chcete zajistit, aby byl veřejně zveřejněný front-end zabezpečený a aby byl zajištěný přístup pouze k tomu, co je potřeba. Příchozí internetové komunikaci by měla být přístupná jen prezentační vrstva. Pro zvýšení jejího zabezpečení můžete použít bránu firewall webových aplikací (WAF), která se umísťuje právě před tuto vrstvu. Brány firewall webových aplikací kontrolují potenciální škodlivé aktivity během provozu, zajišťují, že komunikace je šifrovaná, a upozorňují vás, je-li něco v nepořádku. V Azure Application Gateway nástroj pro vyrovnávání zatížení HTTP s integrovaným WAF, který můžete povolit.

Zkontrolujte své znalosti