Susisiekite su mumis dėl asmeninio FinMV pasiūlymo, pritaikyto jūsų poreikiams.
Jūsų įmonės techninis direktorius, planuodamas finansinės platformos paleidimą, turės pasirinkti projekto architektūros variantą. Kokios architektūros galimybės jam prieinamos ir kurią geriau pasirinkti?
Monolitinė architektūra yra kaip sniego gniūžtė. Pradedate projektą ir turite mažą sniego gniūžtę. Ji tokia maža, kad ją gali sukurti ir suvynioti nedidelė komanda. Praeina pora metų, o dabar jūsų sniego gniūžtė tapo tokia didžiulė, kad 20 kūrėjų jau stumia ją. Dar po poros metų šimtai kūrėjų išvers jūsų sniego gniūžtę su daugybe kodų, tačiau naujų funkcijų paleidimas bus labai lėtas.
Todėl savininkai pradeda keisti techninį direktorių, komandos narius, bet tik blogėja. Nauji komandos nariai nežino istorinių detalių, kodėl sniego gniūžtė yra tokia, kokia yra, o ne kita. Produkto dokumentacija greitai pasensta.
Kodėl to nepadarius nuo pat pradžių? Pirma, pačioje verslo pradžioje visada yra ištekliai riboti, nepakanka kūrėjų, patirties ir laiko. Vadovas ragina, o programuotojai skuba tai padaryti kuo greičiau.
Antra, technikos inžinieriai galvoja: „ Na, kol kas tai tebūnie monolitinė architektūra, bet kai verslas augs, tada darysime viską iš naujo“. Deja, iš tikrųjų perkelti esamą monolitinį projektą į mikropaslaugų architektūrą bus dešimtis kartų sunkiau nei parašyti viską nuo nulio.
Jūsų finansinę platformą nedelsdami sukursime remdamiesi mikro paslaugų architektūra.
Microservice architektūra gali būti lyginama su grindinio plokštėmis pėsčiųjų takuose. Kai jūsų projektas auga, prie jūsų tako pridedama daugiau plytelių. Jei komponentas pasenęs, pakanka pakeisti šią plytelę nauja.
Ši architektūra turi daug privalumų, tačiau išvardinsiu svarbiausius:
Pirmasis pavyzdys. P2P skolinimo platformos su dideliu vartotojų skaičiumi valdymas nusprendė patekti į šalių, kuriose yra kita valiuta, rinkas. Platforma buvo monolitinės architektūros ir apėmė tik vieną valiutą – eurą, o norint patekti į Švedijos (Švedijos kronos), Lenkijos (Lenkijos zlotas), Čekijos (Čekijos krona) rinkas, reikėjo įvesti daugiavaliutą.
Prireikė mėnesių, kol visa komanda įdiegė šią funkciją, o naujos funkcijos kūrimas dar labiau sulėtėjo. Mikropaslaugos architektūros atveju viskas būtų daug paprasčiau ir greičiau.
Antras pavyzdys. Iš pradžių svetainių kūrimo priemonė buvo paleista gimtąja kalba, o valdymas nesiruošė plėstis į kitas rinkas. Projektas buvo monolitinės architektūros, o funkcionalumas sparčiai augo. Platformos schema buvo sudėtingas tinklas, kuriame viskas buvo sujungta su viskuo. Vieną dieną įmonė nusprendė išleisti platformos versiją kitomis kalbomis. Iš pradžių atrodė, kad užteks pridėti tik kalbos failus, o dabar turėsime išversti visą sąsają.
Praktiškai reikėjo perdaryti visą projektą. Pavyzdžiui, įmonių ir produktų pavadinimai duomenų bazėje dabar turėtų būti saugomi ne tik viena kalba, bet kiekviena kalba. Dėl verslo logikos informacijos dubliuoti buvo neįmanoma, reikėjo saugoti visų kalbų pavadinimus vienu metu. Atitinkamai, dėl to pasikeitė kabineto ir užpakalinio biuro sąsajos. Pakeitus sąsają reikėjo pakeisti gaunamų duomenų patvirtinimo taisykles, raidžių šablonus dėl skirtingų galūnių skirtingomis kalbomis principų, keisti testus ir pan.
Kadangi viskas buvo su viskuo susieta, buvo priimtas sprendimas pereiti prie mikro paslaugų architektūros kartu su naujų kalbų paleidimu. Perėjimo nuo monolitinės prie mikro paslaugų architektūros procesas truko daugiau nei metus.
Trečias pavyzdys. „Fintech“ platforma buvo sukurta naudojant seną PHP ir Laravel versiją. Atnaujinti į naujesnes versijas, taip pat pakeisti duomenų bazę iš MariaDB į PostgreSQL buvo praktiškai neįmanoma, nes visai komandai kelis mėnesius teko susidurti tik su perkėlimo procesu.
Naujos PHP ir Laravel versijos tuo metu galėjo pagreitinti projektą ir tolesnę plėtrą, tačiau monolitinė architektūra neleido atnaujinti technologijų krūvos
.
