{"id":37650,"date":"2019-10-31T22:18:50","date_gmt":"2019-10-31T19:18:50","guid":{"rendered":"https:\/\/prohoster.info\/blog\/arhitektura-billinga-novogo-pokoleniya-transformatsiya-s-perehodom-na-tarantool\/"},"modified":"2019-10-31T22:18:50","modified_gmt":"2019-10-31T19:18:50","slug":"arhitektura-billinga-novogo-pokoleniya-transformatsiya-s-perehodom-na-tarantool","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/arhitektura-billinga-novogo-pokoleniya-transformatsiya-s-perehodom-na-tarantool","title":{"rendered":"Fremtidens betalingsarkitektur: transformation med overgang til Tarantool","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hvorfor har en virksomhed som MegaFon brug for Tarantool i faktureringen? Udefra ser det ud til, at en leverand\u00f8r normalt kommer, bringer en stor kasse, s\u00e6tter stikket i stikkontakten - og s\u00e5 er faktureringen klar! Det var engang s\u00e5dan, men nu er det for\u00e6ldet, og s\u00e5danne dinosaurer er allerede udd\u00f8dt eller er p\u00e5 vej til at udd\u00f8. Oprindeligt var fakturering et system til at udstede regninger - en regnemaskine eller kalkulator. I den moderne telekomverden er det et system til automatisering af hele livscyklussen for interaktion med abonnenten fra indg\u00e5else af kontrakt til opsigelse<\/b>, inklusiv real-time taksering, modtagelse af betalinger og meget mere. Fakturering i telekomfirmaer ligner en kamprobot - stor, st\u00e6rk og udstyret med v\u00e5ben.<\/p>\n

\"Fremtidens
\n
\nHvad har Tarantool at g\u00f8re med dette? Det vil Oleg Ivlev<\/b> og\u00a0Andrey Knyazev<\/b>. Oleg er hovedarkitekten for virksomheden MegaFon<\/a><\/noindex> med stor erfaring fra udenlandske virksomheder, Andrey er direkt\u00f8r for forretningssystemer. Fra deres foredrag p\u00e5\u00a0Tarantool Conference 2018<\/a><\/noindex>\u00a0vil du finde ud af, hvorfor R&D er n\u00f8dvendigt i virksomheder, hvad Tarantool er, hvordan begr\u00e6nsningerne ved vertikal skalerbarhed og globalisering blev foruds\u00e6tningerne for denne database i virksomheden, om teknologiske udfordringer, transformation af arkitektur, og hvordan MegaFons teknologistak ligner Netflix, Google og Amazon.
\n<\/a><\/noindex>
\n

\r\n \"Afspil\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Projektet 'Unified Billing'<\/h2>\n

\nProjektet, som vil blive omtalt, hedder 'Unified Billing'. Det var netop her, at Tarantool viste sine bedste egenskaber. <\/p>\n

\"Fremtidens
\n
\nV\u00e6ksten i ydeevnen for Hi-End udstyr kunne ikke f\u00f8lge med v\u00e6ksten i abonnentbasen og antallet af tjenester; der forventedes en yderligere stigning i antallet af abonnenter og tjenester p\u00e5 grund af M2M, IoT, og filialernes s\u00e6regenheder f\u00f8rte til en forv\u00e6rring af time-to-market. Virksomheden besluttede at skabe et enkelt forretningssystem med en unik modul\u00e6r arkitektur af verdensklasse, i stedet for de 8 nuv\u00e6rende forskellige faktureringssystemer.<\/p>\n

MegaFon er otte selskaber i \u00e9t<\/b>. I 2009 blev reorganiseringen afsluttet: filialer over hele Rusland blev samlet i et enkelt selskab, OAO 'MegaFon' (nu PAO). Dermed opstod der 8 faktureringssystemer i virksomheden med deres egne 'custom' l\u00f8sninger, filial-specifikke tr\u00e6k og forskellige organisatoriske strukturer, IT og marketing.<\/p>\n

Alt var godt, indtil vi skulle lancere et f\u00e6lles nationalt produkt. Her opstod der en lang r\u00e6kke udfordringer: Nogen har taksering med afrunding opad, andre nedad, og nogle efter det aritmetiske gennemsnit. Der er tusinder af s\u00e5danne situationer.<\/p>\n

P\u00e5 trods af at versionen af faktureringssystemet er den samme, er der kun \u00e9n leverand\u00f8r, men indstillingerne var s\u00e5 forskellige, at det tog lang tid at limme dem sammen. Vi fors\u00f8gte at reducere antallet af dem og st\u00f8dte p\u00e5 et andet problem, som mange virksomheder kender.<\/p>\n

Vertikal skalering<\/b>. Selv det mest avancerede udstyr p\u00e5 det tidspunkt kunne ikke im\u00f8dekomme behovene. I arbejdet brugte vi Hewlett-Packard-udstyr fra linjen Superdome Hi-End, men det kunne ikke opfylde behovene selv for to filialer. Vi \u00f8nskede horisontal skalering uden store driftsomkostninger og kapitalinvesteringer.<\/p>\n

Forventning om v\u00e6kst i antallet af abonnenter og tjenester<\/b>. Konsulenterne har l\u00e6nge bragt fort\u00e6llinger om IoT og M2M ind i telekomverdenen: Der kommer en tid, hvor der vil v\u00e6re et SIM-kort i hver telefon og strygejern, og to i k\u00f8leskabet. I dag har vi et antal abonnenter, men i den n\u00e6rmeste fremtid vil der v\u00e6re mange gange flere.<\/p>\n

Teknologiske udfordringer<\/h2>\n

\nDisse fire grunde drev os til alvorlige forandringer. Der var et valg mellem at opgradere systemet og designe det fra bunden. Vi t\u00e6nkte l\u00e6nge, traf alvorlige beslutninger og deltog i udbud. I sidste ende besluttede vi at designe fra bunden og tage fat p\u00e5 sp\u00e6ndende udfordringer - teknologiske udfordringer.<\/p>\n

Skalering<\/h3>\n

\nHvis det tidligere var, lad os sige 8 faktureringssystemer med 15 millioner abonnenter<\/b>, s\u00e5 skulle det nu blive 100 millioner abonnenter eller flere<\/b>\u00a0\u2014 belastningen er meget h\u00f8jere.<\/p>\n

Vi blev sammenlignelige i st\u00f8rrelse med store internetakt\u00f8rer som Mail.ru eller Netflix.<\/p><\/blockquote>\n

\nMen den videre bev\u00e6gelse mod \u00f8get belastning og abonnentbase stiller alvorlige krav til os.<\/p>\n

Geografien i vores enorme land<\/h3>\n

\nMellem Kaliningrad og Vladivostok 7500 km og 10 tidszoner<\/b>. Lysets hastighed er endelig, og p\u00e5 s\u00e5danne afstande er forsinkelsen allerede betydningsfuld. 150 ms p\u00e5 de mest avancerede optiske kanaler er for meget til real-time taksering, is\u00e6r som den er i telekom i Rusland nu. Desuden er det n\u00f8dvendigt at opdatere inden for en arbejdsdag, og med forskellige tidszoner er det et problem.<\/p>\n

Vi tilbyder ikke bare abonnementsbaserede tjenester, vi har komplekse tariffer, pakker og forskellige modifikatorer. Vi skal ikke bare give abonnenten lov til at tale eller ikke tale, men vi skal give ham en bestemt kvote \u2013 vi skal t\u00e6lle opkald og handlinger i realtid, s\u00e5 han ikke bem\u00e6rker det.<\/p>\n

Fejltolerance<\/h3>\n

<\/p>\n

Det er bagsiden af centralisering.<\/p><\/blockquote>\n

\nHvis vi samler alle abonnenter i \u00e9t system, vil enhver n\u00f8dsituation og katastrofe v\u00e6re katastrofal for forretningen. Derfor designer vi systemet, s\u00e5 det udelukker indflydelsen fra afbrydelser p\u00e5 hele abonnentbasen.<\/p>\n

Dette er igen et resultat af at opgive vertikal skalerbarhed. Da vi gik over til horisontal skalerbarhed, \u00f8gede vi antallet af servere fra hundrede til tusinder. De skal styres, og der skal bygges udskiftelighed, automatisk reservedele IT-infrastruktur og genoprettes distribuerede systemer.<\/p>\n

Der var interessante udfordringer foran os. Vi designede systemet og fors\u00f8gte i det \u00f8jeblik at finde global best practice for at se, hvorvidt vi var p\u00e5 rette spor, og i hvor h\u00f8j grad vi fulgte med i teknologierne.<\/p>\n

Global erfaring<\/h2>\n

<\/p>\n

Overraskende nok fandt vi ikke en eneste reference i den globale telekommunikationsindustri.<\/p><\/blockquote>\n

\nEuropa var ikke relevant i forhold til antal abonnenter og omfang, USA \u2013 p\u00e5 grund af fladen af deres takster. Vi kiggede lidt i Kina og fandt noget i Indien og tog specialister fra Vodafone India.<\/p>\n

Til at analysere arkitekturen samlede vi Dream Team ledet af IBM \u2013 arkitekter fra forskellige omr\u00e5der. Disse personer kunne vurdere, hvad vi gjorde, og bringe bestemte viden ind i vores arkitektur.<\/p>\n

Skala<\/h2>\n

\nNogle tal til illustration.<\/p>\n

Vi designer systemet til 80 mio. abonnenter med plads til en milliard<\/b>. S\u00e5dan fjerner vi fremtidige gr\u00e6nser. Det er ikke fordi vi planl\u00e6gger at erobre Kina, men p\u00e5 grund af presset fra IoT og M2M.<\/p>\n

300 mio. dokumenter behandles i realtid<\/b>. Selvom vi har 80 mio. abonnenter, arbejder vi ogs\u00e5 med potentielle kunder og dem, der er forladt os, hvis der er behov for at inddrive fordringer. Derfor er de reelle volumen betydeligt st\u00f8rre.<\/p>\n

2 mia. transaktioner<\/b> \u00e6ndrer saldo dagligt \u2013 det er betalinger, opkr\u00e6vninger, opkald og andre begivenheder.\u00a0200 TB data \u00e6ndres aktivt<\/b>, lidt langsommere \u00e6ndres 8 PB data<\/b>, og dette er ikke en arkiv, men levende data i \u00e9t billing-system. Skalaen p\u00e5 datacentre er 5.000 servere p\u00e5 14 lokationer<\/b>.<\/p>\n

Teknologisk stak<\/h2>\n

\nDa vi planlagde arkitekturen og begyndte at opbygge systemet, importerede vi de mest interessante og avancerede teknologier. Resultatet blev en teknologistak, som er kendt af enhver spiller p\u00e5 internettet og af virksomheder, der skaber h\u00f8jtydende systemer. <\/p>\n

\"Fremtidens
\n
\nStakken ligner stakkene hos andre store spillere: Netflix, Twitter, Viber. Den best\u00e5r af 6 komponenter, men vi \u00f8nsker at forkorte og forene den.<\/p>\n

Fleksibilitet er godt, men i en stor virksomhed er der ingen vej uden ensretning.<\/p><\/blockquote>\n

\nVi har ikke t\u00e6nkt os at erstatte Oracle med Tarantool. I store virksomheders realiteter ville det v\u00e6re en utopi, eller en korsfarertur p\u00e5 5-10 \u00e5r med et uforudsigeligt resultat. Men Cassandra og Couchbase kan sagtens erstattes med Tarantool, og det er vi i gang med.<\/p>\n

Hvorfor Tarantool?<\/h2>\n

\nDer er 4 enkle kriterier for, hvorfor vi valgte denne database.<\/p>\n

Hastighed<\/b>. Vi har gennemf\u00f8rt belastningstests p\u00e5 MegaFons industrielle systemer. Tarantool vandt \u2013 det viste den bedste ydeevne.<\/p>\n

Det kan ikke siges, at andre systemer ikke im\u00f8dekommer MegaFons behov. De nuv\u00e6rende memory-l\u00f8sninger er s\u00e5 effektive, at denne kapacitet er mere end tilstr\u00e6kkelig for virksomheden. Men vi er interesseret i at arbejde med en leder, og ikke med dem, der halter bagefter, ogs\u00e5 hvad ang\u00e5r belastningstest.<\/p>\n

Tarantool im\u00f8dekommer virksomhedens behov, selv p\u00e5 lang sigt.<\/p><\/blockquote>\n

\nTCO-omkostninger<\/b>. Support af Couchbase i MegaFons omfang koster astronomiske bel\u00f8b, mens situationen med Tarantool er langt mere behagelig, og de er t\u00e6t p\u00e5 hinanden hvad funktionalitet ang\u00e5r.<\/p>\n

En anden behagelig egenskab, som lidt p\u00e5virkede vores valg \u2013 Tarantool fungerer bedre end de andre databaser med hukommelsen. Den viser maksimal effektivitet<\/b>.<\/p>\n

P\u00e5lidelighed<\/b>. MegaFon investerer i p\u00e5lidelighed, m\u00e5ske som ingen andre. S\u00e5 da vi kiggede p\u00e5 Tarantool, inds\u00e5 vi, at vi m\u00e5tte s\u00f8rge for, at det kunne opfylde vores krav.<\/p>\n

Vi har investeret vores tid og penge, og sammen med Mail.ru har vi skabt en enterprise-version, som nu bruges i flere andre virksomheder.<\/p>\n

Tarantool-enterprise tilfredsstillede os fuldt ud p\u00e5 sikkerhed, p\u00e5lidelighed og loggning.<\/p><\/blockquote>\n

<\/p>\n

Partnerskab<\/h3>\n

\nDet vigtigste for mig er den direkte kontakt med udvikleren<\/b>. Det er pr\u00e6cis det, som folkene fra Tarantool har vundet os over med.<\/p>\n

N\u00e5r du henvender dig til en spiller, is\u00e6r en der arbejder med en ankerkunde, og siger, at du har brug for, at databasen skal kunne g\u00f8re dette, dette og dette, svarer de som regel:<\/p>\n

\u2014 Godt, l\u00e6g kravene nederst i den bunke \u2014 p\u00e5 et tidspunkt, m\u00e5ske, n\u00e5r vi kommer til dem.<\/i><\/p>\n

Mange har en roadmap for de n\u00e6ste 2-3 \u00e5r, og det er n\u00e6sten umuligt at f\u00e5 plads der, men udviklerne af Tarantool tiltr\u00e6kker med deres \u00e5benhed, ikke kun med MegaFon, og tilpasser deres system til kunden. Det er fantastisk, og vi kan virkelig lide det.<\/p>\n

Hvor vi anvendte Tarantool<\/h2>\n

\nVi bruger Tarantool i flere elementer. Det f\u00f8rste er i piloten<\/b>, som vi lavede p\u00e5 adressen katalogsystemet. I sin tid \u00f8nskede vi, at det skulle v\u00e6re et system, der ligner Yandex.Kort og Google Maps, men det endte med at blive lidt anderledes. <\/p>\n

For eksempel, adressekataloget i salgsgr\u00e6nsefladen. P\u00e5 Oracle tager det 12-13 sekunder at finde den \u00f8nskede adresse \u2014 ikke komfortable tal. N\u00e5r vi skifter til Tarantool, erstatter vi Oracle med en anden database i konsollen, og udf\u00f8rer den samme s\u00f8gning, s\u00e5 f\u00e5r vi en acceleration p\u00e5 200 gange! Byen dukker op efter det tredje bogstav. Vi tilpasser nu gr\u00e6nsefladen, s\u00e5 det sker efter det f\u00f8rste. Alligevel er responstiden helt anderledes \u2014 nu millisekunder i stedet for sekunder.<\/p>\n

Det andet anvendelsesomr\u00e5de er et popul\u00e6rt emne, der kaldes to-hastigheds IT<\/b>. Alt fordi konsulenter fra hvert hj\u00f8rne siger, at virksomheder b\u00f8r g\u00e5 den vej.<\/p>\n

\"Fremtidens
\n
\nHer er der et lag af infrastruktur, over det er dom\u00e6ner, for eksempel billing systemer, som i telekommunikation, virksomhedssystemer, virksomhedsrapportering. Dette er kernen, som ikke b\u00f8r r\u00f8res. Det vil sige, at man naturligvis kan, men p\u00e5 en paranoid m\u00e5de sikrer kvalitet, fordi det bringer penge til virksomheden.<\/p>\n

Dern\u00e6st er lag af mikrotjenester \u2014 det, der differentierer operat\u00f8ren eller en anden spiller. Mikrotjenester kan hurtigt skabes baseret p\u00e5 visse caches, der henter data fra forskellige dom\u00e6ner. Her er der plads til eksperimenter<\/b>\u00a0\u2014 hvis noget mislykkes, lukker man en mikrotjeneste, \u00e5bner en anden. Dette sikrer virkelig en \u00f8get time-to-market og \u00f8ger p\u00e5lideligheden og hastigheden i virksomheden.<\/p>\n

Mikrotjenester er uden tvivl den prim\u00e6re rolle for Tarantool i MegaFon. <\/p><\/blockquote>\n

<\/p>\n

Hvor vi planl\u00e6gger at anvende Tarantool<\/h2>\n

\nSammenlignet med vores succesfulde billing-projekt og transformationsprogrammerne hos Deutsche Telekom, \u0421\u0432\u044f\u0437\u044c\u043a\u043e\u043c, Vodafone India, er det bem\u00e6rkelsesv\u00e6rdigt dynamisk og kreativt. I implementeringen af dette projekt er ikke kun MegaFon og dens struktur blevet transformeret, men der er ogs\u00e5 opst\u00e5et Tarantool-enterprise hos Mail.ru, mens vores leverand\u00f8r Nexign (tidligere \u201e\u041f\u0435\u0442\u0435\u0440-\u0421\u0435\u0440\u0432\u0438\u0441\u201c) har udviklet BSS Box (et box-baseret billing-l\u00f8sning).<\/p>\n

Dette er, p\u00e5 en m\u00e5de, et historisk projekt for det russiske marked. Det kan sammenlignes med det, der er beskrevet i Frederic Brooks' bog \u201eThe Mythical Man-Month\u201c. Dengang, i 60'erne, anmodede IBM 5.000 mennesker om at udvikle et nyt operativsystem, OS\/360, til mainframes. Vi har f\u00e6rre, 1.800, men vores folk er dedikerede, og med brugen af open source og nye tilgange arbejder vi mere effektivt.<\/p>\n

Nedenfor vises dom\u00e6nerne for billing eller, mere bredt, for forretningssystemer. Folk fra enterprise kender godt CRM. Andre systemer skal allerede v\u00e6re tilg\u00e6ngelige for alle: Open API, API Gateway.<\/p>\n

\"Fremtidens
\n<\/p>\n

Open API<\/h3>\n

\nLad os igen se p\u00e5 tallene og hvordan Open API fungerer nu. Dets belastning er 10.000 transaktioner per sekund<\/b>. Da vi planl\u00e6gger aktivt at udvikle lagene af mikrotjenester og bygge MegaFons offentlige API, forventer vi en st\u00f8rre v\u00e6kst i fremtiden, is\u00e6r p\u00e5 dette omr\u00e5de.\u00a0100.000 transaktioner vil helt sikkert v\u00e6re<\/b>.<\/p>\n

Jeg ved ikke, om vi kan sammenligne os med Mail.ru i SSO \u2013 de har tilsyneladende 1.000.000 transaktioner per sekund. Deres l\u00f8sning er yderst interessant for os, og vi planl\u00e6gger at l\u00e6re af deres erfaring - for eksempel ved at skabe funktionel redundans i SSO ved hj\u00e6lp af Tarantool. Lige nu arbejder udviklerne fra Mail.ru med dette hos os.<\/p>\n

CRM<\/h2>\n

\nCRM er de samme 80 millioner abonnenter, som vi \u00f8nsker at bringe op p\u00e5 en milliard, fordi der allerede er 300 millioner dokumenter, der omfatter tre \u00e5rs historie. Vi venter virkelig p\u00e5 nye tjenester, og her v\u00e6kstpunktet er de tilkoblede tjenester<\/b>. Det er et omr\u00e5de, der vil vokse, fordi der vil komme flere og flere tjenester. Derfor vil der v\u00e6re behov for en historie, vi \u00f8nsker ikke at snuble over dette.<\/p>\n

Selve billing i forhold til fakturering, arbejde med kundernes debitorer er blevet transformeret til et s\u00e6rskilt dom\u00e6ne<\/b>. For at forbedre produktiviteten, er den dom\u00e6nearkitekturm\u00e6ssige skabelon blevet anvendt.<\/b>.<\/p>\n

Systemet er opdelt i dom\u00e6ner, belastningen er fordelt, og der er sikret fejltolerance. Derudover er der arbejdet med den distribuerede arkitektur.<\/p><\/blockquote>\n

\nAlt andet er enterprise-l\u00f8sninger. I opkaldslageret - 2 milliarder om dagen<\/b>, 60 milliarder om m\u00e5neden. Nogle gange skal de t\u00e6lles op igen for m\u00e5neden, og det er bedre hurtigt. Finansiel overv\u00e5gning<\/b>\u00a0\u2013 det er lige n\u00f8jagtigt de 300 millioner, som konstant vokser og vokser: abonnenter bev\u00e6ger sig ofte mellem operat\u00f8rer, hvilket \u00f8ger denne del.<\/p>\n

Den mest telekommunikationsm\u00e6ssige komponent fra mobiltelefonien er onlinetaksering<\/b>. Det er de systemer, der tillader dig at ringe eller ikke ringe, og tr\u00e6ffer beslutninger i realtid. Her er belastningen 30.000 transaktioner i sekundet, men med hensyn til den voksende datatransmission planl\u00e6gger vi 250.000 transaktioner<\/b>, og derfor er vi meget interesserede i Tarantool.<\/p>\n

Det tidligere billede viser de dom\u00e6ner, hvor vi planl\u00e6gger at anvende Tarantool. Selve CRM-systemet er selvf\u00f8lgelig bredere, og vi har til hensigt at anvende det i selve kernen. <\/p>\n

Mit beregnede tal for TTH p\u00e5 100 millioner abonnenter bekymrer mig som arkitekt \u2013 hvad hvis der er 101 millioner? Skal alt laves om igen? For at undg\u00e5 dette anvender vi caches og samtidig \u00f8ger tilg\u00e6ngeligheden.<\/p>\n

\"Fremtidens
\n
\nGenerelt er der to tilgange til anvendelsen af Tarantool. Den f\u00f8rste er at bygge alle caches p\u00e5 mikroserviceniveau.<\/b>Hvad jeg forst\u00e5r, er det den vej, VimpelCom g\u00e5r, n\u00e5r de opretter en kundecache.<\/p>\n

Vi er derimod mindre afh\u00e6ngige af leverand\u00f8rer og \u00e6ndrer BSS-kernen, s\u00e5 vi allerede har en ensartet kundekatalog fra kassen. Men vi \u00f8nsker at udvide det. Derfor anvender vi en lidt anden tilgang \u2013 vi laver caches inde i systemerne.<\/b>.<\/p>\n

S\u00e5 er der mindre desynkronisering \u2013 \u00e9t system st\u00e5r for b\u00e5de cache og den prim\u00e6re masterkilde.<\/p><\/blockquote>\n

\nMetoden passer godt ind i Tarantools tilgang med en transaktionel skelet, hvor der kun opdateres de dele, der vedr\u00f8rer opdateringer, det vil sige data\u00e6ndringer. Alt andet kan opbevares et andet sted. Der er ikke et enorme data lake, et ukontrolleret globalt cache. Caches designes til systemet, enten til produkter, eller til kunder, eller for at lette livet for service.<\/p>\n

RTO og RPO<\/h2>\n

\nDer findes to termer i IT - RTO<\/b> og\u00a0RPO<\/b>. <\/p>\n

Recovery time objective<\/b>\u00a0\u2014 det er den tid, det tager at gendanne tjenesten efter en fejl. RTO = 0 betyder, at selvom noget falder ud, forts\u00e6tter tjenesten med at arbejde.<\/p>\n

gendannelsespunktm\u00e5l<\/b>\u00a0\u2014 det er den tid, det tager at gendanne data, hvor mange data vi kan miste over en given tidsperiode. RPO = 0 betyder, at vi ikke mister data.<\/p>\n

Opgave for Tarantool<\/h2>\n

\nLad os pr\u00f8ve at l\u00f8se opgaven for Tarantool.<\/p>\n

Givet<\/b>: en velkendt indk\u00f8bskurv, for eksempel p\u00e5 Amazon eller et andet sted. Krav<\/b> at kurven skal fungere 24 timer i d\u00f8gnet, 7 dage om ugen, eller 99,99% af tiden. Bestillinger, der kommer til os, skal bevare r\u00e6kkef\u00f8lgen, fordi vi ikke kan t\u00e6nde eller slukke for abonnentens forbindelse kaotisk \u2013 alt skal v\u00e6re strengt sekventielt. Den tidligere abonnementsstatus p\u00e5virker den n\u00e6ste, s\u00e5 data er vigtige \u2013 intet m\u00e5 g\u00e5 tabt.<\/p>\n

L\u00f8sning<\/b>. Man kan fors\u00f8ge at l\u00f8se det direkte og sp\u00f8rge databaseudviklerne, men opgaven kan ikke l\u00f8ses matematisk. Man kan huske teoremerne, bevarelseslovene, kvantefysikken, men hvorfor \u2013 det er umuligt at l\u00f8se p\u00e5 databaseniveau.<\/p>\n

Her fungerer den gode gamle arkitekturm\u00e6ssige tilgang \u2013 man skal kende emnet godt og dermed l\u00f8se denne g\u00e5de.<\/p>\n

\"Fremtidens
\n
\nVores l\u00f8sning: vi opretter et distribueret register for anmodninger p\u00e5 Tarantool \u2013 et geo-distribueret kluster<\/b>. P\u00e5 diagrammet er det tre forskellige datacentre \u2013 to f\u00f8r Ural, et efter Ural, og vi fordeler alle anmodninger mellem disse centre.<\/p>\n

Hos Netflix, som nu betragtes som en af lederne inden for IT, havde de indtil 2012 kun et datacenter. Dagen f\u00f8r den katolske juleaften, den 24. december, faldt dette datacenter. Brugere i Canada og USA blev frataget deres yndlingsfilm, blev meget kede af det og skrev om det p\u00e5 sociale medier. Nu har Netflix tre datacentre p\u00e5 den vest-\u00f8stlige kyst og et i Vesteuropa. <\/p>\n

Vi bygger oprindeligt en geo-distribueret l\u00f8sning \u2013 vi v\u00e6rds\u00e6tter fejltolerance. <\/p><\/blockquote>\n

\nS\u00e5 vi har et kluster, men hvordan h\u00e5ndterer vi RPO = 0 og RTO = 0? L\u00f8sningen er enkel og afh\u00e6nger af emnet.<\/p>\n

Hvad er vigtigt i anmodningerne? To dele: skabelsen af kurven\u00a0F\u00d8R<\/b> beslutningen om k\u00f8b, og\u00a0EFTER<\/b>. Delen F\u00d8R kaldes i telekommunikation normalt order capturing<\/b> eller order negotiation<\/b>. I telekombranchen kan det v\u00e6re betydeligt mere komplekst end i en internetbutik, fordi man skal betjene kunden, tilbyde 5 muligheder, og det hele tager lidt tid, men kurven fyldes. I dette \u00f8jeblik kan der ske en fejl, men det er ikke farligt, fordi det foreg\u00e5r interaktivt under opsyn af en person. <\/p>\n

Hvis det Moskva Data Center pludselig g\u00e5r ned, vil vi automatisk skifte til et andet Data Center og forts\u00e6tte driften. Teoretisk kan et produkt g\u00e5 tabt i kurven, men du kan se det, genopfylde kurven og forts\u00e6tte arbejdet. I dette tilf\u00e6lde er RTO = 0.<\/p>\n

Samtidig er der et andet scenarie: n\u00e5r vi trykker p\u00e5 'submit', \u00f8nsker vi, at dataene ikke g\u00e5r tabt. Fra dette punkt begynder automatiseringen at fungere - det er allerede RPO = 0. Anvendelsen af disse to forskellige m\u00f8nstre i et tilf\u00e6lde kan v\u00e6re et geo-distribueret cluster med en skiftbar master, mens det i et andet tilf\u00e6lde kan v\u00e6re en form for quorum-optegnelse. M\u00f8nstrene kan variere, men vi l\u00f8ser problemet.<\/p>\n

Derudover, med en distribueret register af anmodninger, kan vi ogs\u00e5 skalere det hele - have mange dispatcher og udf\u00f8rere, der henvender sig til dette register.<\/p>\n

\"Fremtidens
\n<\/p>\n

Cassandra og Tarantool sammen<\/h2>\n

\nDer er endnu et tilf\u00e6lde - \"balancespejlet\"<\/b>. Her har vi netop en interessant anvendelse af Cassandra og Tarantool.<\/p>\n

Vi anvender Cassandra, fordi 2 milliarder opkald om dagen ikke er gr\u00e6nsen, og det vil blive mere. Marketers elsker at visualisere trafik efter kilder, og der kommer flere og flere detaljer fra sociale medier, for eksempel. Dette \u00f8ger historikken.<\/p>\n

Cassandra tillader horisontal skalerbarhed p\u00e5 enhver volumen.<\/p><\/blockquote>\n

\nVi f\u00f8ler os godt tilpas med Cassandra, men den har et problem - den er ikke god til l\u00e6sning. Ved skrivning er alt fint, 30.000 i sekundet er ikke et problem - problemet ligger i l\u00e6sningen.<\/b>.<\/p>\n

Derfor opstod temaet med cache, og vi besluttede samtidig at l\u00f8se det n\u00e6ste problem: Der er et gammelt traditionelt tilf\u00e6lde, hvor udstyret fra switchen fra online-efterretning kommer ind i filer, som vi uploader til Cassandra. Vi k\u00e6mpede med problemet med p\u00e5lidelig upload af disse filer, og vi brugte endda, efter r\u00e5d fra IBM manager file transfer - der findes s\u00e5danne l\u00f8sninger, der effektivt styrer filoverf\u00f8rsel ved hj\u00e6lp af UDP-protokollen, for eksempel, og ikke TCP. Det er godt, men det tager stadig minutter, og indtil vi har indl\u00e6st alt dette, kan operat\u00f8ren i callcentret ikke svare kunden p\u00e5, hvad der er sket med hans balance - man m\u00e5 vente.<\/p>\n

For at undg\u00e5 dette\u00a0bruger vi parallelt funktionelt reserve<\/b>. N\u00e5r vi sender en h\u00e6ndelse gennem Kafka til Tarantool, mens vi gensender aggregater i realtid, for eksempel for i dag, f\u00e5r vi cache af saldi<\/b>, som kan returnere saldi med enhver hastighed, for eksempel 100.000 transaktioner per sekund og de samme 2 sekunder.<\/p>\n

M\u00e5let er, at efter et opkald skal den \u00e6ndrede balance ikke kun v\u00e6re tilg\u00e6ngelig i brugerens personlige konto efter 2 sekunder, men ogs\u00e5 information om, hvorfor den er \u00e6ndret.<\/p>\n

Konklusion<\/h2>\n

\nDette var eksempler p\u00e5 brug af Tarantool. Vi har v\u00e6ret meget tilfredse med \u00e5benheden hos Mail.ru og deres vilje til at overveje forskellige tilf\u00e6lde. <\/p>\n

Det er allerede sv\u00e6rt at overraske konsulenter fra BCG eller McKinsey, Accenture eller IBM med noget nyt - meget af det, de tilbyder, laver vi allerede, har gjort eller planl\u00e6gger at g\u00f8re. Jeg tror, at Tarantool vil f\u00e5 en v\u00e6rdig plads i vores teknologiske stak og erstatte mange eksisterende teknologier. Vi er i den aktive fase af udviklingen af dette projekt.<\/p>\n

Oleg og Andrey's pr\u00e6sentation var en af de bedste ved Tarantool Conference sidste \u00e5r, og allerede den 17. juni vil Oleg Ivlev tale ved\u00a0T+ Conference 2019<\/a><\/noindex>\u00a0med en pr\u00e6sentation \u00abHvorfor Tarantool i Enterprise\u00bb<\/a><\/noindex>. Alexander Deulin fra MegaFon vil ogs\u00e5 deltage med en pr\u00e6sentation \u00abTarantool caches og replikation fra Oracle\u00bb<\/a><\/noindex>. Vi vil finde ud af, hvad der er \u00e6ndret, hvilke planer der er blevet realiseret. Deltag - konferencen er gratis, man skal bare registrere sig<\/a><\/noindex>. Alle pr\u00e6sentationer er accepteret<\/a><\/noindex> og konferencens program er blevet dannet: nye cases, ny erfaring med at bruge Tarantool, arkitektur, enterprise, tutorials og mikrotjenester.<\/p><\/blockquote>\n

Kilde: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0417\u0430\u0447\u0435\u043c \u0442\u0430\u043a\u043e\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0446\u0438\u0438, \u043a\u0430\u043a \u041c\u0435\u0433\u0430\u0424\u043e\u043d, Tarantool \u0432\u00a0\u0431\u0438\u043b\u043b\u0438\u043d\u0433\u0435? \u0421\u043e \u0441\u0442\u043e\u0440\u043e\u043d\u044b \u043a\u0430\u0436\u0435\u0442\u0441\u044f, \u0447\u0442\u043e \u043e\u0431\u044b\u0447\u043d\u043e \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u0442 \u0432\u0435\u043d\u0434\u043e\u0440, \u043f\u0440\u0438\u043d\u043e\u0441\u0438\u0442 \u043a\u0430\u043a\u0443\u044e-\u0442\u043e \u0431\u043e\u043b\u044c\u0448\u0443\u044e \u043a\u043e\u0440\u043e\u0431\u043a\u0443, \u0432\u0442\u044b\u043a\u0430\u0435\u0442 \u0448\u0442\u0435\u043a\u0435\u0440 \u0432\u00a0\u0440\u043e\u0437\u0435\u0442\u043a\u0443\u00a0\u2014 \u0432\u043e\u0442 \u0438\u00a0\u0431\u0438\u043b\u043b\u0438\u043d\u0433! \u041a\u043e\u0433\u0434\u0430-\u0442\u043e \u0442\u0430\u043a \u0438\u00a0\u0431\u044b\u043b\u043e, \u043d\u043e\u00a0\u0441\u0435\u0439\u0447\u0430\u0441 \u044d\u0442\u043e \u0430\u0440\u0445\u0430\u0438\u043a\u0430, \u0438\u00a0\u0442\u0430\u043a\u0438\u0435 \u0434\u0438\u043d\u043e\u0437\u0430\u0432\u0440\u044b \u0443\u0436\u0435 \u0432\u044b\u043c\u0435\u0440\u043b\u0438 \u0438\u043b\u0438 \u0432\u044b\u043c\u0438\u0440\u0430\u044e\u0442. \u0418\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u0431\u0438\u043b\u043b\u0438\u043d\u0433 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0434\u043b\u044f \u0432\u044b\u0441\u0442\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0441\u0447\u0435\u0442\u043e\u0432\u00a0\u2014 \u0441\u0447\u0438\u0442\u0430\u043b\u043a\u0430 \u0438\u043b\u0438 \u043a\u0430\u043b\u044c\u043a\u0443\u043b\u044f\u0442\u043e\u0440. \u0412\u00a0\u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e\u043c \u0442\u0435\u043b\u0435\u043a\u043e\u043c\u0435\u00a0\u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u0438 \u0432\u0441\u0435\u0433\u043e \u0436\u0438\u0437\u043d\u0435\u043d\u043d\u043e\u0433\u043e \u0446\u0438\u043a\u043b\u0430 \u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u0441\u00a0\u0430\u0431\u043e\u043d\u0435\u043d\u0442\u043e\u043c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28258,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37650","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Next-generation billing arkitektur: transformation med overgangen til Tarantool | ProHoster","description":"Hvorfor har en virksomhed som MegaFon brug for Tarantool i billing? Udefra ser det ud som om, at en leverand\u00f8r normalt kommer, bringer en stor kasse, s\u00e6tter stikket i stikkontakten \u2014 og s\u00e5 er billing klar!","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/arhitektura-billinga-novogo-pokoleniya-transformatsiya-s-perehodom-na-tarantool","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0410\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0430 \u0431\u0438\u043b\u043b\u0438\u043d\u0433\u0430 \u043d\u043e\u0432\u043e\u0433\u043e \u043f\u043e\u043a\u043e\u043b\u0435\u043d\u0438\u044f: \u0442\u0440\u0430\u043d\u0441\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044f \u0441 \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u043e\u043c \u043d\u0430 Tarantool | ProHoster","og:description":"\u0417\u0430\u0447\u0435\u043c \u0442\u0430\u043a\u043e\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0446\u0438\u0438, \u043a\u0430\u043a \u041c\u0435\u0433\u0430\u0424\u043e\u043d, Tarantool \u0432 \u0431\u0438\u043b\u043b\u0438\u043d\u0433\u0435? \u0421\u043e \u0441\u0442\u043e\u0440\u043e\u043d\u044b \u043a\u0430\u0436\u0435\u0442\u0441\u044f, \u0447\u0442\u043e \u043e\u0431\u044b\u0447\u043d\u043e \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u0442 \u0432\u0435\u043d\u0434\u043e\u0440, \u043f\u0440\u0438\u043d\u043e\u0441\u0438\u0442 \u043a\u0430\u043a\u0443\u044e-\u0442\u043e \u0431\u043e\u043b\u044c\u0448\u0443\u044e \u043a\u043e\u0440\u043e\u0431\u043a\u0443, \u0432\u0442\u044b\u043a\u0430\u0435\u0442 \u0448\u0442\u0435\u043a\u0435\u0440 \u0432 \u0440\u043e\u0437\u0435\u0442\u043a\u0443 \u2014 \u0432\u043e\u0442 \u0438 \u0431\u0438\u043b\u043b\u0438\u043d\u0433!","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/arhitektura-billinga-novogo-pokoleniya-transformatsiya-s-perehodom-na-tarantool","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:18:50+00:00","article:modified_time":"2019-10-31T19:18:50+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37650","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 18:44:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:23:06","updated":"2026-01-23 18:44:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/37650","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=37650"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/37650\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/28258"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=37650"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=37650"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=37650"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}