hu

Hogyan működik?

Segítségre van szüksége az üzlethez?

Forduljon hozzánk személyre szabott FinMV árajánlatért az Ön igényeinek megfelelően.

Monolit vagy mikroszolgáltatás?

Cége műszaki igazgatójának egy pénzügyi platform elindításának tervezésekor ki kell választania egy projektarchitektúra lehetőséget. Milyen építészeti lehetőségek állnak rendelkezésére, és melyiket érdemes választani?

1. lehetőség. Monolit architektúra (monolit)

A monolitikus architektúra olyan, mint egy hógolyó. Elkezd egy projektet, és van egy kis hógolyó. Annyira kicsi, hogy egy kis csapat is fejlesztheti és görgetheti. Eltelik pár év, és mára a hógolyód akkora lett, hogy már 20 fejlesztő szorgalmazza. Néhány éven belül fejlesztők százai gurítják majd a hógolyót egy csomó kóddal, de az új funkciók bevezetése nagyon lassú lesz.

Ennek eredményeként a tulajdonosok elkezdik cserélni a technikai igazgatót, a csapattagokat, de a helyzet csak romlik. Az új csapattagok nem ismerik a történelmi részleteket, hogy miért olyan a hógolyó, amilyen, és miért nem más. A termékdokumentáció gyorsan elavulttá válik.

Miért nem csinálod rögtön az elején? Először is, a vállalkozás legelején mindig korlátozottak az erőforrások, nincs elég fejlesztő, szakértelem és idő. A kézikönyv sürgető, a programozók pedig sietnek, hogy a lehető leggyorsabban megtegyék.

Másodszor a műszaki mérnökök azt gondolják: "Nos, ez most legyen monolitikus architektúra, de ha a vállalkozás növekszik, akkor mindent újra csinálunk". Sajnos a valóságban egy meglévő monolitikus projekt átvitele mikroszolgáltatási architektúrába tízszer nehezebb lesz, mint mindent a nulláról írni.

2. lehetőség. Mikroszolgáltatás architektúra

Az Ön pénzügyi platformját azonnal mikroszolgáltatási architektúra alapján készítjük el.

A mikroszolgáltatási architektúra összehasonlítható a járólapokkal a gyalogutakon. A projekt növekedésével egyre több csempét adnak a sétányhoz. Ha egy összetevő elavult, elegendő ezt a csempét egy újra cserélni.

Ennek az architektúrának számos előnye van, de felsorolom a legfontosabbakat:

  • az egyes mikroszolgáltatások működéséért az egyes alkalmazottak felelősek
  • a projektkód ellopása megakadályozva van, mivel a fejlesztők a kódnak csak egy részéhez férhetnek hozzá.
  • a programnyelvi frissítések megjelenésekor az egyes szolgáltatások programkódját egyenként javíthatja.

Példák valós életből

Első példa. Egy nagyszámú felhasználóval rendelkező P2P hitelezési platform menedzsmentje úgy döntött, hogy más pénznemet használó országok piacára lép. A platform monolitikus felépítésű volt, és csak egy valutát tartalmazott - az eurót, és ahhoz, hogy beléphessen Svédország (svéd korona), Lengyelország (lengyel zloty), Csehország (cseh korona) piacára, be kellett vezetni a többvalutát.

Hónapokba telt, mire az egész csapat bevezette ezt a funkciót, és az új funkciók fejlesztése még tovább lassult. Mikroszolgáltatás architektúra esetén minden sokkal egyszerűbb és gyorsabb lenne.

Második példa. Kezdetben a webhelykészítőt az anyanyelven indították el, és a menedzsment nem kívánt terjeszkedni más piacokra. A projekt monolitikus felépítésű volt, és a funkcionalitás gyorsan bővült. A platform sémája egy összetett web volt, amelyben minden mindennel összefüggött. Egy napon a vállalkozás úgy döntött, hogy kiadja a platform egy változatát más nyelveken is. Eleinte úgy tűnt, elég csak nyelvi fájlokat hozzáadni, és most a teljes felületet lefordítjuk.

A gyakorlatban az egész projektet újra kellett készíteni. Például az adatbázisban szereplő cégek és termékek neveit mostantól nem csak egy nyelven, hanem minden nyelven kell tárolni. Az üzleti logika miatt lehetetlen volt az információk megkettőzése, az összes nyelv nevét egyszerre kellett tárolni. Ennek megfelelően ez változásokhoz vezetett a kabinet és a back office felületeiben. Az interfész módosítása szükségessé tette a bejövő adatok érvényesítésének szabályait, a levélsablonokat a különböző nyelvű végződések eltérő elve miatt, a tesztek megváltoztatását stb.

Mivel minden mindennel összefüggött, az új nyelvek bevezetésével együtt a mikroszolgáltatási architektúrára való átállás mellett döntöttek. A monolitikus architektúráról a mikroszolgáltatásra való átállás folyamata több mint egy évig tartott.

Harmadik példa. A fintech platform a PHP és a Laravel régi verzióján készült. Az újabb verziókra való frissítés, valamint az adatbázis cseréje MariaDB-ről PostgreSQL-re gyakorlatilag lehetetlen volt, mivel az egész csapatnak több hónapig csak a migrációs folyamattal kellett foglalkoznia.

A PHP és a Laravel akkori új verziói felgyorsíthatták a projektet és a további fejlesztést, de a monolitikus architektúra nem tette lehetővé a technológiai verem frissítését

.