Mikroszervizek: önálló szolgáltatások, önálló költségekkel
Célok
A lecke végére meg tudod határozni a mikroszervizes architektúrát, fel tudod sorolni a jellemzőit, és a hét szempont mentén meg tudod mondani, mit nyer és mit fizet a rendszer az önállóságért.
Miért jött létre?
Egy nagy monolitban a változtatások egymásra várnak: közös kiadás, közös adatmodell, közös folyamat. A mikroszerviz-stílus azt a problémát kezeli, hogy sok csapat külön ütemben, egymástól függetlenül tudjon változtatni egy nagy rendszeren. Ez szervezeti probléma is, nem csak műszaki.
Mi a mikroszerviz?
Fowler és Lewis meghatározása szerint a stílus kis szolgáltatások halmaza, amelyek mindegyike saját folyamatban fut, könnyű mechanizmusokon (gyakran HTTP-erőforrás-API-n) keresztül kommunikál, üzleti képességek köré szerveződik, és automatizált eszközökkel önállóan telepíthető. Az Azure Architecture Center szerint minden szolgáltatás egyetlen üzleti képességet valósít meg egy bounded contexten belül, és saját adattárolója van.
A „micro” nem sor- vagy osztályszámot jelent. A szolgáltatás mérete a felelősséghez és a csapat munkájához igazodik.
A cikk által felsorolt jellemzők:
szolgáltatásokra bontott komponensek (a határ szolgáltatáshatár);
üzleti képességek köré szerveződés;
„termékek, nem projektek” (a csapat a szolgáltatást a teljes életciklusán át birtokolja);
okos végpontok és buta csatornák;
decentralizált irányítás;
decentralizált adatkezelés;
infrastruktúra-automatizálás;
hibára tervezés;
evolúciós tervezés.
flowchart TB
C["Kliens"] --> G["Belépési pont"]
G --> A["Szolgáltatás A"]
G --> B["Szolgáltatás B"]
A --> AD[("A adata")]
B --> BD[("B adata")]
A -.->|"üzenet"| B
Mit ad?
Önálló kiadás: egy szolgáltatás a többi nélkül kiadható és visszaállítható.
Szelektív skálázás: csak a terhelt rész növelhető.
Szűkebb kódbázis, csapatonként kisebb felelősség.
Technológiai szabadság (de ez költséget is jelent: közös elvek nélkül széttartó rendszer lesz).
Hibahatár: egy szolgáltatás kiesése nem feltétlenül viszi el a többit — ha a hívási lánc ezt engedi (3.4).
Mi az ára?
Az önállóság minden dimenziójának ára van, és a legtöbb költség ugyanabból ered: a helyi hívásból hálózati hívás lett.
Szempont
Mi változik a monolithoz képest?
Csatolás
A határ szerződés; a szerződés kompatibilitását kezelni kell (6.4)
Deployolhatóság
Jobb, de a sok szolgáltatás sok kiadást és sok verziót jelent
Skálázás
Szelektív, de mindegyik szolgáltatásnak saját kapacitás- és üzemeltetési terve van
Adatkezelés
Szolgáltatásonkénti adat; a szolgáltatások közötti lekérdezés nehéz
Konzisztencia
Elosztott tranzakció helyett többnyire végső konzisztencia és kompenzáció (5. fejezet)
Hibakezelés
Részleges hiba, időtúllépés, ismétlés, ismeretlen eredmény — minden hívásnál (6. fejezet)
Költség
Több kiadás, megfigyelés, automatizálás, ismeret; kis csapatban az infrastruktúra költsége felülírhatja az önállóság hasznát
Fowler és Lewis is kiemeli: a távoli hívás drágább a folyamaton belülinél, ezért a távoli API-knak durvábbaknak kell lenniük, ami gyakran kényelmetlenebb; a szétosztott tranzakciók nehezek, ezért a szolgáltatások végső konzisztenciát és kompenzáló műveleteket használnak; a szolgáltatáshatáron át a kód mozgatása nehezebb; az egymás után láncolt szinkron hívások megsokszorozzák a kiesést.
Fowler „microservice premium” megfogalmazása szerint a stílus magas felárral jár, amely jelentősen lassíthatja a fejlesztést; akkor érdemes fontolóra venni, ha a rendszer már túl összetett ahhoz, hogy monolitként kezelhető legyen.
Gyakori tévhitek
Állítás
Pontosítás
„A mikroszerviz kis kódot jelent.”
A méretet a felelősség és a csapat határozza meg, nem a sorszám.
„Minden szolgáltatásnak külön adatbázisszerver kell.”
A lényeg a tulajdonosi határ; külön séma is lehet (5.1).
„A mikroszerviz automatikusan skálázhatóbb.”
Szelektív skálázást tesz lehetővé, de működtetési költséggel.
„Külön repó = független szolgáltatás.”
A függetlenséget a kiadás, az adat és a hibakezelés mutatja.
Röviden
A mikroszerviz önállóan futó és kiadható, saját adatot kezelő, üzleti képességre szabott szolgáltatás.
Előny: önálló kiadás, szelektív skálázás, csapatautonómia.
Mikroszervizek: önálló szolgáltatások, önálló költségekkel
Célok
A lecke végére meg tudod határozni a mikroszervizes architektúrát, fel tudod sorolni a jellemzőit, és a hét szempont mentén meg tudod mondani, mit nyer és mit fizet a rendszer az önállóságért.
Miért jött létre?
Egy nagy monolitban a változtatások egymásra várnak: közös kiadás, közös adatmodell, közös folyamat. A mikroszerviz-stílus azt a problémát kezeli, hogy sok csapat külön ütemben, egymástól függetlenül tudjon változtatni egy nagy rendszeren. Ez szervezeti probléma is, nem csak műszaki.
Mi a mikroszerviz?
Fowler és Lewis meghatározása szerint a stílus kis szolgáltatások halmaza, amelyek mindegyike saját folyamatban fut, könnyű mechanizmusokon (gyakran HTTP-erőforrás-API-n) keresztül kommunikál, üzleti képességek köré szerveződik, és automatizált eszközökkel önállóan telepíthető. Az Azure Architecture Center szerint minden szolgáltatás egyetlen üzleti képességet valósít meg egy bounded contexten belül, és saját adattárolója van.
A „micro” nem sor- vagy osztályszámot jelent. A szolgáltatás mérete a felelősséghez és a csapat munkájához igazodik.
A cikk által felsorolt jellemzők:
flowchart TB C["Kliens"] --> G["Belépési pont"] G --> A["Szolgáltatás A"] G --> B["Szolgáltatás B"] A --> AD[("A adata")] B --> BD[("B adata")] A -.->|"üzenet"| BMit ad?
Mi az ára?
Az önállóság minden dimenziójának ára van, és a legtöbb költség ugyanabból ered: a helyi hívásból hálózati hívás lett.
Fowler és Lewis is kiemeli: a távoli hívás drágább a folyamaton belülinél, ezért a távoli API-knak durvábbaknak kell lenniük, ami gyakran kényelmetlenebb; a szétosztott tranzakciók nehezek, ezért a szolgáltatások végső konzisztenciát és kompenzáló műveleteket használnak; a szolgáltatáshatáron át a kód mozgatása nehezebb; az egymás után láncolt szinkron hívások megsokszorozzák a kiesést.
Fowler „microservice premium” megfogalmazása szerint a stílus magas felárral jár, amely jelentősen lassíthatja a fejlesztést; akkor érdemes fontolóra venni, ha a rendszer már túl összetett ahhoz, hogy monolitként kezelhető legyen.
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Források