Hello, Habr. Ma folytatom a kiadványok sorozatát, amelyeket kifejezetten a kurzus új folyamának elindításához írtam. .
Bevezetés
Az építészeti stílus megválasztása az egyik alapvető technikai döntés az információs rendszer felépítésénél. Ebben a cikksorozatban azt javaslom, hogy elemezzem a legnépszerűbb építészeti stílusokat az építési alkalmazásokhoz, és válaszoljak arra a kérdésre, hogy mikor melyik építészeti stílus a legelőnyösebb. A bemutatás során megpróbálok egy logikai láncot felrajzolni, amely megmagyarázza az építészeti stílusok fejlődését a monolitoktól a mikroszolgáltatásokig.
В foglalkoztunk a monolittal, és arra a következtetésre jutottunk, hogy a monolitnak számos problémája van: méret, csatlakoztathatóság, telepítés, skálázhatóság, megbízhatóság és merevség.
Ezúttal azt javaslom, hogy egy rendszer modulokból/könyvtárakból (komponens-orientált architektúra) vagy szolgáltatásokból (szolgáltatás-orientált architektúra) való megszervezésének lehetőségeiről beszéljünk.
Komponens-orientált architektúra
A komponens-orientált architektúra magában foglalja a rendszer végrehajtását komponensek halmazaként, amely mind a jelenlegi, mind a jövőbeli projektekben használható. A rendszer komponensekre bontásánál a következőket veszik figyelembe: újrafelhasználhatóságuk, cserélhetőségük, kontextusfüggetlenségük, bővíthetőségük, beágyazhatóságuk és függetlenségük.
A komponensek megfelelő használatával megoldódik a „nagy piszok labda” (nagy méret + magas csatolás) problémája, és maguk az alkatrészek egyaránt képviselhetik az összeszerelési egységeket (modulok, könyvtárak) és a telepítési egységeket (szolgáltatások). A telepítési egységek nem mindig vannak hozzárendelve a futó folyamathoz: például egy webalkalmazás és egy adatbázis együtt kerül telepítésre.
Leggyakrabban a monolitokat modulok sorozataként fejlesztik. Ez a megközelítés független fejlesztéshez vezet, de a független méretezés és telepítés, a hibatűrés és a teljes technológiai stacktől való függetlenség problémái továbbra is fennállnak. Ezért a modul részben független komponens.
A legnagyobb probléma egy ilyen monolittal az, hogy a modulokra osztás tisztán logikus, és a fejlesztők könnyen megsérthetik. Megjelenhet egy alapmodul, ami fokozatosan szemétdombbá válik, nőhet a modulok közötti függőségek grafikonja stb. Az ilyen problémák elkerülése érdekében a fejlesztést vagy egy nagyon érett csapatnak kell végeznie, vagy egy „építész” irányítása alatt, aki főállású kódellenőrzéssel foglalkozik, és megveri a logikai struktúrát megsértő fejlesztők kezét.
Az „ideális” monolit logikailag elválasztott modulok halmaza, amelyek mindegyike a saját adatbázisába néz.
Szolgáltatás Alapú Achitektúra
Ha a rendszert szolgáltatások halmazaként kell megszervezni, akkor szolgáltatás-orientált architektúráról beszélünk. Alapelvei a felhasználó-központú alkalmazások együttműködési képessége, az üzleti szolgáltatások újrafelhasználása, a technológiai verem függetlensége és az autonómia (független fejlődés, méretezhetőség és telepítés).
A szolgáltatás-orientált architektúra (SOA = szolgáltatásorientált architektúra) megoldja a monolit összes azonosított problémáját: csak egy szolgáltatást érint a változás, és egy jól definiált API támogatja az összetevők jó beágyazását.
De nem minden olyan zökkenőmentes: a SOA új problémákat okoz. A távoli hívások drágábbak, mint a helyiek, és jelentősen megdrágult a felelősség komponensek közötti újraelosztása.
A független telepítés lehetősége egyébként nagyon fontos jellemzője a szolgáltatásnak. Ha a szolgáltatásokat együtt, vagy ráadásul meghatározott sorrendben kell telepíteni, akkor a rendszer nem tekinthető szolgáltatás-orientáltnak. Ebben az esetben elosztott monolitról beszélnek (ezt nem csak a SOA, hanem a mikroszolgáltatási architektúra szempontjából is anti-mintának tekintik).
A szolgáltatás-orientált építészetet jól támogatja az építészeti közösség és a szállítók. Ez számos tanfolyam és bizonyítvány, jól kidolgozott minták jelenlétét jelenti. Ez utóbbihoz tartozik például a jól ismert vállalati szolgáltatási busz (ESB = enterprise service bus). Ugyanakkor az ESB a szállítók poggyásza, nem feltétlenül kell használni a SOA-ban.
A szolgáltatásorientált architektúra népszerűsége 2008 körül érte el a csúcsot, ezt követően hanyatlásnak indult, ami a mikroszolgáltatások megjelenése után (~2015) jelentősen drámaibbá vált.
Következteté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, azt javaslom, hogy a következő részben végre térjünk át a mikroszolgáltatási architektúra alapelveire, és fordítsunk különös figyelmet a mikroszolgáltatási architektúra és a szolgáltatásorientált architektúra közötti különbségre.
Forrás: will.com