Miksi MegaFonin kaltainen yritys tarvitsee Tarantolia laskutukseen? Ulkopuolelta näyttää siltä, että myyjä yleensä tulee, tuo jonkinlaisen ison laatikon, kytkee pistokkeen pistorasiaan - ja se on laskutus! Näin oli joskus, mutta nyt se on arkaaista, ja tällaiset dinosaurukset ovat jo kuolleet sukupuuttoon tai sukupuuttoon tulossa. Aluksi laskutus on laskujen laatimisjärjestelmä - laskentakone tai laskin. Nykyaikaisessa televiestinnässä tämä on automaatiojärjestelmä tilaajan kanssa käymisen koko elinkaarelle sopimuksen tekemisestä irtisanomiseen, mukaan lukien reaaliaikainen laskutus, maksujen hyväksyminen ja paljon muuta. Laskutus tietoliikenneyrityksissä on kuin taistelurobotti - suuri, tehokas ja täynnä aseita.
Mitä tekemistä Tarantoolilla on sen kanssa? He puhuvat siitä Oleg Ivlev и Andrei Knyazev. Oleg on yrityksen pääarkkitehti Andreylla on laaja kokemus ulkomaisissa yrityksissä työskentelystä ja hän on liiketoimintajärjestelmien johtaja. Heidän raporttinsa pöytäkirjasta opit, miksi yrityksissä tarvitaan T&K:ta, mitä Tarantool on, kuinka vertikaalisen skaalauksen ja globalisaation umpikujasta tuli edellytyksiä tämän tietokannan ilmestymiselle yritykseen, teknologisista haasteista, arkkitehtonisista muutoksista ja kuinka MegaFonin teknostack muistuttaa Netflixiä , Google ja Amazon.
Projekti "Unified Billing"
Kyseinen projekti on nimeltään "Unified Billing". Täällä Tarantool osoitti parhaat puolensa.
Hi-End-laitteiden tuottavuuden kasvu ei pysynyt tilaajakannan kasvun ja palveluiden määrän kasvun tahdissa, vaan tilaajamäärän ja palveluiden määrän kasvua odotettiin edelleen M2M:n, IoT:n ja toimialan ominaisuuksien johdosta. markkinoilletuloajan heikkenemiseen. Yhtiö päätti luoda yhtenäisen liiketoimintajärjestelmän ainutlaatuisella maailmanluokan modulaarisella arkkitehtuurilla nykyisen 8 erilaisen laskutusjärjestelmän sijaan.
MegaFon on kahdeksan yritystä yhdessä. Vuonna 2009 uudelleenjärjestely saatettiin päätökseen: sivuliikkeet kaikkialla Venäjällä sulautuivat yhdeksi yhtiöksi, MegaFon OJSC:ksi (nykyisin PJSC). Näin ollen yrityksellä on 8 laskutusjärjestelmää, joissa on omat ”mukautetut” ratkaisut, toimialan ominaisuudet ja erilaiset organisaatiorakenteet, IT ja markkinointi.
Kaikki oli hyvin, kunnes meidän oli lanseerattava yksi yhteinen liittovaltion tuote. Täällä syntyi paljon vaikeuksia: joillekin tariffit pyöristetään ylöspäin, toisille alaspäin ja toisille - aritmeettisen keskiarvon perusteella. Tällaisia hetkiä on tuhansia.
Huolimatta siitä, että laskutusjärjestelmästä oli vain yksi versio, yksi toimittaja, asetukset erosivat niin paljon, että niiden kokoaminen kesti kauan. Yritimme vähentää niiden määrää ja törmäsimme toiseen ongelmaan, joka on tuttu monille yrityksille.
Pystysuuntainen skaalaus. Edes tuolloin tyylikkäin laitteisto ei vastannut tarpeita. Käytimme Superdome Hi-End -linjan Hewlett-Packardin laitteita, mutta se ei vastannut kahden toimipisteen tarpeita. Halusin vaakasuuntaisen skaalauksen ilman suuria käyttökustannuksia ja pääomasijoituksia.
Tilaajamäärän ja palveluiden kasvuodotukset. Konsultit ovat jo pitkään tuoneet tarinoita IoT:stä ja M2M:stä tietoliikennemaailmaan: tulee aika, jolloin jokaisessa puhelimessa ja silitysraudassa on SIM-kortti ja kaksi jääkaapissa. Tänään meillä on yksi määrä tilaajia, mutta lähitulevaisuudessa niitä tulee paljon lisää.
Tekniset haasteet
Nämä neljä syytä motivoivat meitä tekemään vakavia muutoksia. Valittavana oli järjestelmän päivittäminen ja suunnittelu alusta alkaen. Mietimme pitkään, teimme vakavia päätöksiä, pelasimme tarjouskilpailuja. Tämän seurauksena päätimme suunnitella alusta alkaen ja tartuimme mielenkiintoisiin haasteisiin - teknologisiin haasteisiin.
Skaalautuvuus
Jos se oli ennen, sanotaan, sanotaan 8 laskutusta 15 miljoonalle tilaajalle, ja nyt sen olisi pitänyt toimia 100 miljoonaa tilaajaa ja enemmän - kuorma on suuruusluokkaa suurempi.
Meistä on tullut mittakaavaltaan verrattavissa suuriin Internet-peleihin, kuten Mail.ru tai Netflix.
Mutta jatkuva liike kuormituksen ja tilaajakunnan lisäämiseksi on asettanut meille vakavia haasteita.
Valtavan maamme maantiede
Kaliningradin ja Vladivostokin välillä 7500 km ja 10 aikavyöhykettä. Valon nopeus on rajallinen ja tällaisilla etäisyyksillä viiveet ovat jo merkittäviä. 150 ms tyylikkäimmillä moderneilla optisilla kanavilla on liikaa reaaliaikaiseen laskutukseen, varsinkin kun se on nyt Venäjän televiestinnässä. Lisäksi sinun on päivitettävä yhden arkipäivän aikana, ja eri aikavyöhykkeillä tämä on ongelma.
Emme tarjoa palveluita vain tilausmaksua vastaan, vaan meillä on monimutkaisia tariffeja, paketteja ja erilaisia modifikaatioita. Meidän ei tarvitse vain sallia tai kieltää tilaaja puhua, vaan antaa hänelle tietty kiintiö - laskea puhelut ja toimet reaaliajassa, jotta hän ei huomaa.
vikasietoisuus
Tämä on keskittämisen toinen puoli.
Jos keräämme kaikki tilaajat yhteen järjestelmään, kaikki hätätapahtumat ja katastrofit ovat tuhoisia yrityksille. Siksi suunnittelemme järjestelmän siten, että onnettomuuksien vaikutukset koko tilaajakuntaan eliminoidaan.
Tämä on jälleen seurausta vertikaalisesta mittakaavasta kieltäytymisestä. Kun skaalaamme vaakasuunnassa, lisäsimme palvelimien määrää sadasta tuhansiin. Niitä on hallittava ja vaihdettava, varmuuskopioitava automaattisesti IT-infrastruktuuri ja palautettava hajautettu järjestelmä.
Kohtasimme niin mielenkiintoisia haasteita. Suunnittelimme järjestelmän, ja sillä hetkellä yritimme löytää maailmanlaajuisia parhaita käytäntöjä tarkistaaksemme, kuinka trendikkäitä olemme, kuinka paljon seuraamme edistyksellistä teknologiaa.
Maailman kokemus
Yllättäen emme löytäneet ainuttakaan referenssiä maailmanlaajuisesta telekommunikaatiosta.
Eurooppa on pudonnut tilaajamäärän ja mittakaavan suhteen, Yhdysvallat - tariffiensa tasaisuuden suhteen. Tarkastelimme joitakin Kiinassa ja löysimme joitain Intiasta ja palkkasimme asiantuntijoita Vodafone Indiasta.
Arkkitehtuurin analysoimiseksi kokosimme Dream Teamin, jota johti IBM - arkkitehtejä eri aloilta. Nämä ihmiset pystyivät arvioimaan riittävästi, mitä olimme tekemässä, ja tuoda tiettyä tietoa arkkitehtuuriimme.
asteikko
Muutama numero havainnollistamiseksi.
Suunnittelemme järjestelmän 80 miljoonaa tilaajaa miljardin reservillä. Näin poistamme tulevaisuuden kynnykset. Tämä ei johdu siitä, että aiomme valtaa Kiinan, vaan IoT:n ja M2M:n hyökkäyksestä.
300 miljoonaa asiakirjaa käsitellään reaaliajassa. Vaikka meillä on 80 miljoonaa tilaajaa, teemme yhteistyötä sekä potentiaalisten asiakkaiden että meiltä lähteneiden kanssa, jos tarvitsemme saatavia. Siksi todelliset määrät ovat huomattavasti suurempia.
2 miljardia transaktiota Saldo muuttuu päivittäin - nämä ovat maksuja, kuluja, puheluita ja muita tapahtumia. 200 TB dataa muuttuu aktiivisesti, vaihda hieman hitaammin 8 PB dataa, ja tämä ei ole arkisto, vaan live-tiedot yhdessä laskutuksessa. Mittakaava palvelinkeskuksen mukaan - 5 tuhatta palvelinta 14 sivustolla.
Teknologiapino
Kun suunnittelimme arkkitehtuuria ja aloitimme järjestelmän kokoamisen, toimme maahan mielenkiintoisimmat ja edistyneimmät teknologiat. Tuloksena on teknologiapino, joka on tuttu kaikille Internet-pelaajille ja suuria kuormituksia valmistaville yrityksille.
Pino on samanlainen kuin muiden suurten pelaajien pinot: Netflix, Twitter, Viber. Se koostuu kuudesta osasta, mutta haluamme lyhentää ja yhtenäistää sitä.
Joustavuus on hyvä asia, mutta suuressa yhtiössä ei tule ilman yhdistämistä.
Emme aio muuttaa samaa Oraclea Tarantooliksi. Suuryritysten todellisuudessa tämä on utopiaa tai 5-10 vuoden ristiretkeä, jonka lopputulos on epäselvä. Mutta Cassandra ja Couchbase voidaan helposti korvata Tarantoolilla, ja siihen pyrimme.
Miksi Tarantool?
On 4 yksinkertaista kriteeriä, miksi valitsimme tämän tietokannan.
Nopeus. Teimme kuormitustestejä MegaFonin teollisuusjärjestelmille. Tarantool voitti - se osoitti parasta suorituskykyä.
Tämä ei tarkoita, että muut järjestelmät eivät täytä MegaFonin tarpeita. Nykyiset muistiratkaisut ovat niin tuottavia, että yrityksen reservit ovat enemmän kuin tarpeeksi. Mutta olemme kiinnostuneita olemaan tekemisissä johtajan kanssa, emme jonkun jälkeen, joka on jälkeenjäänyt, myös kuormitustestissä.
Tarantool kattaa yrityksen tarpeet myös pitkällä aikavälillä.
TCO-kustannukset. Couchbasen tuki MegaFon-volyymeilla maksaa tähtitieteellisiä summia, mutta Tarantoolilla tilanne on paljon miellyttävämpi, ja ne ovat toiminnaltaan samanlaisia.
Toinen hieno ominaisuus, joka hieman vaikutti valintaamme, on se, että Tarantool toimii paremmin muistin kanssa kuin muut tietokannat. Hän näyttää maksimaalinen tehokkuus.
Luotettavuus. MegaFon panostaa luotettavuuteen, luultavasti enemmän kuin kukaan muu. Joten kun tarkastelimme Tarantoolia, ymmärsimme, että meidän oli saatava se vastaamaan vaatimuksiamme.
Investoimme aikamme ja rahamme ja loimme yhdessä Mail.ru:n kanssa yritysversion, joka on nyt käytössä useissa muissa yrityksissä.
Tarantool-yritys tyydytti meidät täysin turvallisuuden, luotettavuuden ja kirjauksen suhteen.
kumppanuus
Minulle tärkeintä on suora yhteys kehittäjään. Juuri tällä Tarantoolin kaverit lahjoivat.
Jos tulet pelaajan luo, varsinkin sellaisen, joka työskentelee ankkuriasiakkaan kanssa, ja sanot, että tarvitset tietokannan voidaksesi tehdä tämän, tämän ja tämän, hän yleensä vastaa:
- Okei, laita vaatimukset tuon pinon pohjalle - jonain päivänä me luultavasti pääsemme niihin.
Monilla on tiekartta seuraaville 2-3 vuodelle, ja sinne on lähes mahdotonta integroida, mutta Tarantool-kehittäjät valloittavat avoimuudellaan, ei vain MegaFonilta, ja mukauttavat järjestelmänsä asiakkaalle. Se on siistiä ja pidämme siitä todella.
Missä käytimme Tarantoolia
Käytämme Tarantolia useissa elementeissä. Ensimmäinen on pilotissa, jonka teimme osoitehakemistojärjestelmässä. Aikoinaan halusin sen olevan järjestelmä, joka oli samanlainen kuin Yandex.Maps ja Google Maps, mutta se osoittautui hieman erilaiseksi.
Esimerkiksi myyntiliittymän osoiteluettelo. Oraclessa halutun osoitteen etsiminen kestää 12-13 sekuntia. - epämiellyttäviä numeroita. Kun vaihdamme Tarantooliin, korvaamme Oraclen toisella konsolin tietokannalla ja suoritamme saman haun, saamme 200-kertaisen nopeuden! Kaupunki ponnahtaa esiin kolmannen kirjaimen jälkeen. Nyt mukautamme käyttöliittymää niin, että tämä tapahtuu ensimmäisen jälkeen. Vastausnopeus on kuitenkin täysin erilainen - millisekunteja sekuntien sijaan.
Toinen sovellus on trendikäs teema nimeltä kaksinopeuksinen IT. Tämä johtuu siitä, että konsultit joka kulmasta sanovat, että yritysten pitäisi mennä sinne.
On infrastruktuurikerros, sen yläpuolella on toimialueet, esimerkiksi laskutusjärjestelmä, kuten tietoliikenne, yritysjärjestelmät, yritysraportointi. Tämä on ydin, jota ei tarvitse koskea. Se on tietysti mahdollista, mutta vainoharhaisesti laadun varmistaminen, koska se tuo rahaa yritykselle.
Seuraavaksi tulee mikropalvelukerros – mikä erottaa operaattorin tai muun pelaajan. Mikropalveluita voidaan luoda nopeasti tiettyjen välimuistien perusteella, jolloin sinne voidaan tuoda tietoja eri toimialueilta. Tässä kenttä kokeille - Jos jokin ei toiminut, suljin yhden mikropalvelun ja avasin toisen. Tämä pidentää todella markkinoilletuloaikaa ja lisää yrityksen luotettavuutta ja nopeutta.
Mikropalvelut ovat ehkä Tarantoolin päärooli MegaFonissa.
Missä aiomme käyttää Tarantolia
Jos vertaamme onnistunutta laskutusprojektiamme Deutsche Telekomin, Svyazcomin ja Vodafone Indian muutosohjelmiin, se on yllättävän dynaaminen ja luova. Tämän projektin toteuttamisprosessissa ei vain MegaFon ja sen rakenne muuttuneet, vaan myös Tarantool-yritys ilmestyi Mail.ru:hun ja toimittajamme Nexign (entinen Peter-Service) - BSS Box (laatikollinen laskutusratkaisu).
Tämä on tietyssä mielessä historiallinen hanke Venäjän markkinoille. Sitä voidaan verrata siihen, mitä on kuvattu Frederick Brooksin kirjassa "The Mythical Man-Month". Sitten 60-luvulla IBM palkkasi 360 5 ihmistä kehittämään uutta OS/000-käyttöjärjestelmää keskuskoneille. Meillä on vähemmän - 1 800, mutta omamme ovat liiveissä ja avoimen lähdekoodin käyttö ja uudet lähestymistavat huomioon ottaen työskentelemme tuottavammin.
Alla on lueteltu laskutus- tai laajemmin yritysjärjestelmien toimialueet. Yritykset tuntevat CRM:n erittäin hyvin. Kaikilla pitäisi jo olla muita järjestelmiä: Open API, API Gateway.
Avaa API
Katsotaanpa numeroita uudelleen ja kuinka Open API toimii tällä hetkellä. Sen kuormitus on 10 000 tapahtumaa sekunnissa. Koska aiomme kehittää aktiivisesti mikropalvelukerrosta ja rakentaa MegaFon julkisen API:n, odotamme suurempaa kasvua tulevaisuudessa tässä osassa. Kauppoja tulee varmasti 100 000.
En tiedä, voimmeko verrata Mail.ru:hun SSO:ssa - kavereilla näyttää olevan 1 000 0000 tapahtumaa sekunnissa. Heidän ratkaisunsa on meille erittäin mielenkiintoinen ja aiomme omaksua heidän kokemuksensa - esimerkiksi tehdä toimivan SSO-varmuuskopion Tarantoolilla. Nyt Mail.ru:n kehittäjät tekevät tämän puolestamme.
CRM
CRM on samat 80 miljoonaa tilaajaa, jotka haluamme kasvattaa miljardiin, koska dokumentteja on jo 300 miljoonaa, jotka sisältävät kolmen vuoden historian. Odotamme todella innolla uusia palveluita ja täällä Kasvupiste on yhdistetty palvelut. Tämä on pallo, joka kasvaa, koska palveluita tulee yhä enemmän. Siksi tarvitsemme tarinan, emme halua kompastella tähän.
Itse laskutus laskujen laatimisen, asiakassaatavien kanssa työskentelyn osalta muunnetaan erilliseksi verkkotunnukseksi. Suorituskyvyn parantamiseksi, sovelletun verkkoalueen arkkitehtuurin arkkitehtuurimalli.
Järjestelmä on jaettu domeeneihin, kuormitus jakautuu ja vikasietoisuus varmistetaan. Lisäksi työskentelimme hajautetun arkkitehtuurin parissa.
Kaikki muu on yritystason ratkaisuja. Puhelumuistissa - 2 miljardia päivässä, 60 miljardia kuukaudessa. Joskus sinun on laskettava ne kuukaudessa, ja se on parempi nopeasti. Taloudellinen seuranta - tämä on täsmälleen sama 300 miljoonaa, jotka kasvavat ja kasvavat jatkuvasti: tilaajat kulkevat usein operaattoreiden välillä ja lisäävät tätä osaa.
Matkaviestinnän telekommunikaatiokomponentti on verkkolaskutus. Nämä ovat järjestelmiä, joiden avulla voit soittaa tai olla soittamatta, tehdä päätöksiä reaaliajassa. Täällä kuormitus on 30 000 tapahtumaa sekunnissa, mutta tiedonsiirron kasvu huomioon ottaen suunnittelemme 250 000 tapahtumaa, ja siksi olemme erittäin kiinnostuneita Tarantoolista.
Edellinen kuva on verkkotunnukset, joilla aiomme käyttää Tarantolia. CRM itsessään on tietysti laajempi ja aiomme käyttää sitä itse ytimessä.
Arvioitu TTX-tilaajamme 100 miljoonaa hämmentää minua arkkitehtina - entä jos 101 miljoonaa? Pitääkö kaikki tehdä uudestaan? Tämän estämiseksi käytämme välimuistia ja samalla lisäämme saavutettavuutta.
Tarantoolin käyttöön on yleensä kaksi tapaa. Ensimmäinen - rakentaa kaikki välimuistit mikropalvelutasolle. Ymmärtääkseni VimpelCom seuraa tätä polkua luoden asiakkaiden välimuistin.
Olemme vähemmän riippuvaisia toimittajista, muutamme BSS-ydintä, joten meillä on yksi asiakastiedosto valmiina. Mutta haluamme laajentaa sitä. Siksi otamme hieman erilaisen lähestymistavan - tehdä välimuistia järjestelmien sisällä.
Näin synkronointia on vähemmän - yksi järjestelmä vastaa sekä välimuistista että päälähteestä.
Menetelmä sopii hyvin Tarantool-lähestymistapaan, jossa on transaktiorunko, jolloin vain päivityksiä eli datamuutoksia koskevat osat päivitetään. Kaikki muu voidaan säilyttää muualla. Ei ole olemassa valtavaa datajärveä, hallitsematonta globaalia välimuistia. Välimuistit on suunniteltu järjestelmää, tuotteita tai asiakkaita varten tai helpottamaan elämää ylläpitoa varten. Kun tilaaja soittaa ja on järkyttynyt palvelusi laadusta, haluat tarjota laadukasta palvelua.
RTO ja RPO
IT:ssä on kaksi termiä - RTO и RPO.
Toipumisajan tavoite on aika, joka kuluu palvelun palauttamiseen vian jälkeen. RTO = 0 tarkoittaa, että vaikka jokin epäonnistuisi, palvelu jatkaa toimintaansa.
Palautumispisteen tavoite - Tämä on tietojen palautusaika, kuinka paljon tietoja voimme menettää tietyn ajanjakson aikana. RPO = 0 tarkoittaa, että emme menetä tietoja.
Tarantool tehtävä
Yritetään ratkaista Tarantoolin ongelma.
Annettu: sovelluskori, jonka kaikki ymmärtävät, esimerkiksi Amazonissa tai jossain muualla. edellytetään niin, että ostoskori toimii 24 tuntia 7 päivää viikossa eli 99,99 % ajasta. Meille tulevien tilausten on pysyttävä järjestyksessä, koska emme voi satunnaisesti kytkeä päälle tai pois tilaajan yhteyttä - kaiken on oltava tiukasti johdonmukaista. Edellinen tilaus vaikuttaa seuraavaan, joten tiedot ovat tärkeitä - mitään ei pitäisi kadota.
päätös. Voit yrittää ratkaista sen suoraan ja kysyä tietokannan kehittäjiltä, mutta ongelmaa ei voida ratkaista matemaattisesti. Voit muistaa lauseita, säilymislakeja, kvanttifysiikkaa, mutta miksi - sitä ei voida ratkaista DB-tasolla.
Vanha kunnon arkkitehtoninen lähestymistapa toimii täällä - sinun on tunnettava aihealue hyvin ja käytettävä sitä tämän pulman ratkaisemiseen.
Ratkaisumme: hajautetun sovellusrekisterin luominen Tarantoolissa - maantieteellisesti hajautettuun klusteriin. Kaaviossa nämä ovat kolme erilaista tietojenkäsittelykeskusta - kaksi ennen Uralia, yksi Uralin takana, ja jaamme kaikki pyynnöt näiden keskusten kesken.
Netflixillä, jota nykyään pidetään yhtenä IT-alan johtajista, oli vuoteen 2012 asti vain yksi datakeskus. Katolisen joulun aattona 24. joulukuuta tämä palvelinkeskus hajosi. Käyttäjät Kanadassa ja USA:ssa jäivät ilman suosikkielokuviaan, olivat hyvin järkyttyneitä ja kirjoittivat siitä sosiaalisiin verkostoihin. Netflixillä on nyt kolme datakeskusta länsi-itärannikolla ja yksi Länsi-Euroopassa.
Rakennamme aluksi maantieteellisesti hajautettua ratkaisua – vikasietoisuus on meille tärkeää.
Meillä on siis klusteri, mutta entä RPO = 0 ja RTO = 0? Ratkaisu on yksinkertainen, riippuen aiheesta.
Mikä sovelluksissa on tärkeää? Kaksi osaa: Korinheitto tO ostopäätöksen tekeminen ja JÄLKEEN. DO-osaa telekommunikaatiossa kutsutaan yleensä tilauksen sieppaus tai tilausneuvottelu. Telecomissa tämä voi olla paljon vaikeampaa kuin verkkokaupassa, koska siellä asiakasta pitää palvella, tarjota 5 vaihtoehtoa, ja tätä kaikkea tapahtuu jonkin aikaa, mutta kori täyttyy. Tällä hetkellä epäonnistuminen on mahdollista, mutta se ei ole pelottavaa, koska se tapahtuu interaktiivisesti ihmisen valvonnassa.
Jos Moskovan palvelinkeskus epäonnistuu yhtäkkiä, jatkamme työtä vaihtamalla automaattisesti toiseen palvelinkeskukseen. Teoriassa yksi tuote voi kadota ostoskoriin, mutta näet sen, lisäät ostoskoriin uudelleen ja jatkat työskentelyä. Tässä tapauksessa RTO = 0.
Samaan aikaan on toinen vaihtoehto: kun napsautimme "lähetä", haluamme, että tiedot eivät katoa. Tästä hetkestä lähtien automaatio alkaa toimia - tämä on RPO = 0. Näitä kahta eri mallia käyttämällä se voisi yhdessä tapauksessa olla yksinkertaisesti maantieteellisesti hajautettu klusteri, jossa on yksi kytkettävä isäntä, toisessa tapauksessa jonkinlainen koorumitietue. Mallit voivat vaihdella, mutta me ratkaisemme ongelman.
Lisäksi, koska meillä on hajautettu sovellusrekisteri, voimme myös skaalata sen kaiken - meillä on monia lähettäjiä ja toimeenpanijoita, jotka käyttävät tätä rekisteriä.
Cassandra ja Tarantool yhdessä
On toinenkin tapaus - "saldoesittely". Tässä on mielenkiintoinen tapaus Cassandran ja Tarantoolin yhteiskäytöstä.
Käytämme Cassandraa, koska 2 miljardia puhelua päivässä ei ole raja, ja niitä tulee lisää. Markkinoijat värittävät mielellään liikennettä lähteen mukaan, esimerkiksi sosiaalisiin verkostoihin ilmestyy yhä enemmän yksityiskohtia. Se kaikki lisää tarinaa.
Cassandra antaa sinun skaalata vaakasuunnassa mihin tahansa kokoon.
Tunnemme olomme mukavaksi Cassandran kanssa, mutta sillä on yksi ongelma - se ei ole hyvä lukemaan. Kaikki on kunnossa tallennuksessa, 30 000 sekunnissa ei ole ongelma - lukuongelma.
Siksi ilmestyi aihe, jossa oli välimuisti, ja samalla ratkaisimme seuraavan ongelman: on vanha perinteinen tapaus, kun verkkolaskutuksen vaihdon laitteet tulevat tiedostoihin, jotka lataamme Cassandraan. Kamppailimme näiden tiedostojen luotettavan lataamisen ongelman kanssa jopa IBM Manager -tiedostonsiirron neuvojen avulla - on olemassa ratkaisuja, jotka hallitsevat tiedostonsiirtoa tehokkaasti käyttämällä esimerkiksi UDP-protokollaa TCP:n sijaan. Tämä on hyvä, mutta se on vielä minuutteja, emmekä ole vielä ladanneet kaikkea, puhelinkeskuksen operaattori ei voi vastata asiakkaalle, mitä hänen saldolleen tapahtui - meidän on odotettava.
Tämän estämiseksi me käytämme rinnakkaista toiminnallista varausta. Kun lähetämme tapahtuman Kafkan kautta Tarantoolille laskemalla aggregaatit reaaliajassa uudelleen esimerkiksi tältä päivältä, saamme käteisvarat, joka voi siirtää saldoja millä tahansa nopeudella, esimerkiksi 100 tuhatta tapahtumaa sekunnissa ja samat 2 sekuntia.
Tavoitteena on, että puhelun soittamisen jälkeen henkilökohtaisella tililläsi ei ole vain muuttunutta saldoa, vaan myös tietoa siitä, miksi se muuttui.
Johtopäätös
Nämä olivat esimerkkejä Tarantoolin käytöstä. Pidimme todella Mail.ru:n avoimuudesta ja halukkuudesta pohtia erilaisia tapauksia.
BCG:n tai McKinseyn, Accenturen tai IBM:n konsulttien on jo vaikea yllättää meidät jollakin uudella - suurimman osan heidän tarjoamastaan olemme jo tekemässä, olemme tehneet tai aiomme tehdä. Uskon, että Tarantool ottaa sille kuuluvan paikkansa teknologiapinossamme ja korvaa monia olemassa olevia teknologioita. Olemme tämän hankkeen aktiivisessa kehitysvaiheessa.
Olegin ja Andreyn raportti on yksi viime vuoden Tarantool-konferenssin parhaista, ja 17. kesäkuuta Oleg Ivlev puhuu klo. raportin kanssa . Alexander Deulin pitää myös MegaFonin esityksen . Selvitetään, mikä on muuttunut, mitä suunnitelmia on toteutettu. Liity - konferenssi on ilmainen, sinun tarvitsee vain . kaikki ja konferenssin ohjelma on muotoiltu: uusia tapauksia, uutta kokemusta Tarantoolin käytöstä, arkkitehtuuria, yritystoimintaa, tutoriaaleja ja mikropalveluita.
Lähde: will.com