Helló, Habr. Ma folytatom a bejegyzések sorozatát, amelyet kifejezetten az új kurzus indulására írtam. .
Bevezetés
Az architekturális stílus megválasztása az egyik alapvető műszaki döntés az informatikai rendszer felépítésekor. Ebben a cikk sorozatban a legnépszerűbb alkalmazásarchitekturális stílusokat szeretném bemutatni, és válaszolni a kérdésre, hogy mikor melyik architekturális stílus a legkedvezőbb. Az előadás során megpróbálom bemutatni a logikai kapcsolatot, amely elmagyarázza az architekturális stílusok fejlődését a monolitoktól a mikroszolgáltatásokig.
A Már foglalkoztunk a monolit struktúrával, és arra jutottunk, hogy a monolitnak számos problémája van: méret, összetettség, telepítés, skálázhatóság, megbízhatóság és merevség.
Most arról szeretnék beszélni, hogyan lehet a rendszert modulok/könyvtárak (komponens-alapú architektúra) vagy szolgáltatások (szolgáltatás-alapú architektúra) formájában megszervezni.
Komponens-alapú architektúra
A komponens-alapú architektúra azt feltételezi, hogy a rendszer egy olyan összetevőkészlet formájában valósul meg, amelyeket a jelenlegi és a jövőbeli projektek során egyaránt használhatunk. A rendszer komponensekre bontása során figyelembe kell venni a következőket: újrahasználhatóság, helyettesíthetőség, kontextustól való függetlenség, bővíthetőség, kapszulázás és függetlenség.
A komponensek megfelelő használatával megoldható a "nagy szennyes golyó" problémája (nagy méret + magas összetettség), és maguk a komponensek lehetnek összeszerelési egységek (modulok, könyvtárak) vagy telepítési egységek (szolgáltatások). A telepítési egységek nem mindig tükrözik a végrehajtott folyamatot: például a webalkalmazás és az adatbázis együtt kerül telepítésre.
A monolitokat leggyakrabban modulok sorozataként fejlesztik ki. Ez a megközelítés biztosítja a fejlesztés függetlenségét, de a független skálázás, telepítés, hibatűrés és a közös technológiai stack-től való függetlenség problémái továbbra is fennállnak. Éppen ezért a modul részben független összetevőnek számít.
A legnagyobb probléma egy ilyen monolittal az, hogy a modulokra bontás tisztán logikai és könnyen megsérthető a fejlesztők által. Lehet, hogy megjelenik egy core modul, amely fokozatosan szemétről szemétre változik, a modulok között nőhet a függőségi gráf stb. Az ilyen problémák elkerülése érdekében a fejlesztést vagy nagyon érett csapattal, vagy egy "építész" irányítása alatt kell végezni, aki teljes munkaidőben foglalkozik a kód áttekintésével és megakadályozza a logikai struktúrát megsértő fejlesztőket.
Az "ideális" monolit logikailag elválasztott modulok sorozataként jelenik meg, mindegyik saját adatbázisára néz.
Szolgáltatás-alapú architektúra
Ha mégis a szolgáltatások rendszerbe történő szervezését tervezik, akkor szolgáltatásorientált architektúráról van szó. Elvei: a felhasználóorientált alkalmazások összeférhetősége, az üzleti szolgáltatások többszöri felhasználása, a technológiai készlettől való függetlenség és az autonómia (független fejlődés, skálázhatóság és telepíthetőség).
A szolgáltatásorientált architektúra (SOA = service oriented architecture) megoldja a monolitikus problémákat: változtatás esetén csak egy szolgáltatás érintett, és a világosan definiált API jó kapszulációt biztosít a komponensek számára.
De nem minden olyan sima: a SOA új problémákat is felvet. A távoli hívások költségesebbek, mint a helyiek, és a komponensek közötti feladatmegosztás lényegesen drágábbá vált.
Egyébként az önálló telepítés lehetősége nagyon fontos jellemzője a szolgáltatásnak. Ha a szolgáltatásokat együtt kell telepíteni, vagy még inkább, meghatározott sorrendben, akkor a rendszert nem lehet szolgáltatásorientáltnak tekinteni. Ilyen esetben elosztott monolitról beszélnek (ami nemcsak a SOA, hanem a mikroszolgáltatás-architektúra szempontjából is antipattern).
A szolgáltatásorientált architektúrát jól támogatja az architektúra közösség és a beszállítók. Ebből adódik, hogy számos tanfolyam és tanúsítvány, jól kidolgozott minták állnak rendelkezésre. Az utóbbiak közé tartozik például a jól ismert vállalati szolgáltatásbusz (ESB = enterprise service bus). Ugyanakkor az ESB a beszállítók öröksége, nem szükséges, hogy a SOA-ban alkalmazzák.
A szolgáltatásorientált architektúra népszerűségének csúcsa körülbelül 2008-ra tehető, ezután fokozatosan csökkent, ami jelentősen felgyorsult a mikroszolgáltatások megjelenésével (~2015).
Zárás
Miután átbeszéltük az információs rendszerek szolgáltatások és modulok formájában történő szervezésének lehetőségeit, javaslom, hogy végre térjünk át a mikroszolgáltatások architektúrájának elveire, és különösen figyeljünk a mikroszolgáltatások architektúrája és a szolgáltatásorientált architektúra közötti különbségekre a következő részben.
Forrás: habr.com
