Nova generacija arhitekture naplate: transformacija s prijelazom na Tarantool

Zašto korporacija poput MegaFona treba Tarantool u naplati? Izvana se čini da prodavač obično dođe, donese nekakvu veliku kutiju, utakne utikač u utičnicu - i to je naplata! Nekad je tako bilo, a sada je arhaično, a takvi dinosauri su već izumrli ili izumiru. U početku, naplata je sustav za izdavanje računa - brojač ili kalkulator. U modernim telekomima to je sustav automatizacije za cijeli životni ciklus interakcije s pretplatnikom od sklapanja ugovora do raskida, uključujući naplatu u stvarnom vremenu, prihvaćanje plaćanja i još mnogo toga. Naplata u telekomunikacijskim kompanijama je poput borbenog robota - velik, snažan i napunjen oružjem.

Nova generacija arhitekture naplate: transformacija s prijelazom na Tarantool

Kakve veze ima Tarantool s tim? Razgovarat će o tome Oleg Ivljev и Andrej Knjazev. Oleg je glavni arhitekt tvrtke Megafon s bogatim iskustvom rada u stranim tvrtkama, Andrey je direktor poslovnih sustava. Iz prijepisa njihova izvješća o Tarantool konferencija 2018 saznat ćete zašto je potrebno istraživanje i razvoj u korporacijama, što je Tarantool, kako su bezizlaznost okomitog skaliranja i globalizacije postali preduvjeti za pojavu ove baze podataka u tvrtki, o tehnološkim izazovima, arhitektonskoj transformaciji te kako je MegaFonov technostack sličan Netflixu , Google i Amazon.

Projekt "Objedinjena naplata"

Riječ je o projektu pod nazivom “Objedinjena naplata”. Tu je Tarantool pokazao svoje najbolje kvalitete.

Nova generacija arhitekture naplate: transformacija s prijelazom na Tarantool

Rast produktivnosti Hi-End opreme nije držao korak s rastom pretplatničke baze i rastom broja usluga; daljnji rast broja pretplatnika i usluga bio je očekivan zbog M2M, IoT i karakteristika podružnica do pogoršanja vremena izlaska na tržište. Tvrtka je odlučila stvoriti jedinstveni poslovni sustav s jedinstvenom modularnom arhitekturom svjetske klase, umjesto dosadašnjih 8 različitih sustava naplate.

MegaFon je osam kompanija u jednoj. Godine 2009. dovršena je reorganizacija: podružnice diljem Rusije spojene su u jednu tvrtku, MegaFon OJSC (sada PJSC). Tako tvrtka ima 8 sustava naplate s vlastitim "custom" rješenjima, karakteristikama podružnica i različitim organizacijskim strukturama, IT-om i marketingom.

Sve je bilo u redu dok nismo morali lansirati jedan zajednički savezni proizvod. Ovdje su se pojavile mnoge poteškoće: za neke se tarife zaokružuju naviše, za druge naniže, a za treće - na temelju aritmetičke sredine. Takvih je trenutaka na tisuće.

Unatoč činjenici da je postojala samo jedna verzija sustava naplate, jedan dobavljač, postavke su se toliko razlikovale da je trebalo dosta vremena da se sastave. Pokušali smo smanjiti njihov broj, a naišli smo na drugi problem koji je poznat mnogim korporacijama.

Vertikalno skaliranje. Čak ni najcool hardver u to vrijeme nije zadovoljio potrebe. U radu je korištena Hewlett-Packardova oprema iz Superdome Hi-End linije, ali nije zadovoljila potrebe niti dva ogranka. Želio sam horizontalno skaliranje bez velikih operativnih troškova i kapitalnih ulaganja.

Očekivanje rasta broja pretplatnika i usluga. Konzultanti su odavno donijeli priče o IoT i M2M u svijet telekomunikacija: doći će vrijeme kada će svaki telefon i pegla imati SIM karticu, a dvije u hladnjaku. Danas imamo isti broj pretplatnika, ali u bliskoj budućnosti bit će ih mnogo više.

Tehnološki izazovi

Ova četiri razloga potaknula su nas na ozbiljne promjene. Postojao je izbor između nadogradnje sustava i projektiranja od nule. Dugo smo razmišljali, donosili ozbiljne odluke, razigravali natječaje. Kao rezultat toga, odlučili smo se za dizajn od samog početka, i prihvatili zanimljive izazove - tehnološke izazove.

Skalabilnost

Da je bilo prije, recimo, recimo 8 биллингов по 15 млн абонентов, a sad je trebalo upaliti 100 milijuna pretplatnika i više - opterećenje je za red veličine veće.

Po veličini smo postali usporedivi s velikim internetskim igračima poput Mail.ru ili Netflixa.

Ali daljnje kretanje prema povećanju opterećenja i baze pretplatnika postavilo je pred nas ozbiljne izazove.

Geografija naše ogromne zemlje

Između Kalinjingrada i Vladivostoka 7500 km i 10 vremenskih zona. Brzina svjetlosti je konačna i na takvim udaljenostima kašnjenja su već značajna. 150 ms na najcool modernijim optičkim kanalima je previše za naplatu u stvarnom vremenu, pogotovo kao što je sada u telekomu u Rusiji. Osim toga, potrebno je izvršiti ažuriranje u jednom radnom danu, a s različitim vremenskim zonama to je problem.

Ne pružamo samo usluge uz pretplatu, imamo složene tarife, pakete i razne modifikatore. Moramo ne samo dopustiti ili zabraniti pretplatniku da razgovara, već mu dati određenu kvotu - izračunati pozive i akcije u stvarnom vremenu tako da on to ne primijeti.

tolerancija kvarova

Ovo je druga strana centralizacije.

Ako skupimo sve pretplatnike u jedan sustav, onda su svaki izvanredni događaji i nepogode pogubni za poslovanje. Stoga dizajniramo sustav na takav način da eliminiramo utjecaj nesreća na cjelokupnu bazu pretplatnika.

To je opet posljedica odbijanja vertikalnog skaliranja. Kada smo skalirali vodoravno, povećali smo broj poslužitelja sa stotina na tisuće. Njima treba upravljati i biti međusobno zamjenjivi, automatski sigurnosno kopirati IT infrastrukturu i obnoviti distribuirani sustav.

Suočili smo se s tako zanimljivim izazovima. Osmislili smo sustav iu tom trenutku smo pokušali pronaći svjetske najbolje prakse kako bismo provjerili koliko smo u trendu, koliko pratimo napredne tehnologije.

Svjetsko iskustvo

Začudo, nismo pronašli niti jednu referencu u globalnom telekomu.

Europa je nazadovala po broju pretplatnika i razmjerima, SAD - po ravnomjernosti svojih tarifa. Pogledali smo neke u Kini, a neke pronašli u Indiji i angažirali stručnjake iz Vodafona Indija.

Za analizu arhitekture okupili smo Dream Team predvođen IBM-om – arhitekte iz različitih područja. Ti su ljudi mogli adekvatno procijeniti ono što radimo i unijeti određena znanja u našu arhitekturu.

ljestvica

Nekoliko brojki za ilustraciju.

Dizajniramo sustav za 80 milijuna pretplatnika s rezervom od jedne milijarde. Ovako uklanjamo buduće pragove. To nije zato što ćemo preuzeti Kinu, već zbog napada IoT i M2M.

300 milijuna dokumenata obrađenih u stvarnom vremenu. Iako imamo 80 milijuna pretplatnika, radimo i s potencijalnim klijentima i s onima koji su nas napustili ako trebamo naplatiti potraživanja. Stoga su stvarne količine osjetno veće.

2 milijarde transakcija Stanje se mijenja svakodnevno - to su plaćanja, naknade, pozivi i drugi događaji. 200 TB podataka se aktivno mijenja, mijenjajte malo sporije 8 PB podataka, a ovo nije arhiva, već živi podaci u jedinstvenom obračunu. Skala prema podatkovnom centru - 5 tisuća poslužitelja na 14 stranica.

Tehnološki skup

Kada smo planirali arhitekturu i počeli sastavljati sustav, uvezli smo najzanimljivije i najnaprednije tehnologije. Rezultat je tehnološki skup poznat svakom internet igraču i korporacijama koje proizvode visokoopterećene sustave.

Nova generacija arhitekture naplate: transformacija s prijelazom na Tarantool

Skup je sličan skupovima drugih velikih igrača: Netflix, Twitter, Viber. Sastoji se od 6 komponenti, ali mi je želimo skratiti i unificirati.

Fleksibilnost je dobra, ali u velikoj korporaciji nema načina bez ujedinjenja.

Nećemo mijenjati isti Oracle u Tarantool. U stvarnosti velikih kompanija to je utopija ili križarski rat od 5-10 godina s nejasnim ishodom. Ali Cassandra i Couchbase lako se mogu zamijeniti Tarantoolom, a to je ono čemu težimo.

Zašto Tarantool?

Postoje 4 jednostavna kriterija zašto smo odabrali ovu bazu podataka.

Ubrzati. Proveli smo testove opterećenja na industrijskim sustavima MegaFon. Tarantool je pobijedio - pokazao je najbolju izvedbu.

To ne znači da drugi sustavi ne zadovoljavaju potrebe MegaFona. Trenutna memorijska rješenja toliko su produktivna da su rezerve tvrtke više nego dovoljne. Ali nas zanima imati posla s liderom, a ne s nekim tko zaostaje, uključujući i test opterećenja.

Tarantool pokriva potrebe tvrtke čak i dugoročno.

TCO trošak. Podrška za Couchbase na MegaFon volumenima košta astronomske iznose novca, ali s Tarantoolom situacija je mnogo ugodnija, a slični su u funkcionalnosti.

Još jedna zgodna značajka koja je malo utjecala na naš izbor je ta da Tarantool bolje radi s memorijom nego druge baze podataka. On pokazuje maksimalnu učinkovitost.

Pouzdanost. MegaFon ulaže u pouzdanost, vjerojatno više nego itko drugi. Pa kad smo pogledali Tarantool, shvatili smo da ga moramo prilagoditi našim zahtjevima.

Uložili smo svoje vrijeme i financije, te smo zajedno s Mail.ru stvorili verziju za poduzeća, koja se sada koristi u nekoliko drugih tvrtki.

Tarantool-enterprise nas je u potpunosti zadovoljio u pogledu sigurnosti, pouzdanosti i logiranja.

partnerstvo

Najvažnije mi je izravan kontakt s programerom. Upravo su to podmitili dečki iz Tarantoola.

Ako dođete igraču, pogotovo onom koji radi s anchor klijentom, i kažete da vam treba baza podataka da biste mogli ovo, to i ovo, on obično odgovori:

- U redu, stavi zahtjeve na dno te hrpe - jednog dana ćemo vjerojatno doći do njih.

Mnogi imaju plan puta za iduće 2-3 godine i tu je gotovo nemoguće integrirati, ali Tarantool programeri osvajaju svojom otvorenošću, i to ne samo od MegaFona, i prilagođavaju svoj sustav kupcu. Super je i jako nam se sviđa.

Gdje smo koristili Tarantool

Tarantool koristimo u nekoliko elemenata. Prvi je u pilotu, koji smo izradili na sustavu adresara. Jedno vrijeme sam želio da to bude sustav sličan Yandex.Maps i Google Maps, ali ispalo je malo drugačije.

Na primjer, katalog adresa u prodajnom sučelju. Na Oracleu traženje željene adrese traje 12-13 sekundi. - neugodni brojevi. Kada se prebacimo na Tarantool, zamijenimo Oracle drugom bazom podataka u konzoli i izvršimo istu pretragu, dobivamo 200x ubrzanje! Grad se pojavljuje nakon trećeg slova. Sada prilagođavamo sučelje tako da se ovo dogodi nakon prvog. Međutim, brzina odgovora je potpuno drugačija - milisekunde umjesto sekundi.

Druga aplikacija je trendi tema nazvana IT s dvije brzine. To je zato što konzultanti sa svih strana govore da bi korporacije trebale ići tamo.

Nova generacija arhitekture naplate: transformacija s prijelazom na Tarantool

Postoji infrastrukturni sloj, iznad njega postoje domene, na primjer, sustav naplate poput telekoma, korporativni sustavi, korporativno izvještavanje. Ovo je srž koju ne treba dirati. To je, naravno, moguće, ali paranoično osiguravanje kvalitete, jer to donosi novac korporaciji.

Slijedi sloj mikroservisa - ono što razlikuje operatera ili drugog igrača. Mikroservisi se mogu brzo kreirati na temelju određenih predmemorija, dovodeći podatke iz različitih domena tamo. Ovdje polje za eksperimente — ako nešto nije išlo, zatvorio sam jedan mikroservis i otvorio drugi. To omogućuje istinski produženo vrijeme izlaska na tržište i povećava pouzdanost i brzinu tvrtke.

Mikroservisi su možda glavna uloga Tarantoola u MegaFonu.

Gdje planiramo koristiti Tarantool

Usporedimo li naš uspješan projekt naplate s programima transformacije u Deutsche Telekomu, Svyazcomu, Vodafonu Indija, on je iznenađujuće dinamičan i kreativan. U procesu implementacije ovog projekta transformirani su ne samo MegaFon i njegova struktura, već se i Tarantool-poduzeće pojavilo na Mail.ru, a naš dobavljač Nexign (bivši Peter-Service) - BSS Box (rješenje za naplatu u kutiji).

Ovo je u neku ruku povijesni projekt za rusko tržište. Može se usporediti s onim što je opisano u knjizi “The Mythical Man-Month” Fredericka Brooksa. Zatim, u 60-ima, IBM je zaposlio 360 ljudi da razviju novi operativni sustav OS/5 za velika računala. Imamo ih manje - 000, ali naši su u prslucima, a uzimajući u obzir korištenje open sourcea i novih pristupa, radimo produktivnije.

U nastavku su navedene domene naplate ili, šire govoreći, poslovnih sustava. Ljudi iz poduzeća vrlo dobro poznaju CRM. Svi bi već trebali imati druge sustave: Open API, API Gateway.

Nova generacija arhitekture naplate: transformacija s prijelazom na Tarantool

Otvori API

Pogledajmo ponovno brojke i kako Open API trenutno radi. Njegovo opterećenje je 10 transakcija u sekundi. Budući da planiramo aktivno razvijati sloj mikroservisa i graditi MegaFon javni API, očekujemo veći rast u budućnosti u ovom dijelu. Sigurno će biti 100 transakcija.

Ne znam možemo li se usporediti s Mail.ru u SSO - čini se da momci imaju 1 transakcija u sekundi. Njihovo rješenje nam je iznimno zanimljivo i planiramo usvojiti njihovo iskustvo - primjerice, napraviti funkcionalnu SSO sigurnosnu kopiju pomoću Tarantoola. Sada programeri iz Mail.ru to rade za nas.

CRM

CRM je istih 80 milijuna pretplatnika koje želimo povećati na milijardu, jer već postoji 300 milijuna dokumenata koji uključuju trogodišnju povijest. Jako se veselimo novim uslugama i ovdje točka rasta su povezane usluge. Ovo je lopta koja će rasti, jer će usluga biti sve više. Sukladno tome, trebat će nam priča; ne želimo se spotaknuti o ovo.

Sama naplata u smislu izdavanja računa, rad s potraživanjima kupaca pretvoriti u zasebnu domenu. Za poboljšanje performansi, primijenjena domenska arhitektura architectural pattern.

Sustav je podijeljen na domene, opterećenje je raspoređeno i osigurana je tolerancija na greške. Osim toga, radili smo s distribuiranom arhitekturom.

Sve ostalo su rješenja na razini poduzeća. U spremištu poziva - 2 milijarde dnevno, 60 milijardi mjesečno. Ponekad ih morate prebrojati za mjesec dana, a bolje je brzo. Financijski nadzor - to je točno istih 300 milijuna koji stalno rastu i rastu: pretplatnici često trče između operatera, povećavajući ovaj dio.

Najtelekomunikacijskija komponenta mobilnih komunikacija je online naplata. To su sustavi koji vam omogućuju nazvati ili ne nazvati, donositi odluke u stvarnom vremenu. Ovdje je opterećenje 30 transakcija u sekundi, ali uzimajući u obzir rast prijenosa podataka, planiramo 250 transakcija, i stoga smo vrlo zainteresirani za Tarantool.

Prethodna slika je domena na kojoj ćemo koristiti Tarantool. Sam CRM je, naravno, širi i koristit ćemo ga u samoj jezgri.

Naša procijenjena TTX brojka od 100 milijuna pretplatnika zbunjuje me kao arhitekta - što ako 101 milijun? Morate li sve ponovno ponoviti? Kako bismo spriječili da se to dogodi, koristimo predmemorije, istovremeno povećavajući dostupnost.

Nova generacija arhitekture naplate: transformacija s prijelazom na Tarantool

Općenito, postoje dva pristupa korištenju Tarantoola. Prvo - izgraditi sve predmemorije na razini mikroservisa. Koliko ja razumijem, VimpelCom slijedi ovaj put, stvarajući predmemoriju klijenata.

Manje ovisimo o dobavljačima, mijenjamo jezgru BSS-a, tako da imamo jednu klijentsku datoteku iz kutije. Ali mi ga želimo proširiti. Stoga imamo malo drugačiji pristup - napraviti predmemorije unutar sustava.

Na ovaj način postoji manje sinkronizacije - jedan sustav je odgovoran i za predmemoriju i za glavni glavni izvor.

Metoda se dobro uklapa u Tarantool pristup s transakcijskim kosturom, kada se ažuriraju samo dijelovi koji se odnose na ažuriranja, odnosno promjene podataka. Sve ostalo može se pohraniti negdje drugdje. Ne postoji veliko podatkovno jezero, neupravljana globalna predmemorija. Predmemorije su dizajnirane za sustav, ili za proizvode, ili za klijente, ili da olakšaju život za održavanje. Kada pretplatnik nazove i uzrujan je zbog kvalitete vaše usluge, želite pružiti kvalitetnu uslugu.

RTO i RPO

U IT-u postoje dva pojma - OTR и RPO.

Ciljano vrijeme oporavka je vrijeme potrebno za ponovno uspostavljanje usluge nakon kvara. RTO = 0 znači da čak i ako nešto ne uspije, usluga nastavlja raditi.

Cilj točke oporavka - ovo je vrijeme oporavka podataka, koliko podataka možemo izgubiti u određenom vremenskom razdoblju. RPO = 0 znači da ne gubimo podatke.

Tarantool zadatak

Pokušajmo riješiti problem za Tarantool.

S obzirom na to: košarica aplikacija koje svi razumiju, na primjer, u Amazonu ili negdje drugdje. potreban tako da košarica radi 24 sata 7 dana u tjednu, odnosno 99,99% vremena. Nalozi koji nam dolaze moraju ostati u redu, jer ne možemo nasumično uključiti ili isključiti pretplatničku vezu - sve mora biti strogo dosljedno. Prethodna pretplata utječe na sljedeću, stoga su podaci važni - ništa ne smije nedostajati.

odluka. Možete ga pokušati riješiti izravno i pitati programere baze podataka, ali problem se ne može riješiti matematički. Možete se sjetiti teorema, zakona očuvanja, kvantne fizike, ali zašto - to se ne može riješiti na razini DB-a.

Ovdje funkcionira stari dobri arhitektonski pristup - morate dobro poznavati predmetno područje i njime riješiti ovu zagonetku.

Nova generacija arhitekture naplate: transformacija s prijelazom na Tarantool

Naše rješenje: kreiranje distribuiranog registra aplikacija na Tarantoolu - geo-distribuirani klaster. U dijagramu su to tri različita centra za obradu podataka - dva prije Urala, jedan iza Urala i sve zahtjeve raspodjeljujemo po tim centrima.

Netflix, koji se danas smatra jednim od vodećih u IT-u, do 2012. imao je samo jedan podatkovni centar. Uoči katoličkog Božića, 24. prosinca, došlo je do prekida rada ovog podatkovnog centra. Korisnici u Kanadi i SAD-u ostali su bez svojih omiljenih filmova, bili su jako uzrujani i pisali o tome na društvenim mrežama. Netflix sada ima tri podatkovna centra na zapadno-istočnoj obali i jedan u zapadnoj Europi.

U početku gradimo geo-distribuirano rješenje - važna nam je tolerancija na pogreške.

Dakle, imamo klaster, ali što je s RPO = 0 i RTO = 0? Rješenje je jednostavno, ovisno o predmetu.

Što je važno u aplikacijama? Dva dijela: bacanje u koš tO donošenje odluke o kupnji i NAKON. DO dio u telekomu se obično zove hvatanje reda ili pregovaranje o narudžbi. U telekomu to zna biti puno teže nego u online trgovini, jer tamo se klijenta mora uslužiti, ponuditi mu 5 opcija, i to se sve događa neko vrijeme, ali košarica je puna. U ovom trenutku kvar je moguć, ali nije strašan, jer se događa interaktivno pod ljudskim nadzorom.

Ako moskovski podatkovni centar iznenada zakaže, automatskim prelaskom na drugi podatkovni centar nastavit ćemo s radom. Teoretski, jedan proizvod se može izgubiti u košarici, ali vi ga vidite, ponovno dodate u košaricu i nastavite s radom. U ovom slučaju RTO = 0.

U istom trenutku postoji i druga opcija: kada kliknemo na "pošalji", želimo da se podaci ne izgube. Od ovog trenutka počinje djelovati automatizacija - to je RPO = 0. Koristeći ova dva različita obrasca, u jednom slučaju to bi jednostavno mogao biti geo-distribuirani klaster s jednim promjenjivim masterom, u drugom slučaju neka vrsta zapisa kvoruma. Uzorci mogu varirati, ali mi rješavamo problem.

Nadalje, imajući distribuirani registar aplikacija, možemo sve to skalirati - imati mnogo dispečera i izvršitelja koji pristupaju tom registru.

Nova generacija arhitekture naplate: transformacija s prijelazom na Tarantool

Cassandra i Tarantool zajedno

Postoji još jedan slučaj - "izlog stanja". Evo zanimljivog slučaja zajedničkog korištenja Cassandre i Tarantoola.

Koristimo Cassandru jer 2 milijarde poziva dnevno nije granica, a bit će ih još. Marketinški stručnjaci vole bojati promet prema izvoru, sve više detalja se pojavljuje na društvenim mrežama, primjerice. Sve to pridonosi priči.

Cassandra vam omogućuje vodoravno skaliranje na bilo koju veličinu.

Osjećamo se ugodno s Cassandrom, ali ima jedan problem - nije dobra u čitanju. Na snimci je sve ok, 30 u sekundi nije problem - problem čitanja.

Stoga se pojavila tema s cacheom, a ujedno smo riješili sljedeći problem: postoji stari tradicionalni slučaj kada oprema iz switcha iz online naplate dolazi u datoteke koje učitavamo u Cassandru. Borili smo se s problemom pouzdanog preuzimanja ovih datoteka, čak i koristeći savjet IBM-ovog upravitelja prijenosa datoteka - postoje rješenja koja učinkovito upravljaju prijenosom datoteka, koristeći, na primjer, UDP protokol, a ne TCP. Ovo je dobro, ali to su još minute, a još nismo sve učitali, operater u pozivnom centru ne može odgovoriti klijentu što je s njegovim stanjem - moramo čekati.

Da se to ne dogodi, mi koristimo paralelnu funkcionalnu rezervu. Kada pošaljemo događaj preko Kafke u Tarantool, preračunavajući agregate u stvarnom vremenu, na primjer, za danas, dobivamo stanja gotovine, koji može prenositi stanja bilo kojom brzinom, na primjer, 100 tisuća transakcija u sekundi i te iste 2 sekunde.

Cilj je da nakon upućivanja poziva u roku od 2 sekunde na vašem osobnom računu ne bude samo promijenjeno stanje, već i informacija o tome zašto se promijenilo.

Zaključak

Ovo su bili primjeri korištenja Tarantoola. Jako nam se svidjela otvorenost Mail.ru-a i njihova spremnost da razmotre različite slučajeve.

Konzultantima iz BCG-a ili McKinseya, Accenturea ili IBM-a već je teško iznenaditi nas nečim novim - velik dio onoga što oni nude mi već radimo, već smo napravili ili planiramo napraviti. Mislim da će Tarantool zauzeti mjesto koje mu pripada u našem tehnološkom nizu i da će zamijeniti mnoge postojeće tehnologije. U aktivnoj smo fazi razvoja ovog projekta.

Izvještaj Olega i Andreja jedan je od najboljih na prošlogodišnjoj Tarantool konferenciji, a 17. lipnja Oleg Ivlev će govoriti na T+ konferencija 2019 s izvješćem “Zašto Tarantool u Enterpriseu”. Alexander Deulin također će održati prezentaciju MegaFona "Tarantool predmemorije i replikacija iz Oraclea". Saznajmo što se promijenilo, koji su planovi provedeni. Pridružite se - konferencija je besplatna, sve što trebate učiniti je registar... svi izvješća prihvaćena i program konferencije je formiran: novi slučajevi, nova iskustva u korištenju Tarantoola, arhitektura, enterprise, tutoriali i mikroservisi.

Izvor: www.habr.com

Dodajte komentar