A lecke végére el tudod magyarázni, mitől lesz valódi modulhatár egy monolitban, meg tudod mondani, mit nyer és mit nem nyer a moduláris monolit a szolgáltatásokhoz képest, és fel tudod ismerni, mikor választható.
Miért kell?
A monolit egyszerű, de belső határai könnyen elmosódnak (2.1). A mikroszervizek erős határt adnak, de hálózati költséggel (3.3). A moduláris monolit (a tananyagban rövidítve modulit) a kettő közti megoldás: erős belső határokat épít egyetlen telepítési egységen belül, hálózat nélkül.
Mi ez?
A modulit olyan monolit, amelyben a kód felelősségi egységekre, modulokra van osztva úgy, hogy a modulok csak szűk, tudatosan tervezett publikus felületen keresztül érik el egymást, a belső megvalósításuk és (ideális esetben) az adatuk pedig rejtett. Telepítési egysége továbbra is egy.
Martin Fowler szerint a legtöbb rendszer számára a jó út a jól definiált belső modulokkal rendelkező monolit, és a „monolit először” stratégia is azt feltételezi, hogy a monolit moduláris marad.
Mitől valódi a modulhatár?
A mappanév csak jelölés. Határ akkor van, ha a többi modul nem tud tetszőlegesen belenyúlni:
a modul publikus felületet ad, üzleti jelentéssel (például „helyet foglal”, nem „táblasort frissít”);
a belső osztályok, adatbáziskapcsolat és entitások nem láthatók kívülről;
a függőségek iránya egyértelmű és körmentes;
a modul adatgazda: más modul nem ír közvetlenül az adataiba (1.3), ezt adatbázis-jogosultság, külön séma vagy automatikus függőségellenőrzés erősítheti.
flowchart LR
A["Modul A"] --> I["B modul publikus felülete"]
subgraph B["Modul B"]
I --> L["Szabályok"]
L --> R["Belső adatelérés"]
end
R --> DB[("B adatai")]
A közös tranzakció továbbra is lehetséges, de tudatos döntés kell legyen: ha egy művelet több modul adatát egyetlen tranzakcióban módosítja, egy későbbi szétbontáskor ezt a garanciát újra kell tervezni.
Szempontok szerint
Szempont
Modulit
Csatolás
Ellenőrzött modulfelületen keresztül; belső részletek rejtettek
Deployolhatóság
Egy közös egység, közös kiadás
Skálázás
Az egész egység együtt
Adatkezelés
Közös adatbázis is lehet, modulonkénti gazdákkal
Konzisztencia
Helyi tranzakció lehetséges
Hibakezelés
Egy folyamat, nincs hálózati hiba a modulok között
Csapat- és üzemeltetési költség
Közel a monolitéhoz; fegyelmet és ellenőrzést kér
Mit nem ad?
A moduláris szerkezet nem ad önálló kiadást, külön skálázást és külön hibahatárt: a közös folyamat kiesése mindent érint. Cserébe elkerüli a hálózati hívás költségeit és a szolgáltatások közti elosztott adatkezelést. Hasznos előkészítés is: ha később egy modul önálló szolgáltatássá válik, a közvetlen belső hozzáféréseket már megszüntettük, így a valódi hívások és adatigények láthatók.
Fowler ugyanakkor figyelmeztet: egy jó folyamatbeli interfész gyakran rossz szolgáltatásinterfész. A modulhatár tehát nem automatikusan jó szolgáltatáshatár.
Mikor választható?
Ha a csapat egyetlen kiadást hatékonyan kezel, de a kód határai egyre elmosódnak, vagy ha a szolgáltatáshatárok még bizonytalanok, a modulit olcsó módja az erős határok kialakításának. Ha viszont a részeknek valóban külön kiadási ritmusra, külön skálázásra vagy külön hibahatárra van szükségük, a modulit korlátai szűkké válnak (3.6).
Gyakori tévhitek
Állítás
Pontosítás
„A modulit csak a mikroszerviz előszobája.”
Önmagában is teljes értékű végállapot lehet.
„A modul = mappa.”
Modul ott van, ahol a belsőhöz való hozzáférés ellenőrzött.
„A modulit minden modulja külön adatbázist kap.”
A közös adatbázis mellett is kijelölhető modulonkénti adatgazda.
„A moduláris szerkezet csökkenti a hibaterjedést.”
Közös folyamat: egy modul hibája a többit is elviheti.
Röviden
A modulit egy telepítési egység erős belső modulhatárokkal.
A határt a publikus felület, a rejtett belső rész, a körmentes függés és az adatgazda adja.
Nincs önálló kiadás, skálázás és hibahatár.
Önmagában is végállapot lehet, és előkészítheti a szétbontást.
Ellenőrző kérdések
Mi különbözteti meg a modult egy egyszerű mappától?
Miért lehet kockázat az, ha egy tranzakció több modul adatát módosítja?
Milyen helyzetben választanád a modulitot mikroszervizek helyett?
Modulit: moduláris monolit és belső szerződések
Célok
A lecke végére el tudod magyarázni, mitől lesz valódi modulhatár egy monolitban, meg tudod mondani, mit nyer és mit nem nyer a moduláris monolit a szolgáltatásokhoz képest, és fel tudod ismerni, mikor választható.
Miért kell?
A monolit egyszerű, de belső határai könnyen elmosódnak (2.1). A mikroszervizek erős határt adnak, de hálózati költséggel (3.3). A moduláris monolit (a tananyagban rövidítve modulit) a kettő közti megoldás: erős belső határokat épít egyetlen telepítési egységen belül, hálózat nélkül.
Mi ez?
A modulit olyan monolit, amelyben a kód felelősségi egységekre, modulokra van osztva úgy, hogy a modulok csak szűk, tudatosan tervezett publikus felületen keresztül érik el egymást, a belső megvalósításuk és (ideális esetben) az adatuk pedig rejtett. Telepítési egysége továbbra is egy.
Martin Fowler szerint a legtöbb rendszer számára a jó út a jól definiált belső modulokkal rendelkező monolit, és a „monolit először” stratégia is azt feltételezi, hogy a monolit moduláris marad.
Mitől valódi a modulhatár?
A mappanév csak jelölés. Határ akkor van, ha a többi modul nem tud tetszőlegesen belenyúlni:
flowchart LR A["Modul A"] --> I["B modul publikus felülete"] subgraph B["Modul B"] I --> L["Szabályok"] L --> R["Belső adatelérés"] end R --> DB[("B adatai")]A közös tranzakció továbbra is lehetséges, de tudatos döntés kell legyen: ha egy művelet több modul adatát egyetlen tranzakcióban módosítja, egy későbbi szétbontáskor ezt a garanciát újra kell tervezni.
Szempontok szerint
Mit nem ad?
A moduláris szerkezet nem ad önálló kiadást, külön skálázást és külön hibahatárt: a közös folyamat kiesése mindent érint. Cserébe elkerüli a hálózati hívás költségeit és a szolgáltatások közti elosztott adatkezelést. Hasznos előkészítés is: ha később egy modul önálló szolgáltatássá válik, a közvetlen belső hozzáféréseket már megszüntettük, így a valódi hívások és adatigények láthatók.
Fowler ugyanakkor figyelmeztet: egy jó folyamatbeli interfész gyakran rossz szolgáltatásinterfész. A modulhatár tehát nem automatikusan jó szolgáltatáshatár.
Mikor választható?
Ha a csapat egyetlen kiadást hatékonyan kezel, de a kód határai egyre elmosódnak, vagy ha a szolgáltatáshatárok még bizonytalanok, a modulit olcsó módja az erős határok kialakításának. Ha viszont a részeknek valóban külön kiadási ritmusra, külön skálázásra vagy külön hibahatárra van szükségük, a modulit korlátai szűkké válnak (3.6).
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Források