Bevezetés a háromszintű architektúrába
A háromszintű architektúra a leggyakoribb interakciós architektúra az interneten. Akkor jelent meg, amikor a kétszintű szerverrészt két részre osztották: egy logikai rétegre és egy adatrétegre .
Valahogy így nézett ki:
A kliens réteg az "elosztott alkalmazás" része, amely a felhasználói interakcióért felelős. Ez a réteg nem tartalmazhat üzleti logikát, és nem tárolhat kritikus adatokat. Ezenkívül nem szabad kölcsönhatásba lépnie közvetlenül az adatbázisréteggel, hanem csak az üzleti logikai rétegen keresztül.
Itt azonban még mindig van némi logika. Először is, ez interakció a felhasználóval a felületen keresztül, az általa bevitt adatok érvényesítése, a helyi fájlokkal való munka. Ebbe beletartozik minden, ami a felhasználói jogosultsággal és az adatok titkosításával kapcsolatos a szerverrel való munka során.
Másodszor, ez egy egyszerű üzleti logika. Például, ha egy webáruház küldött egy listát a termékekről, akkor azokat az ügyféloldalon tudjuk rendezni és szűrni. És itt van a primitív adattárolás is: gyorsítótárazás, bejelentkezett felhasználói cookie-k és hasonlók.
Az üzleti logikai réteg a második szinten található, az üzleti logika nagy része erre koncentrálódik. Rajta kívül csak a kliensbe exportált töredékek, valamint az adatbázisba bemerült logikai elemek (tárolt eljárások és triggerek) maradnak.
Az üzleti logikai szerver egy nagy része nemcsak ugyanazt a logikát tartalmazza, hanem a skálázási problémákat is megoldja: a kódot részekre osztják és különböző szerverekre osztják szét. Egyes rendkívül igényes szolgáltatások több tucat szerveren is futhatnak. A köztük lévő terhelést a terheléselosztó kezeli.
A szerveralkalmazásokat általában úgy tervezik meg, hogy a szerver egy másik példánya könnyen elindítható és a többi példányával együttműködve elkezdhető működni. Ez azt jelenti, hogy még a kiszolgálókód írása során sem lesz garancia arra, hogy a statikus osztály egyetlen példányban elindul.
Az adatréteg adattárolást biztosít, és külön szinten van elhelyezve, rendszerint adatbázis-kezelő rendszerek (DBMS) segítségével valósítják meg, ehhez a komponenshez csak az alkalmazásszerver szintjéről biztosítanak kapcsolatot.
Az adatréteg szétválasztásának okai
Az adatréteg teljes értékű harmadik rétegre való szétválása több okból is megtörtént, de a fő oka a szerver megnövekedett terhelése.
Először is, az adatbázisok sok memóriát és processzoridőt igényeltek az adatfeldolgozáshoz. Ezért mindenhol külön szervereken kezdték elhelyezni.
A megnövekedett terhelés hatására a háttérrendszer könnyen duplikálható volt, és egy szerver tíz példánya is létrehozható volt, de az adatbázis sokszorosítása lehetetlen volt – az adatbázis továbbra is a rendszer egyetlen és oszthatatlan eleme maradt.
Másodszor, az adatbázisok okossá váltak – megvan a saját üzleti logikájuk. Elkezdték támogatni a tárolt eljárásokat, triggereket, saját nyelveiket, például a PLSQL-t. És még olyan programozók is megjelentek, akik elkezdtek olyan kódot írni, amely a DBMS-en belül fut.
Minden logikát, amely nem volt adatokhoz kötve, kikerült a háttérbe, és párhuzamosan több tucat szerveren elindították. Minden, ami kritikusan adathoz kötött, a DBMS-ben maradt, és ott már a megnövekedett terhelés problémáit saját módszereinkkel kellett megoldani:
- Az adatbázis-fürt adatbázis-kiszolgálók csoportja, amelyek ugyanazokat az adatokat tárolják, és egy adott protokoll segítségével szinkronizálják azokat.
- Sharding – az adatok logikai blokkokra oszlanak, és különböző adatbázis-kiszolgálók között vannak elosztva. Ezzel a megközelítéssel nagyon nehéz fenntartani az adatbázis-változásokat.
- A NoSQL megközelítés az adatok tárolása olyan adatbázisokban, amelyek hatalmas mennyiségű adat tárolására készültek. Ezek sokszor nem is adatbázisok, hanem konkrét fájltárolók. Nagyon gyenge funkcionalitás a relációs adatbázisokhoz képest.
- Adatgyorsítótár. Az egyszerű adatbázis szintű gyorsítótár helyett megjelent a teljes gyorsítótár DBMS, amely csak a memóriában tárolta az eredményt.
Nyilvánvaló, hogy külön emberekre és/vagy egész csapatokra volt szükség a szervertechnológiák állatkertjének kezeléséhez, ami az adatréteg külön rétegbe való eltávolításához vezetett.
Fontos! Minden fejlett technológia a nagy IT-vállalatok mélyén születik, amikor a régi megközelítések már nem tudnak megbirkózni az új kihívásokkal. Az adatbázisok külön réteggé alakítását nem bármelyik programozó találta ki, hanem egy mérnökcsoport valahol az Oracle vagy az IBM mélyén.
Érdekes! Amikor Zuckerberg elkezdte írni a Facebookot, egyszerűen PHP + MySQL-en dolgozott. Amikor több millió felhasználó volt, írtak egy speciális fordítót, amely az összes PHP kódot C ++ nyelvre fordította, és natív gépi kódra fordította.
Ezenkívül a MySQL nem képes több milliárd felhasználó adatait tárolni, ezért a Facebook kidolgozta a NoSQL adatbázisok koncepcióját, és megírt egy erős szerveroldali NoSQL DBMS-t - Cassandra. Egyébként teljesen Java nyelven van megírva.
Az alkalmazáslogikai hely kétértelműsége
És bár egy háromszintű architektúra szinte egyértelműen elosztja a szerepeket a részei között, nem mindig lehet pontosan meghatározni, hogy a rendszerben pontosan hol kell az üzleti logika új részét (új kódot) hozzáadni.
Az alábbi képen látható egy példa erre a kétértelműségre:
A szerver részt szürke háttérrel, a kliens részt fehérrel töltjük ki. Ez utóbbi megközelítésre (jobb szélen) jó példa a modern mobilalkalmazások. A kliens oldalon (a telefonon) található a nézet (megjelenítés), a logika és az adatok. És csak néha szinkronizálják ezeket az adatokat a szerverrel.
Példa a bal szélső opcióra egy tipikus PHP szerver, amely a szerveren minden logikát tartalmaz, és ez már statikus HTML-t ad a kliensnek. Valahol e két véglet között lesz a projekted.
A munka kezdetén, miután megismerkedett a projekttel, konzultálnia kell a rajta dolgozó programozókkal, hogy hol érdemes megvalósítani a következő feladat logikáját.
Nyugodtan tedd meg. Először is, nem másznak be valaki más kolostorába a chartájukkal. Másodszor, mindenki (és neked is) könnyebben megtalálja a szükséges kódot azon a helyen, ahol azt várod.
