Helló, Habr. Jelenleg az OTUS-nál új tanfolyamra lehet jelentkezni. . A tanfolyam kezdetének közeledtével szeretném megosztani veletek a saját cikkemet.
Bevezetés
Az architekturális stílus megválasztása az egyik alapvető műszaki döntés az informatikai rendszer felépítésekor. Ebben a cikk sorozatban a legnépszerűbb alkalmazásarchitekturális stílusokat szeretném bemutatni, és válaszolni a kérdésre, hogy mikor melyik architekturális stílus a legkedvezőbb. Az előadás során megpróbálom bemutatni a logikai kapcsolatot, amely elmagyarázza az architekturális stílusok fejlődését a monolitoktól a mikroszolgáltatásokig.
Egy kis történelem
Ha megpróbáljátok megkérdezni a fejlesztőktől: "Mire jók a mikroszolgáltatások?", a legkülönbözőbb válaszokat fogjátok kapni. Hallani fogjátok, hogy a mikroszolgáltatások javítják a skálázhatóságot, megkönnyítik a kód megértését, növelik a hibatűrést, és néha azt is hallani, hogy lehetővé teszik a "kód megtisztítását". Nézzük meg a történelmet, hogy megértsük, milyen céllal jelentek meg a mikroszolgáltatások.
Röviden, a mikroszolgáltatások a mi jelenlegi értelmezésünk szerint így születtek: 2011-ben James Lewis, különböző cégek munkáit elemezve, észrevette a "micro-app" új mintájának megjelenését, amely optimalizálta a SOA-t a szolgáltatások gyorsabb telepítése szempontjából. Később, 2012-ben, az építészeti csúcstalálkozón ezt a mintát mikroszolgáltatásra nevezték át. Így a mikroszolgáltatások bevezetésének eredeti célja a szánalmas time to market.
A mikroszolgáltatások "hype hullámában" 2015-ben voltak népszerűek. Egyes kutatások szerint egyetlen konferencia sem múlt el mikroszolgáltatásokkal kapcsolatos előadás nélkül. Sőt, egyes konferenciák kifejezetten csak a mikroszolgáltatásokra vonatkoztak. Jelenleg nagyon sok projekt kezdődik ennek az építészeti stílusnak az alkalmazásával, és ha egy projekt rengeteg örökölt kódot tartalmaz, akkor szinte biztos, hogy aktívan zajlik a migráció a mikroszolgáltatásokra.
A fentiek ellenére még mindig meglehetősen kis számú fejlesztő tudja meghatározni a "mikroszolgáltatás" fogalmát. De erről később beszélünk...
Monolit
Az építészeti stílus, amelyet a mikroszolgáltatásokkal szemben állítanak, a monolit (vagy "minden egyben"). Valószínűleg nem érdemes elmagyarázni, mi a monolit, ezért azonnal felsorolom ennek az építészeti stílusnak a hátrányait, amelyek további fejlesztésre ösztönözték az építészeti stílusokat: méret, összefonódás, telepítés, skálázhatóság, megbízhatóság és merevség. Az alábbiakban javaslom, hogy ismerkedjetek meg minden egyes hátrány részletesebben.
Méret
A monolit nagyon nagy. Rendszerint egy nagyon nagy adatbázissal kommunikál. Az alkalmazás olyan nagyra nő, hogy egy fejlesztő alapjában véve már nem tudja megérteni. A monolittal csak azok dolgoznak jól, akik elegendő időt töltöttek el ezzel a kóddal, míg a kezdők nagyon sok időt pazarolnak azzal, hogy próbálják megérteni a monolitot, és nem biztos, hogy sikerül nekik. Általában a monolit használata során mindig van egy úgynevezett „senior”, aki viszonylag jól ismeri a monolitot, és egy éven vagy másfél éven át „megveri” a kezeit a többi új fejlesztőre. Nyilvánvaló, hogy egy ilyen senior az egyetlen hibapont, és a távozása a monolit pusztulásához vezethet.
Kapcsolódás
A monolit olyan, mint egy „nagy kupac sár” (big ball of mud), amelynek módosítása megjósolhatatlan következményekkel járhat. Ha az egyik helyen változtatunk, akkor a monolit másik részén is kárt okozhatunk (ez a „fül megvakarta, *@ leesett” eset). Ennek az az oka, hogy a monolit komponensei között nagyon összetett és, ami a legfontosabb, nem nyilvánvaló kapcsolat van.
Telepítés
A monolit telepítése az összefonódott kapcsolatok miatt hosszú folyamat, amelynek megvan a maga rituáléja. Ez a rituálé általában nem teljesen standardizált, és „szájról szájra” terjed.
Skálázhatóság
A monolit moduljai ellentétes erőforrás-igényekkel bírhatnak, ami miatt kompromisszumokat kell keresni a hardver szempontjából. Képzelje el, hogy a monolit A és B szolgáltatásokból áll. Az A szolgáltatás nagy lemezterület-igényű, míg a B szolgáltatás a RAM-ra van szüksége. Ebben az esetben vagy a gép, amelyre a monolitot telepítik, támogatnia kell mindkét szolgáltatás követelményeit, vagy kézi beavatkozással az egyik szolgáltatást ki kell kapcsolni.
Egy másik példa (klasszikusabb): az A szolgáltatás sokkal népszerűbb, mint a B szolgáltatás, ezért azt akarja, hogy 100 A szolgáltatása legyen, és 10 B szolgáltatása. Ismét két lehetőség van: vagy 100 teljes monolitot telepítünk, vagy néhány monolitra kézi beavatkozással a B szolgáltatásokat ki kell kapcsolni.
Megbízhatóság
Mivel minden szolgáltatás együtt van, ha a monolit összeomlik, akkor minden szolgáltatás egyidejűleg leáll. Valójában lehet, hogy ez nem is olyan rossz, legalábbis a részleges meghibásodások a disztribúciós rendszerben elkerülhetők, de másrészt, egy olyan funkció hibája miatt, amelyet a felhasználók 0,001%-a használ, elveszítheti az összes felhasználóját a rendszerében.
Rigidity
A monolit mérete miatt nehéz áttérni az új technológiákra. Ennek következtében külön feladattá válik a feltételezett senior tudás megszerzése. A projekt kezdetén kiválasztott technológiai stack gátolhatja a termék fejlődését.
Zárás
A következő alkalommal arról beszélünk, hogyan próbálták az emberek megoldani a felmerült problémákat, áttérve a komponensekre és az SOA-ra.
Tovább olvasva:
Forrás: habr.com
