Kliens-szerver architektúra

1.1 Alkalmazás architektúra

Ez a tanfolyam kezdőknek készült, mert nem sokáig fogsz egy komoly alkalmazás architektúráját tervezni. De ne aggódj, a jó építészet inkább kivétel, mint szabály. Nagyon nehéz kiválasztani a megfelelő alkalmazás architektúrát az alkalmazás elkészítése előtt .

Példák népszerű architektúrákra nagy szerveralkalmazásokhoz:

• Réteges építészet (Layered Architecture).
• Többszintű építészet.
• Szolgáltatásorientált architektúra (SOA).
• Microservice architektúra (Microservice Architecture).

Mindegyiknek megvannak a maga előnyei és hátrányai. De ezek tanulmányozása nem ad semmit. Az architektúra a válasz arra a kérdésre, hogy "hogyan lehet megszervezni több ezer objektum interakcióját a rendszeren belül" . És amíg nem tapasztalja meg a probléma teljes összetettségét, nem fogja tudni megérteni a megoldás teljes sokoldalúságát.

Minden alkalmazás valamilyen architektúrát használ, vagy legalábbis úgy tesz, mintha azt tenné. Ezért az alkalmazástervezés népszerű megközelítéseinek ismerete lehetővé teszi az alkalmazás működésének gyors és jobb megértését. Ez pedig azt jelenti, hogy pontosan ott kell változtatásokat végrehajtani, ahol szükség van rájuk.

Mit jelent a „módosítások végrehajtása, ahol szükséges”? Vannak helyek, ahol nem kell változtatni? Pontosan.

Pontosabban, tegyük fel, hogy egy közepes háttérprojekten dolgozik . 5 éve írta egy 20 fős csapat. A projekt 100 emberévet vett igénybe, és körülbelül 100 ezer kódsort tartalmaz. Összesen kétezer osztályból áll, amelyek 10 különböző méretű modulra vannak felosztva.

És adjunk hozzá egy durva valóságot. Egyes feladatok logikája több modulra oszlik. Ezenkívül az üzleti logika lehet a frontendben (JavaScriptben írva) és / vagy tárolt eljárásként írható közvetlenül az adatbázisban. Még mindig biztos abban, hogy azonnal meghatározhatja a változtatások pontos helyét ?

Ez nem valami rémálom, amit kitaláltam, hogy megijesztessem. Ez egy tipikus projekt. Még rosszabb is előfordul. Miért történik ez? Számos oka lehet, de szinte mindig vannak ilyenek:

• Sokan dolgoznak a projekten – mindegyikük egy kicsit másképp látja.
• 5 éve 10 ember változott a projektben, az újoncok nem nagyon értették.
• A szoftverek létrehozása folyamatos változtatásokat jelent, amelyek folyamatosan mindent megváltoztatnak.
• Öt évvel ezelőtt, amikor az építészet mellett döntöttünk, a projekt ötlete némileg más volt.

De a legfontosabb dolog az, hogy a projekt architektúrájától függetlenül az összes programozó, aki azon dolgozik, ugyanazt a felfogást tartotta a projekt működéséről. Kezdjük a legegyszerűbb koncepcióval - a kliens-szerver architektúrával.

1.2 A kliens-szerver interakció fogalma

Most megértjük a kliens-szerver architektúra alapjául szolgáló koncepciót , és lehetővé teszi, hogy jobban megértse, hogyan szerveződik az interneten található programok millióinak interakciója.

Ahogy a név is sugallja, ez a fogalom két felet foglal magában: a klienst és a szervert . Itt minden olyan, mint az életben: a kliens ennek vagy annak a szolgáltatásnak az ügyfele, a szerver pedig a szolgáltató. A kliens és a szerver fizikailag programok , például egy tipikus kliens egy böngésző .

A következő példák megadhatók szerverként:

• Webszerverek, például a Tomcat.
• Adatbázis-kiszolgálók, például a MySQL.
• Fizetési átjárók, mint például a Stripe.

A kliens és a szerver általában az interneten keresztül kommunikál egymással (bár működhetnek ugyanabban a helyi hálózatban és általában bármilyen más típusú hálózatban). A kommunikáció szabványos protokollokon (például HTTP, FTP) vagy alacsonyabb szintű protokollokon (például TCP vagy UDP) keresztül történik.

A protokollt általában a szerverek által nyújtott szolgáltatás típusának megfelelően választják ki. Például, ha ez egy videohívás, akkor általában UDP-t használnak.

Emlékszel a Tomcat és szervletek működésére? A szerver kap egy HTTP üzenetet, kicsomagolja, onnan kivonja az összes szükséges információt és továbbítja a servletnek feldolgozásra. Ezután a feldolgozás eredményét visszacsomagolják egy HTTP-válaszba, és elküldik az ügyfélnek.

Ez a tipikus kliens-szerver interakció. A böngésző a webkliens, a Tomcat pedig a webszerver. A Tomcat webszervernek is nevezik.

De ha jobban belegondolunk, nem a név a fontos, hanem a lényeg - a szereposztás a programok között. A HTML oldalon futó JS-szkriptet kliensnek , a szervletet pedig szervernek nevezhetjük . Hiszen párban dolgoznak a kliens-szerver koncepció keretein belül .

1.3 Fontos árnyalat

Azt is érdemes megjegyezni, hogy a kliens-szerver interakció azon az elven alapul, hogy az interakciót a kliens kezdeményezi : a szerver csak válaszol a kliensnek, és jelenti, hogy tudja-e nyújtani a szolgáltatást az ügyfélnek, és ha igen, milyen feltételekkel. .

Nem számít, hol található fizikailag a kliens és hol a szerver. Az ügyfélszoftver és a szerverszoftver általában különböző gépekre van telepítve, de futhatnak ugyanazon a számítógépen is.

Ezt a koncepciót egy összetett rendszer egyszerűsítése felé tett első lépésként dolgozták ki. A következő erősségei vannak:

• Logikai egyszerűsítés : a szerver nem tud semmit a kliensről és arról, hogy hogyan fogja használni az adatait a jövőben.
• Lehetnek gyenge kliensek : minden erőforrásigényes feladat átvihető a szerverre.
• Klienskód és szerverkód önálló fejlesztése.
• Sok különböző kliens, például Tomcat és különböző böngészők.

A kliens és a szerver közötti interakció legalapvetőbb verziója a képen látható:

Itt fontos megjegyezni két részletet. Először is, a képen látható, hogy sok kliens hozzáférhet egy szerverhez. Másodszor, egyszerre érhetik el. Ez is fontos része a szervernek.

Egy kliens általában egy felhasználóval kommunikál, így ott gyakran nincs szükség engedélyre. A szerver azonban több ezer kliens kéréseit dolgozza fel, és a kód fejlesztésekor meg kell tudni különböztetni az engedélyezést és a hitelesítést.

Az is fontos, hogy a szerver több ezer kérést dolgozzon fel párhuzamosan. Ez pedig azt jelenti, hogy a háttérkód fejlesztése során folyamatosan gondolnia kell az erőforrásokhoz való párhuzamos hozzáférés feladatára. Ezenkívül a szerverkódnak nagyon nagy a valószínűsége a versenyfeltételeknek (szálverseny), a holtpontnak (a szálak kölcsönös blokkolása).

A fontos tárgyak életciklusát figyelemmel kell kísérni:

Nem indíthat egyszerűen új szálat a szerveren keresztül new Thread().start(). Ehelyett szüksége van egy ThreadPool-ra, amely megosztja az összes szolgáltatási szálat.

Ezenkívül nem lehet csak úgy elindítani egy aszinkron feladatot, mert ezek külön szálban is végrehajtódnak. Egy ilyen feladat létrehozásakor mindig tudnia kell, hogy melyik szálkészlet hajtja végre, és mi történik, ha egy ilyen készlet túlcsordul.

A fájlokkal és könyvtárakkal kapcsolatos minden munkát az erőforrásokkal való próbálkozáson keresztül kell elvégezni. Ha egy normál alkalmazásban elfelejtett bezárni egy adatfolyamot vagy fájlt, az probléma? Bezárul, amikor kilép a programból. De ha elfelejtett bezárni egy fájlt a szerveren valahol a kódban, és a szervere hónapok óta fut... Hamarosan több ezer ilyen le nem zárt fájl fog felhalmozódni, és az operációs rendszer leállítja az új fájlok megnyitását olvasásra (munka a fájlokkal). az operációs rendszer vezérli). A csapatvezető nem veregeti meg a fejét...

1.4 Kliens-szerver architektúra

még egy fontos szempont. A kliens-szerver architektúra csak a számítógépek közötti interakció általános elveit határozza meg , az interakció részleteit különböző protokollok határozzák meg.

Ez a koncepció (kliens-szerver) azt mondja nekünk, hogy a hálózaton lévő gépeket fel kell osztani kliens gépekre, amelyeknek mindig kell valami, és szervergépekre, amelyek azt adják, amire szükségük van. Ebben az esetben mindig a kliens indítja el az interakciót, és az interakció létrejöttének szabályait a protokoll írja le.

Kétféle kliens-szerver interakciós architektúra létezik: az elsőt kétszintű kliens-szerver architektúrának , a másodikat többszintű kliens-szerver architektúrának (ezt néha háromrétegű architektúrának vagy háromrétegű architektúrának nevezik, de ez egy speciális eset).

A kliens-szerver interakció kétszintű architektúrájának működési elve az, hogy egy kérés feldolgozása egy szerveren történik anélkül, hogy a feldolgozás során más szerverekre hivatkozna.

A kétszintű kliens-szerver interakciós modell egyszerű diagramként rajzolható meg.

Itt látható, hogy az első szint minden, ami a klienst érinti, a második szint pedig minden, ami a szervert érinti.