Úgy tűnik, hogy a mikroservice-ek iránti hype csúcsa már mögöttünk van. Már nem olvasunk heti több bejegyzést arról, hogy "Hogyan alakítottam át a monolitomat 150 szolgáltatásra". Mostanában gyakrabban hallom a racionális felfogásokat: "Nem utálom a monolitot, egyszerűen csak az hatékonyság miatt aggódom". Sőt, már szemtanúja voltunk néhány migrációnak . A nagyobb alkalmazásokról a kisebb szolgáltatásokra való átállás során számos új problémát kell megoldanod. Nézzük meg őket a lehető legrövidebben.
Telepítés: az alapvető kémiától a kvantummechanikáig
Az alapadatbázis és a háttérfolyamatokkal rendelkező alkalmazás beállítása meglehetősen egyértelmű folyamat volt. Közéteszem a readme-t a Github-ra – és gyakran egy óra, legfeljebb pár óra elteltével minden működik, és én már új projektet kezdek. A kód hozzáadása és futtatása, legalábbis az alap környezetben, az első napon elvégezhető. De ha belemerülünk a mikroservice-ekbe, az első indítás ideje a csillagokba emelkedik. Igen, most már van Docker orchestration-nal és K8-as gépkörzettel, de a kezdő programozónak ez mind sokkal bonyolultabb. Sok junior számára ez egy nehézség, ami valójában szükségtelen bonyodalom.
A rendszer megértése nem egyszerű
Ácsa egy pillanatra a juniorunkra. Monolitikus alkalmazásokkal ha hiba történt, azt könnyen nyomon tudtuk követni és azonnal el tudtuk kezdeni a hibakeresést. Most van egy szolgáltatásunk, amely egy másik szolgáltatással kommunikál, az egy üzenetbuszra valamit sorba állít, ami egy másik szolgáltatást kezel – és itt hibák lépnek fel. Össze kell gyűjtenünk mindezeket az elemeket, hogy végül kiderüljön, hogy az A szolgáltatás 11-es verzióval működik, míg az E szolgáltatás már a 12-es verzióra vár. Ez nagyon eltér az én szabványos konszolidált naplómtól: interaktív terminált / hibakeresőt kell használnunk, hogy lépésről lépésre végigmenjünk a folyamaton. A hibakeresés és az alkalmazások megértése lényegében nehezebbé vált.
Ha nem lehet hibakeresni, lehet, hogy tesztelni fogjuk őket
A folyamatos integráció és folyamatos fejlesztés ma már elterjedt gyakorlattá vált. A legtöbb új alkalmazás, amit látok, automatikusan létrehozza és futtatja a teszteket minden új verzióval, és megköveteli, hogy a teszteket el kell végezni és felül kell vizsgálni a regisztrálás előtt. Ezek nagyszerű folyamatok, amelyeket nem szabad elhanyagolni, és sok cég számára komoly elmozdulást jelentenek. De most, hogy valóban ellenőrizni tudjam a szolgáltatást, fel kell állítanom az alkalmazásom teljes munkaképességű verzióját. Emlékszel arra az új mérnökre, akinek 150 szolgáltatásból álló K8 klasztere volt? Nos, most megtanítjuk a CI rendszerünket, hogyan állítsa fel ezeket a rendszereket annak érdekében, hogy ellenőrizzük, valóban minden megfelelően működik. Valószínűleg ez túl sok erőfeszítés, ezért inkább elkülönítve teszteljük minden egyes részt: biztos vagyok abban, hogy a specifikációink elég jók, az API tiszta, és a szolgáltatás leállása elkülönített és nem befolyásolja a másokat.
Minden kompromisszumnak van valamilyen érvényes oka. Igaz?
Számos oka van a mikroszolgáltatásokra való áttérésnek. Láttam, hogy ezt nagyobb rugalmasság, csapatok méretezése, teljesítmény vagy jobb működési ellenállás érdekében teszik. De a valóságban évtizedeket fektettünk a monolitikus fejlesztési eszközökbe és gyakorlatokba, amelyek továbbra is fejlődnek. Különböző technológiákban dolgozó szakemberekkel dolgozom. Általában a méretezésről beszélünk, mert szembesülnek a Postgres adatbázis egyetlen csomópontjának határaival. A beszélgetések nagy része a .
De mindig érdekel, hogy milyen architektúrájuk van. Milyen szakaszában vannak a mikroszolgáltatásokra való áttérésnek. Érdekes figyelni, hogy egyre több mérnök mondja, hogy elégedett a monolitikus alkalmazásával. Sokak számára a mikroszolgáltatások előnyöket hoznak, és az előnyök felülmúlják a migráció során fellépő nehézségeket. De személy szerint kérlek, adjátok vissza a monolitikus alkalmazásomat, egy helyet a strandon — és teljesen boldog vagyok.
Forrás: habr.com
