Contactați-ne pentru o ofertă personalizată FinMV, adaptată nevoilor dumneavoastră.
Directorul tehnic al companiei dumneavoastră, atunci când planifică lansarea unei platforme financiare, va trebui să aleagă o opțiune de arhitectură a proiectului. Ce opțiuni de arhitectură îi sunt disponibile și care este mai bine să aleagă?
O arhitectură monolitică este ca un bulgăre de zăpadă. Începi un proiect și ai un mic bulgăre de zăpadă. Este atât de mic încât poate fi dezvoltat și rulat de o echipă mică. Trec câțiva ani, iar acum bulgărele dvs. de zăpadă a devenit atât de mare încât 20 dezvoltatori îl susțin deja. Peste câțiva ani, sute de dezvoltatori îți vor face bulgăre de zăpadă cu o tonă de cod, dar lansarea noilor funcții va deveni foarte lentă.
Ca urmare, proprietarii încep să schimbe directorul tehnic, membrii echipei, dar se înrăutățește doar. Noii membri ai echipei nu cunosc detaliile istorice, de ce bulgărele de zăpadă este așa și nu altul. Documentația produsului devine rapid învechită.
De ce nu o faceți chiar de la început? În primul rând, chiar la începutul unei afaceri, există întotdeauna resursele sunt limitate, nu există suficienti dezvoltatori, expertiză și timp. Manualul este îndemnător, iar programatorii se grăbesc să o facă în cel mai rapid mod posibil.
În al doilea rând, inginerii tehnici cred: „Ei bine, să fie o arhitectură monolitică deocamdată, dar când afacerea va crește, atunci vom reface totul”. Din păcate, în realitate, transferul unui proiect monolitic existent într-o arhitectură de microservicii va fi de zeci de ori mai dificil decât scrierea totul de la zero.
Vom face platforma dvs. financiară imediat bazată pe arhitectura de microservicii.
Arhitectura de microservicii poate fi comparată cu placile de pavaj de pe poteci. Pe măsură ce proiectul tău crește, mai multe plăci sunt adăugate pe pasarela. Dacă o componentă este învechită, este suficient să înlocuiți această țiglă cu una nouă.
Această arhitectură are multe avantaje, dar le voi numi pe cele mai importante:
Primul exemplu. Managementul unei platforme de creditare P2P cu un număr mare de utilizatori a decis să intre pe piețele unor țări cu altă monedă. Platforma avea o arhitectură monolitică și includea o singură monedă - euro, iar pentru a intra pe piețele din Suedia (corona suedeză), Polonia (zlotul polonez), Republica Cehă (coroana cehă) a fost necesară introducerea multivalută.
Au fost necesare luni întregi pentru ca întreaga echipă să implementeze această funcționalitate, iar dezvoltarea de noi funcționalități a încetinit și mai mult. În cazul unei arhitecturi de microservicii, totul ar fi mult mai ușor și mai rapid.
Al doilea exemplu. Inițial, constructorul de site-uri a fost lansat în limba maternă și managementul nu avea de gând să se extindă pe alte piețe. Proiectul avea o arhitectură monolitică, iar funcționalitatea a crescut rapid. Schema platformei era un web complex în care totul era conectat la tot. Într-o zi, compania a decis să lanseze o versiune a platformei în alte limbi. La început, părea că ar fi suficient să adăugați doar fișiere de limbă și acum vom avea întreaga interfață tradusă.
În practică, întregul proiect a trebuit refăcut. De exemplu, numele companiilor și produselor din baza de date ar trebui să fie acum stocate nu numai într-o singură limbă, ci în fiecare limbă. A fost imposibil să duplicați informații din cauza logicii de afaceri, a fost necesar să stocați simultan numele pentru toate limbile. În consecință, acest lucru a dus la schimbări în interfețele cabinetului și back office-ului. Modificările interfeței au necesitat modificarea regulilor de validare a datelor primite, șabloane de scrisori din cauza diferitelor principii ale terminațiilor în diferite limbi, schimbarea testelor etc.
Deoarece totul era conectat la tot, a fost luată decizia de a trece la o arhitectură de microservicii odată cu lansarea de noi limbi. Procesul de tranziție de la arhitectura monolitică la arhitectura microservicii a durat mai mult de un an.
Al treilea exemplu. Platforma fintech a fost realizată pe o versiune veche a PHP și Laravel. Actualizarea la versiuni mai noi, precum și schimbarea bazei de date de la MariaDB la PostgreSQL, a fost practic imposibilă, deoarece întreaga echipă a trebuit să se ocupe doar de procesul de migrare timp de câteva luni.
Noile versiuni ale PHP și Laravel la acea vreme puteau accelera proiectul și dezvoltarea ulterioară, dar arhitectura monolitică nu permitea actualizarea stivei de tehnologie
.
