Aspekty n-úrovňových architektur
Podívali jsme se, co tvoří N-vrstvou 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í.
Zaměstnanecké 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 našem ukázkovém prostředí, můžete použít služby PaaS nebo IaaS na libovolné ú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 do zatížení přidat další webové servery, aniž by to mělo vliv na 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 oddělená do vrstev, měli bychom izolovat každou vrstvu a povolit pouze potřebný 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 prostor pro útoky aplikace a zvýšíme jeho 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. Dodatečné úrovně přidávají uživateli složitost, dobu zpracování, latenci a nakonec zpoždění.
Vzhledem k tomu, že rozhraní API pro každou doménu na úrovni aplikace nejsou oddě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ášť. Úplné oddělení zahrnuje odebrání sdílených závislostí a větší závislost na volání rozhraní API mezi vrstvami. Po správném provedení se zajistí, že vaše nasazení aplikací budou flexibilní.
Aplikace v N-úrovňové architektuře se často nasazují 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čích rezidentní.
N-vrstvá je klasický styl architektury, ale v mnoha scénářích je nahrazen jinými moderními vzory návrhu, jako je architektura mikroslužeb. Často stojí za to nějakou dobu investovat do vyhodnocení jiných architektur, abyste zjistili, jestli jsou pro vaši aplikaci vhodnější.
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í, k přizpůsobení 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í toho, aby vaši uživatelé měli co nejlepší prostředí a aby vaše náklady zůstaly nízké. Škálovací sady virtuálních počítačů Azure je možné použít pro úlohy založené na virtuálních počítačích a mnoho služeb PaaS, jako je Aplikace Azure Služba, má integrované funkce 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. Při vyrovnávání zatížení se při přidávání dalších výpočetních prostředků do vrstvy přidají do distribuce nástroje pro vyrovnávání zatížení, aby využily další výpočetní výkon. Naopak když systém selže, odebere se z zatížení, aby se minimalizoval dopad uživatelů na nízký výkon nebo chybné požadavky. 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 vrstvami má pozitivní vliv na výkon, zejména na požadavky, které jsou asynchronní povahy. Služba umístí zprávu do fronty, kde zůstane, dokud se nezpracuje, a vypne dopad podřízeného zatížení. Pokud dojde k výpadku systému, služba zasílání zpráv zajistí, že se vaše zpráva bude dál zpracovávat. Zpráva zůstane ve frontě a zpracuje se po návratu systému do online režimu. 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í
Optimalizace aplikace pro zabezpečení je často úloha, která se nikdy neukončí. I když je aplikace oddělená do vrstev, stále musí existovat dobře plánované postupy zabezpečení, které byly do architektury vnořeny. Čím více úrovní přidáte, tím více potřebujete zabezpečit a tím více do systému zavedáte složitost. 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ě
Při spouštění N-úrovňové architektury na virtuálních počítačích se ujistěte, že každá vrstva je ve své vlastní podsíti. Tato podsíť funguje jako hranice zabezpečení, která umožňuje izolovat připojení prostřednictvím seznamů řízení přístupu k síti. Podsíť také usnadňuje správu tím, že zajišťuje, aby nové systémy v podsíti přijímaly stejná pravidla. V Azure se to provádí nativně se skupinami 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.
Firewall webových aplikací
S izolací zabezpečení mezi podsítěmi chcete zajistit, aby byl veřejně vystavený front-end zabezpečený a umožňoval přístup jenom k tomu, co je potřeba. Prezentační vrstvu byste měli zpřístupnit jenom příchozímu internetovému provozu. Technologie firewallu webových aplikací (WAF) před prezentační vrstvou vylepšuje zabezpečení na této úrovni. 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. Application Gateway je v Azure nástroj pro vyrovnávání zatížení HTTP, který má integrovaný WAF, který můžete povolit.