A lecke végére meg tudod határozni, mi a monolit, fel tudod sorolni az előnyeit és költségeit a hét szempont mentén, és meg tudod mondani, mikor érdemes megtartani.
Miért érdemes a monolittal kezdeni?
A monolit az alapeset, amelyhez a többi architektúrát hasonlítani lehet. Ha nem világos, mit ad és mit vesz el, a szétbontás előnyei és költségei sem mérlegelhetők. A monolit gyakran jó választás is, nemcsak kiindulópont.
Mi a monolit?
A monolit olyan alkalmazás, amelynek fő funkciói egyetlen telepítési egység részei. Ez a kiadás és a futtatás határára vonatkozik, nem a kód minőségére: a monolit belső szerkezete lehet rétegzett, komponensalapú vagy moduláris, de lehet rendezetlen is. A microservices.io leírása szerint a monolitikus architektúra az alkalmazást egyetlen telepíthető és futtatható komponensként, egyetlen adatbázissal építi fel.
A monolit nem egy gépen fut szükségszerűen: több azonos példány is futhat terheléselosztó mögött. Ilyenkor is egy alkalmazás több másolata fut, nem több szolgáltatás.
flowchart LR
U["Kliens"] --> H["HTTP-belépés"]
subgraph M["Monolit: egy telepítési egység"]
H --> A["Üzleti funkciók"]
A --> R["Adatelérés"]
end
R --> DB[("Adatbázis")]
A belső hívások egy folyamaton belüli függvényhívások. A vezérlés, a kivételek és a tranzakció követhető egyetlen helyen.
Szempontok szerint
Szempont
A monolit jellemzően
Csatolás
A részek közötti határt csak fegyelem tartja; könnyen megszűnik
Deployolhatóság
Egy kiadás, egyszerű, de minden változtatás ugyanazt a csomagot érinti
Skálázás
Az egész alkalmazás skálázható; egyes részek külön nem
Adatkezelés
Közös adatbázis, helyi tranzakciók
Konzisztencia
Egy tranzakcióban több funkció adata is módosítható
Hibakezelés
Egy hívási verem, egy naplóforrás; de egy hiba az egész folyamatot érintheti
Csapat- és üzemeltetési költség
Kevés mozgó rész; nagy csapatnál a közös kód egyeztetést igényel
A microservices.io a monolit előnyeként említi az egyszerűbb, hatékonyabb helyi kommunikációt és a helyi adatbázis-tranzakciókat (részletesen az 5.1 leckében), hátrányként a nagy közös kódbázist, a lassabb kiadási folyamatot, az egyetlen technológiai készletet és azt, hogy a részek skálázási, rendelkezésre állási vagy biztonsági tulajdonságai nem választhatók szét.
Hol jelentkezik a költség?
A költségek jelentős része a közös erőforrásokból és a közös kiadásból ered. Egy memóriaszivárgás az egész folyamatot érinti. Ha csak egy funkció igényel sok processzoridőt, az egész alkalmazásból kell több példányt indítani, hacsak a terhelést nem vesszük ki külön futó egységbe. Nagy szervezetben a közös kód és a közös kiadási folyamat egyeztetési ponttá válhat.
Fontos: ezeknek a nehézségeknek egy része nem a monolit létezéséből, hanem rossz belső határokból vagy elhanyagolt tesztekből ered. Szétbontásuk ezeket önmagában nem javítja.
Mikor érdemes megtartani?
Ha az alkalmazás fő részei együtt változnak, közös tranzakciókat igényelnek, és a csapat egyetlen kiadást hatékonyan kezel, a monolit jó választás. Martin Fowler a „monolit először” stratégiát azzal indokolja, hogy a szolgáltatáshatárokat nehéz előre jól kijelölni, és a funkciók mozgatása szolgáltatások között sokkal nehezebb, mint egy monoliton belül. Hozzáteszi: ez nem automatikus; csak jól moduláris monolitot lehet később szétbontani.
Gyakori tévhitek
Állítás
Pontosítás
„A monolit egy szerveren fut.”
Több példányban is futhat; a lényeg a közös telepítési egység.
„A monolit rendezetlen kód.”
Belső szerkezete lehet rendezett, ellenőrzött.
„A monolit nem skálázható.”
Horizontálisan skálázható; csak az egyes részek külön nem.
„A modern rendszer nem lehet monolit.”
A választás a követelményektől függ, nem a divattól.
Röviden
A monolit egyetlen telepítési egység, közös futási és kiadási határral.
Előnye az egyszerűség, a helyi hívás és a helyi tranzakció.
Ára a közös kiadás, a közös erőforrás és a szelektív skálázás hiánya.
A rossz szerkezet nem a monolit sajátja, és nem oldódik meg szétbontással.
Ellenőrző kérdések
Miért nem lesz mikroszerviz egy monolitból attól, hogy hat példányban futtatják?
Melyik szempontban előnyös a monolit, és melyikben hátrányos?
Mikor indokolt a monolit megtartása a szétbontás helyett?
A monolit: egy telepítési egység
Célok
A lecke végére meg tudod határozni, mi a monolit, fel tudod sorolni az előnyeit és költségeit a hét szempont mentén, és meg tudod mondani, mikor érdemes megtartani.
Miért érdemes a monolittal kezdeni?
A monolit az alapeset, amelyhez a többi architektúrát hasonlítani lehet. Ha nem világos, mit ad és mit vesz el, a szétbontás előnyei és költségei sem mérlegelhetők. A monolit gyakran jó választás is, nemcsak kiindulópont.
Mi a monolit?
A monolit olyan alkalmazás, amelynek fő funkciói egyetlen telepítési egység részei. Ez a kiadás és a futtatás határára vonatkozik, nem a kód minőségére: a monolit belső szerkezete lehet rétegzett, komponensalapú vagy moduláris, de lehet rendezetlen is. A microservices.io leírása szerint a monolitikus architektúra az alkalmazást egyetlen telepíthető és futtatható komponensként, egyetlen adatbázissal építi fel.
A monolit nem egy gépen fut szükségszerűen: több azonos példány is futhat terheléselosztó mögött. Ilyenkor is egy alkalmazás több másolata fut, nem több szolgáltatás.
flowchart LR U["Kliens"] --> H["HTTP-belépés"] subgraph M["Monolit: egy telepítési egység"] H --> A["Üzleti funkciók"] A --> R["Adatelérés"] end R --> DB[("Adatbázis")]A belső hívások egy folyamaton belüli függvényhívások. A vezérlés, a kivételek és a tranzakció követhető egyetlen helyen.
Szempontok szerint
A microservices.io a monolit előnyeként említi az egyszerűbb, hatékonyabb helyi kommunikációt és a helyi adatbázis-tranzakciókat (részletesen az 5.1 leckében), hátrányként a nagy közös kódbázist, a lassabb kiadási folyamatot, az egyetlen technológiai készletet és azt, hogy a részek skálázási, rendelkezésre állási vagy biztonsági tulajdonságai nem választhatók szét.
Hol jelentkezik a költség?
A költségek jelentős része a közös erőforrásokból és a közös kiadásból ered. Egy memóriaszivárgás az egész folyamatot érinti. Ha csak egy funkció igényel sok processzoridőt, az egész alkalmazásból kell több példányt indítani, hacsak a terhelést nem vesszük ki külön futó egységbe. Nagy szervezetben a közös kód és a közös kiadási folyamat egyeztetési ponttá válhat.
Fontos: ezeknek a nehézségeknek egy része nem a monolit létezéséből, hanem rossz belső határokból vagy elhanyagolt tesztekből ered. Szétbontásuk ezeket önmagában nem javítja.
Mikor érdemes megtartani?
Ha az alkalmazás fő részei együtt változnak, közös tranzakciókat igényelnek, és a csapat egyetlen kiadást hatékonyan kezel, a monolit jó választás. Martin Fowler a „monolit először” stratégiát azzal indokolja, hogy a szolgáltatáshatárokat nehéz előre jól kijelölni, és a funkciók mozgatása szolgáltatások között sokkal nehezebb, mint egy monoliton belül. Hozzáteszi: ez nem automatikus; csak jól moduláris monolitot lehet később szétbontani.
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Források