Moduláris monolit vagy mikroszolgáltatások. Döntési útmutató

A monolit és a mikroszolgáltatások vitáját gyakran a régi és a modern közötti választásként mutatják be. Ez kevéssé segít egy beruházási döntésben. Az architektúrának ahhoz kell illeszkednie, ahogyan a csapat fejleszt, telepít és üzemeltet. Minden szolgáltatáshatár önállóságot ad, de hálózatot, külön telepítést és új hibalehetőségeket is hoz.

A moduláris monolit egy alkalmazásként fut, belül mégis üzleti képességek szerint válik szét. A rendelés, számlázás és készlet saját interfészt birtokol. A mikroszolgáltatások hasonló határokat külön folyamatokba és rendszerint külön adattárakba tesznek. A különbség a határ üzemeltetési árában van.

1. 01

   Moduláris monolit

   Egy folyamat és telepítés. A modulok belső szerződéseken át beszélnek.

2. 02

   Mikroszolgáltatások

   Önálló folyamatok és telepítések. Minden határ hálózati és üzemeltetési költséget hoz.

A doménnel kezdjünk

Ha egy csapat egy folyamaton belül sem tud használható doménhatárt kijelölni, a hálózat nem fogja megtalálni helyette. A bizonytalan felosztás sok távoli hívást, közös táblákat és továbbra is összehangolt kiadásokat eredményez. Elosztott hibamódok jelennek meg valódi önállóság nélkül.

Egy modulnak nyilvános szerződés kell. A számlázás ne olvassa a készlet belső tábláit. Saját interfészén kérjen foglalást a készletmodultól. Függőségi szabályok és architektúratesztek őrizhetik a határt. A stabil helyi szerződés később kisebb kockázattal kerülhet API mögé.

A jó modulok üzleti képességeket követnek, nem controller és repository nevű technikai mappákat. Így egy árváltozás az árképzésben marad. Ugyanezt az elvet kódszinten a tervezési mintákról szóló cikk mutatja be.

Mit vásárol egy mikroszolgáltatás

Az önállóan telepített szolgáltatás saját ütemben változhat. A keresés a teljes termék kiadása nélkül frissülhet. A számításigényes rész külön skálázható, az érzékeny képesség pedig szigorúbb biztonsági szabályt kaphat. Az önállóság akkor érték, ha a szervezet élni tud vele.

Az ár azonnal jelentkezik. Egy függvényhívás hálózati kérés lesz. Lehet lassú, megkettőződhet vagy teljesen kieshet. Időkorlát, idempotens ismétlés, nyomkövetés és részleges hibákra kész terv szükséges. Egyetlen adatbázis-tranzakció már nem tartja össze a teljes üzleti lépést.

A tesztelés is megváltozik. Egy sikeres egységteszt nem bizonyítja, hogy a telepített szolgáltatások még egyetértenek. Kompatibilitási szerződéstesztek kellenek. Élesben naplók, metrikák és trace adatok mutatják meg, hol állt meg egy kérés. Ezek nélkül a hibakeresés ideje gyorsan nő.

Az adat mutatja a valódi határt

A saját kóddal rendelkező, de más szolgáltatás tábláit olvasó rendszer nem önálló. Egy sémaváltozás a saját repository módosítása nélkül törheti el. Az adattulajdon ezért az architektúra része.

A külön adattárak azt is jelentik, hogy egyes nézetek átmenetileg elavultak. A rendelés elfogadható, mielőtt a számlázás feldolgozza az eseményt. A csapatnak ki kell mondania, hol biztonságos ez a késés. Egy egyenleg vagy az utolsó darab foglalása más modellt igényelhet, mint egy kimutatás.

Az elosztott tranzakciót nem érdemes törékeny szinkron hívásláncnak álcázni. Események, idempotens fogyasztók és folytatható munkafolyamatok segíthetnek. Ezeket szintén figyelni és tesztelni kell. Ha nincs szükség független adattulajdonra, a modulhatárok mögötti közös adatbázis rendszerint olcsóbb.

A csapattulajdon megváltoztatja a választ

A mikroszolgáltatások akkor működnek jól, ha a csapat a tervezéstől az éles incidensig birtokolja a szolgáltatást. A stabil tulajdonos nélküli külön repository szétteríti a felelősséget. A változások más láncszemet ismerő emberekre várnak.

Egy kisebb termékcsapat gyakran többet nyer egy telepítésből, egy fejlesztői környezetből és modulokon átívelő közvetlen refaktorálásból. Ez nem jelent rendezetlen monolitot. Az elosztás drága módja a kódfegyelem kikényszerítésének.

A helyzet akkor fordul, amikor önálló csapatok rendszeresen blokkolnak egy közös kiadást, a doménhatár stabil, és a részeknek eltérő működési ritmus kell. A leválasztás ilyenkor csökkentheti a koordinációt. A bizonyíték a megfigyelt munkából, nem divatos ábrából érkezik.

1. 01

   Önálló változási ritmus

   Egy modul blokkolja a többi kiadását.

2. 02

   Eltérő skálázási profil

   A terhelés elkülönült és ismételten mért.

3. 03

   Egyértelmű tulajdonos

   Egy csapat vállalja a fejlesztést és üzemeltetést.

4. 04

   Stabil szerződés

   A doménahatár már nem változik sprintenként.

A leválasztás jelei

Az egyik jel a független változási ok. A modulnak saját terve van, és módosításai többnyire nem igényelnek máshol beavatkozást. Másik jel az eltérő üzemeltetés. Saját skálázást, rendelkezésre állást vagy olyan technológiát igényel, amely a rendszer többi részének nem kell.

Ugyanilyen fontos a stabil szerződés. A csapat meg tudja nevezni a bemeneteket, kimeneteket, adattulajdont és hibaviselkedést. Ha a szerződés minden sprintben változik, a külön telepítés csak API-verziózási munkává alakítja a helyi bizonytalanságot.

Gyakorlati út először a monoliton belül erősíti meg a határt. Megszünteti a közvetlen adatbázis-rövidítéseket, szerződésteszteket ad hozzá és méri az interakciókat. Ezután összevethető a leválasztás haszna az elosztás árával.

Maradjon visszafordítható a döntés

Új üzleti rendszerhez a moduláris monolit gyakran jó kezdet, amíg a termék és a határok alakulnak. Egy telepítés gyors visszajelzést ad. A védett modulok megőrzik annak lehetőségét, hogy a később önállóságot érdemlő részt leválasszuk.

A mikroszolgáltatások akkor indokoltak, amikor a cég már mérhető árat fizet a közös kiadásokért, skálázásért vagy bizonytalan tulajdonért. A becslésbe a platform, a megfigyelhetőség és az incidenskezelés is beletartozik. A forráskód feldarabolása nem teremti meg ezeket.

Az egyedi szoftverfejlesztésben a feltételezéseket később felülvizsgálható döntésként rögzítjük. Ha egy régi rendszer már akadályozza a változást, a következő útmutató a legacy rendszer korszerűsítését tárgyalja. A cél a biztonságos változtatás árának csökkentése.

Leválasztás előtt visszaútnak is kell lennie. A modul metrikái megmutatják a terhelést, hibákat és változási gyakoriságot. Ha a különválasztás után minden kiadás továbbra is több csapat egyidejű munkáját igényli, rossz volt a határ. Érdemesebb kijavítani, mint ragaszkodni az architektúra nevéhez.

Az architektúradöntés rövid feljegyzése sok későbbi vitát megelőz. Tartalmazza a jelenlegi problémát, a vizsgált lehetőségeket és az ellenőrizhető feltételezéseket. Szolgáltatás esetén nevezzük meg a tulajdonos csapatot, az adatokat, a telepítési igényt és a kezelendő részleges hibákat.

Néhány kiadás után újra meg kell nézni a döntést. Hasonlítsuk össze a változtatások sebességét, a közösen végzett telepítéseket és az incidensek megoldási idejét. Az architektúra így nem végleges ítélet, hanem éles működéssel ellenőrzött feltételezés. A modul vissza is kapcsolható, ha az önállóság nem hozta meg a várt értéket.