Vállalati rendszerek architektúra mintái - Enterprise tervezési minták (cache, pooling, MVC, MVVM, session facade, DTO, transformer, business delegate) Flashcards
Elosztott alkalmazások
Cél az architektúránál: híd az üzleti és a technikai követelmények között.
Identifikáljuk a követelményeket, melyek az alkalmazást struktúráját befolyásolják . Azt a kockázatot szeretnénk csökkenteni, amit az üzleti követelmények változói jelenthetnek. Olyan szempontok melyeket később nehéz megváltoztatni (pl nyelv).
Funkcionális mellett minőségi követelményeket is teszünk.
A szoftver rendszer struktúrája számít, fontos és a struktúra helyesség kritikus.
Az elosztott architektúra különböző szintjei
Az architektúra az egyes komponensek struktúrájáról, kapcsolatáról beszé
Elosztott alkalmazások architektúra fejlődése
● Mainframe: idő osztásban egymás után (egy gép, mindenki azt használja).
● Mindenkinek saját PC, alkalmazások feltelepítése
● Kliens-szerver: több réteges rendszereknél, PC-k összekötése hálózaton keresztül
● Felhő: elosztott rendszereknél.
Kihívások webes környezetnél
Webes környezetnél sok kliens és egy, vagy több szerver van.
Kihívások webes környezetknél:
● Deployment (Telepítés): a rendszer frissítések ne okozzanak leállást vagy zavart a szolgáltatásokban.
● Session handling (Munkamenet kezelés): a munkamenet információkat hatékonyan kell kezelni, és esetenként terheléselosztásra is szükség lehet.
● Load balancing (Terheléselosztás)
● Security (Biztonság)
● Failover (Hibatűrés): a rendszer képes legyen folyamatosan működni, még akkor is, ha egyes részei meghibásodnak. Enterprise környezetekben fontos a redundancia és az automatikus hibaelhárítás, hogy minimalizáljuk a szolgáltatások leállását.
● Time synchronization (Idő szinkronizáció)
Az elosztott alkalmazások sok-sok rendszerrel működnek együtt.
Szoros csatolás helyett laza csatolást alkalmazunk a komponensek között. Interfacen keresztül távoli eljáráshívás történik. Hálózati kapcsolaton keresztül kommunikálnak, ezért a teljesítmény ettől is fog függeni. Ez azonban biztonsági rés, mivel hálózaton keresztül le lehet hallgatni a kommunikációt, erre figyelnünk kell (teljesítménybe kerül). Az átküldött paramétereket nem tudjuk módosítani.
Lehetnek esetek, amikor egyik komponens nem éri el a másikat, ilyenkor mi történjen? Programozás is más, mivel a paramétereket át kell vinni a hálózaton, nem tudjuk őket egyszerűen módosítani.
Klaszterek
egy szolgáltatásként tekintünk több gépre, ezzel a rendszer teljesítményét tudjuk növelni: a kapacitását, a rendelkezésre állása javul, valamint olcsóbb lesz. Sokkal jobb több kisebb szervergép mint egy nagy, sokkal költséghatékonyabb. Ha valamit cserélni szeretnénk az egyik gépben működni fog továbbra is a szolgáltatás. Ezeket a rendszereket menedzselni kell, a gépeket konfigurálni kell: ezt tudjuk automatizálni. Ezek a gépek általában virtuális gépek távoli adatközpontban, amit mi tudunk menedzselni. A futtató környezetet konfigurálni kell.
Munkafolyamatok
futtató környezetet konfigurálni kell.
Törődni kell a munkafolyamatokkal is. Hol helyezzük el őket? Cookieba, URL paraméterbe, https alapból képes követni.
Több módja van a munkafolyamat megtartásának:
1. Sticky session: Ha az első kérés pl a “B” szerverre érkezett akkor az összes további kérést is oda fogjuk irányítani. Ehhez a load balancernek extra munkát kell végezni. Ha meghibásodik a source server akkor oda a munkafolyamat. Nem skálázható nagyon sok szerver esetén.
2. A sessionöket közös adattárba (SQL) helyezzük, ez sebességben rosszabb lehet.
3. Tárolhatjuk memóriában is őket, több kiszolgálón is, lehet all-to-all (minden sessionnek minden kiszolgálón meg kell lennie (load balancer bárhova küldheti a kérést, de rosszul skálázható)), vagy csak egy két helyen (limited session replication, minden egyes server gondoskodik arról hogy a saját és egy másik session-jét eltárolja, ha a server kiesik akkor a load balancer átirányítja a sessiont másik serverre) .
Telepítésre módszerek
Telepítésnél cél, hogy az ügyfelek ne vegyék észre, a munkafolyamatokat is meg kell tartanunk. Erre több módszer is van:
● Párhuzamos telepítés: minden csomópontra több verziót telepítünk fel, az új felhasználók az újat, régiek a régit használják.
● Load balancer: csomópontokon megvan, hogy merre milyen verzió van. Klienseket megfelelő helyre irányítjuk, szép lassan kivesszük a régi verziót. Hátránya, hogy új verziónál több csomópont kell.
Mi történik, ha kiesik egy szolgáltató?
Failover-nél is cselekednünk kell, hogy mi legyen? Mi történik ha kiesik egy szolgáltató?
Kell a munkafolyamat is, hogy ne vegyék észre a felhasználók, mikor átküldjük egy másikra. Az infrastruktúrát monitorozni kell, illetve legyen szabad számítási kapacitásunk is. Ha megszakad két csomópont közt a kommunikáció, magukhoz lehet hívni az összes kérést, ezt is kezelni kell.
Layer and tier
: layer a szoftveres, tier a fizikai szervezés.
Kezdetben monolitikus architektúrák voltak, minden egyben leképezve. Kétrétegű rendszereknél külön van az üzleti logika és az adatbázis.
Layer and tier problémák
Problémák itt:
* Az egyre bonyolultabb üzleti logikát nehéz karbantartani
* UI szoros kapcsolatban van az üzleti logikával, ami nem jó: sok ismétlődés, kód duplikáció lehet
* A logika adatbázisban tárolása sem jó, biztonsági rést okoz
* Teljesítmény problémák is felléphetnek:
* Megjelenítésbe épülnek be sql lekérdezések
* Réteges alkalmazásoknál a UI külön van az üzleti logikától
* A UI-ban minden szerepel, amit a külső feleknek jelenítünk meg
* Üzleti logikába kalkuláció, validáció, parancsok feldolgozása történik, ez alatt szerepel még az adatfeldolgozó réteg.
* Vannak további rétegek is:
* Application réteg: technológia specifikus dolgokkal foglalkozik, üzleti és megjelenítési réteg közt szerepel
* Adatelérési réteg: üzleti és adatbázis réteg közt van, ha fontos az adatszervezés, vagy a kulcsban egy fontos adat is megjelenik. Nem akarjuk, hogy ez a kulcs kihasson az üzleti logikára
A vertikális rétegek olyan rétegek, melyek több szinten is megjelenhetnek. pl cacheles, logolás, tranzakciók, több rétegben is megjelennek, nem tudjuk őket egyhez kötni. A validáció is fontos, általában az üzleti logikában fordul elő, de több rétegben is megjelenhet. Fontos, hogy kliens és szerveroldalon is validáljunk! Kevés hiba üzenettel dolgozzunk, inkább ne engedjünk valamit, mint hogy hiba üzeneteket dobáljunk.
Enterprise tervezési minták
- MVC
- MVM
- Session facade
- Data Transfer Object (DTO)
- Data Access Object
- Business Delegate
- Transformer
- Cache
MVC
Szét akarjuk választani a modellt és a megjelenítést. Controllerekbe plusz felelősséget szervezünk ki. Observer mintát követve a Controller összeköti a Model-t és View-t. A Controller küldhet parancsokat a Modelnek és ezután firssíthető a megjelenítést, vagy a View kérdezi a Controllert, hogy volt-e változás időnként. MVCnek van több változata is. Az MVP-ben minden megjelenítési logika a Presenterben van, nincs közvetlen kapcsolat a Model és a View között.
MVVM
Adatkötéssel dolgozik a komponensek és a modellek között. Előnye az azonnali frissítés, viszont cserébe teljesítmény terén visszaesés lehet nagy View-oknál. Felhasználás: Android, Angular, WPF.
Session facade
Lazán csatolt komponensek, implementációt könnyen lehet cserélni, rétegek közötti kommunikációt segíti elő. Interakciót kell megvalósítani, magasszintű hozzáférést biztosít a szolgáltatáshoz, nem definiálunk új funkciókat, single responsiblility, nevével is utaljunk rá, hogy facade. Megoldást jelent a szoros csatolásra. Kliens és üzleti logika közötti függőség elkerülése. Az objektumainkat helyesen fogják használni. A kliens számára elérhetővé teszi a funkciókat. Tranzakciós határként is használhatjuk(@Transaction annotáció, ezután üzleti logika). Jó a többrétegű alkalmazásoknál, deklaratív biztonság és cache management.
Data Transfer Object (DTO)
Egy adathordozó osztály, csoportosítjuk az összetartozó értékeket (pl egy képernyőhöz tartozókat). DTO nem rendszer specifikus osztály, csak adat továbbításra van. Minden szükséges adatot csomagoljunk össze(egy DTO/képernyő megjelenítéshez)! Sorosítási mechanizmus eltárolása az adat továbbításában. Nem tartalmazhat tesztelést igénylő logikát.
