Elosztott monolit és a „mikroszerviz = jobb” tévhit
Célok
A lecke végére fel tudod ismerni az elosztott monolit jeleit, és meg tudod indokolni, miért nem jobb egy architektúra csak azért, mert több szolgáltatásból áll.
Miért kell erről külön beszélni?
A mikroszerviz divatos, ezért gyakran a „fejlett” architektúra szinonimájaként jelenik meg. Ez a feltevés — hogy a több, kisebb, hálózaton összekötött szolgáltatás mindig jobb a monolitnál — téves. A szétosztásnak ára van (3.3), és ha az előnyök elmaradnak, csak az ár marad.
Mi az elosztott monolit?
Az elosztott monolit olyan rendszer, amely külön folyamatokra van bontva, de a részei nem tudnak érdemben külön változni vagy működni. A szolgáltatások hálózaton beszélnek, a csatolás viszont megmaradt: a rendszernek a monolit hátrányai (összekapcsolt kiadás) és az elosztott rendszer hátrányai (hálózati hiba, késleltetés) egyaránt megvannak. A kifejezés szakmai közhasználatú, nem szabványosított; a leírások egyező jelei:
Összehangolt kiadás: egy szolgáltatás változtatása másokét is kikényszeríti.
Közös adat: több szolgáltatás közvetlenül ugyanazt az adatot írja.
Hosszú szinkron láncok: egy kérés sok szolgáltatáson halad át, és bármelyik kiesése az egészet megállítja.
Technikai vágás: a rendszert technikai rétegek (felület, háttér) szerint bontották, nem üzleti képességek szerint.
flowchart LR
K["Kérés"] --> A["Szolgáltatás A"]
A -->|"szinkron"| B["Szolgáltatás B"]
B -->|"szinkron"| C["Szolgáltatás C"]
C -->|"szinkron"| D["Szolgáltatás D"]
A --> DB[("Közös adat")]
C --> DB
Az ábrán a hibatartomány nem lett kisebb: ha D kiesik, a kérés elbukik. A hálózati bonyolultság megjelent, a haszon nem.
Az eseményküldés sem oldja meg automatikusan a csatolást: ha minden fogyasztó ugyanazon belső adatstruktúra pontos verzióját várja, az események felé is együtt kell frissíteni őket.
Miért nem „jobb” a mikroszerviz?
A haszon feltételes. Akkor jelenik meg, ha a részek valóban külön ütemben változnak, külön skálázódnak vagy külön hibahatárt kívánnak, és a csapat az automatizálást, a megfigyelést és az üzemeltetést bírja.
A határ nehezen javítható. Fowler szerint a legtöbb sikeres mikroszervizrendszer monolitként indult, és utólag bontották szét; a nulláról mikroszervizként épített rendszerek gyakran komoly nehézségekbe ütköztek. Az ok az, hogy a szolgáltatáshatárokat előre nehéz jól kijelölni, és a funkciók mozgatása szolgáltatások között sokkal nehezebb. Fowler maga is megjegyzi, hogy a bizonyíték ebben a kérdésben gyér, ezért óvatos ajánlásnak szánja.
A felár valós. A „microservice premium” miatt a stílus a rendszerek többségénél nem éri meg; Fowler szerint a legtöbb rendszernek jól definiált belső modulokkal monolitnak kell maradnia.
A szervezet is számít. A rendszer szerkezete a szervezet kommunikációs szerkezetét másolja (Conway, lásd 1.2): ha egy kis csapat gondoz sok szolgáltatást, az önállóság hasznát az infrastruktúra gondozása felemészti.
Helyzet
Mire utal?
Egy változtatás három szolgáltatás összehangolt kiadását igényli
Elosztott monolit
Kis csapat, bizonytalan termékhatárok, sok szolgáltatás
A felár meghaladhatja a hasznot
Valóban külön életciklusú, külön skálázandó részek, több csapat
A mikroszerviz indokolt lehet
Gyakori tévhitek
Állítás
Pontosítás
„A mikroszerviz mindig jobb, mint a monolit.”
Mindkettő kompromisszum; a követelmények döntenek.
„Ha külön folyamatban fut, már független.”
Ha együtt kell kiadni és működni, elosztott monolit.
„Az eseményvezérelt kommunikáció megszünteti a csatolást.”
Az adatstruktúra pontos verziójától való függés megmarad.
„A monolit elavult.”
Sok rendszernek a jól moduláris monolit a megfelelő választás.
Röviden
Az elosztott monolit külön folyamatokban futó, de együtt változó és együtt működő rendszer.
Jele: összehangolt kiadás, közös adat, hosszú szinkron lánc, technikai vágás.
A mikroszerviz haszna feltételes, ára valós.
A legtöbb rendszernek a jól moduláris monolit elég lehet.
Ellenőrző kérdések
Milyen jelek alapján neveznél egy rendszert elosztott monolitnak?
Miért nem oldja meg az eseményküldés önmagában a csatolást?
Hogyan érvelnél amellett, hogy egy konkrét rendszernek ne mikroszervizek legyenek?
Elosztott monolit és a „mikroszerviz = jobb” tévhit
Célok
A lecke végére fel tudod ismerni az elosztott monolit jeleit, és meg tudod indokolni, miért nem jobb egy architektúra csak azért, mert több szolgáltatásból áll.
Miért kell erről külön beszélni?
A mikroszerviz divatos, ezért gyakran a „fejlett” architektúra szinonimájaként jelenik meg. Ez a feltevés — hogy a több, kisebb, hálózaton összekötött szolgáltatás mindig jobb a monolitnál — téves. A szétosztásnak ára van (3.3), és ha az előnyök elmaradnak, csak az ár marad.
Mi az elosztott monolit?
Az elosztott monolit olyan rendszer, amely külön folyamatokra van bontva, de a részei nem tudnak érdemben külön változni vagy működni. A szolgáltatások hálózaton beszélnek, a csatolás viszont megmaradt: a rendszernek a monolit hátrányai (összekapcsolt kiadás) és az elosztott rendszer hátrányai (hálózati hiba, késleltetés) egyaránt megvannak. A kifejezés szakmai közhasználatú, nem szabványosított; a leírások egyező jelei:
flowchart LR K["Kérés"] --> A["Szolgáltatás A"] A -->|"szinkron"| B["Szolgáltatás B"] B -->|"szinkron"| C["Szolgáltatás C"] C -->|"szinkron"| D["Szolgáltatás D"] A --> DB[("Közös adat")] C --> DBAz ábrán a hibatartomány nem lett kisebb: ha D kiesik, a kérés elbukik. A hálózati bonyolultság megjelent, a haszon nem.
Az eseményküldés sem oldja meg automatikusan a csatolást: ha minden fogyasztó ugyanazon belső adatstruktúra pontos verzióját várja, az események felé is együtt kell frissíteni őket.
Miért nem „jobb” a mikroszerviz?
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Források