{"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\/it\/blog\/administrirovanie\/arhitektura-billinga-novogo-pokoleniya-transformatsiya-s-perehodom-na-tarantool","title":{"rendered":"Architettura del billing di nuova generazione: trasformazione attraverso l'adozione di Tarantool","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Perch\u00e9 una corporazione come MegaFon ha bisogno di Tarantool nella fatturazione? Da fuori sembra che un venditore arrivi, porti una grande scatola, colleghi una spina alla presa e voil\u00e0, ecco la fatturazione! Un tempo era cos\u00ec, ma ora \u00e8 un'arcaica, e questi dinosauri sono gi\u00e0 estinti o stanno scomparendo. Inizialmente, la fatturazione era un sistema per emettere fatture \u2014 un contatore o una calcolatrice. Nel moderno telecomunicazioni, \u00e8 un sistema per automatizzare l'intero ciclo di vita dell'interazione con l'abbonato, dalla conclusione del contratto fino alla risoluzione<\/b>, inclusa la tariffazione in tempo reale, l'accettazione dei pagamenti e molto altro. La fatturazione nelle aziende di telecomunicazioni \u00e8 simile a un robot da combattimento \u2014 grande, potente e armato fino ai denti.<\/p>\n

\"Architettura
\n
\nCosa c'entra Tarantool? Questo sar\u00e0 spiegato da Oleg Ivlev<\/b> e\u00a0Andrey Knyazev<\/b>. Oleg \u00e8 il principale architetto dell'azienda MegaFon<\/a><\/noindex> con una vasta esperienza in aziende estere, Andrey \u00e8 il direttore dei sistemi aziendali. Dalla trascrizione della loro relazione alla\u00a0Tarantool Conference 2018<\/a><\/noindex>\u00a0scoprirete perch\u00e9 la ricerca e sviluppo \u00e8 importante nelle aziende, cos'\u00e8 Tarantool, come il limite del ridimensionamento verticale e la globalizzazione abbiano dato origine a questo database all'interno dell'azienda, le sfide tecnologiche, la trasformazione dell'architettura, e in che modo la stack tecnologica di MegaFon sia simile a quella di Netflix, Google e Amazon.
\n<\/a><\/noindex>
\n

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

Progetto \"Unified Billing\"<\/h2>\n

\nIl progetto di cui parleremo si chiama \"Unified Billing\". \u00c8 qui che Tarantool ha dimostrato le sue migliori qualit\u00e0. <\/p>\n

\"Architettura
\n
\nLa crescita delle prestazioni delle attrezzature Hi-End non ha tenuto il passo con l'aumento della base di abbonati e il numero di servizi; si prevedeva un ulteriore aumento del numero di abbonati e servizi grazie a M2M, IoT, e le peculiarit\u00e0 delle filiali portavano a un deterioramento del time-to-market. L'azienda ha deciso di creare un sistema commerciale unificato con un'architettura modulare unica di livello mondiale, in sostituzione delle 8 attuali diverse sistemi di fatturazione.<\/p>\n

MegaFon \u00e8 otto aziende in una<\/b>. Nel 2009 \u00e8 avvenuta la riorganizzazione: le filiali in tutta Russia si sono unite in un'unica azienda, OAO \u00abMegaFon\u00bb (ora P\u0410\u041e). Cos\u00ec, l'azienda ha acquisito 8 sistemi di fatturazione con le proprie soluzioni \u00abcustom\u00bb, caratteristiche filiali e strutture organizzative diverse, IT e marketing.<\/p>\n

Tutto andava bene, fino a quando non \u00e8 stato necessario lanciare un unico prodotto federale. Qui sono emerse una serie di complicazioni: alcune avevano la tariffazione con arrotondamento per eccesso, altre per difetto, e alcune ancora secondo la media aritmetica. Questi aspetti sono migliaia.<\/p>\n

Nonostante la versione del sistema di fatturazione fosse una sola, un unico fornitore, le configurazioni erano cos\u00ec diverse che ci \u00e8 voluto molto tempo per allinearle. Abbiamo cercato di ridurre il loro numero e ci siamo imbattuti in un secondo problema noto a molte aziende.<\/p>\n

Scalabilit\u00e0 verticale<\/b>. Anche l'hardware pi\u00f9 all'avanguardia dell'epoca non soddisfaceva le esigenze. Sono stati utilizzati server Hewlett-Packard della linea Superdome Hi-End, ma non riuscivano a supportare nemmeno le necessit\u00e0 di due filiali. Si desiderava uno scaling orizzontale senza grandi costi operativi e investimenti di capitale.<\/p>\n

Aspettando la crescita del numero di abbonati e dei servizi<\/b>. Da tempo i consulenti hanno portato nel mondo delle telecomunicazioni storie su IoT e M2M: arriver\u00e0 il momento in cui in ogni telefono e ferro da stiro ci sar\u00e0 una SIM, e nel frigorifero ce ne saranno due. Oggi abbiamo un certo numero di abbonati, e nel prossimo futuro ci saranno molte di pi\u00f9.<\/p>\n

Sfide tecnologiche<\/h2>\n

\nQueste quattro ragioni ci hanno spinto verso cambiamenti significativi. Abbiamo dovuto scegliere tra modernizzazione del sistema e progettazione da zero. Abbiamo riflettuto a lungo, preso decisioni importanti, e partecipato a gare d'appalto. Alla fine, abbiamo deciso di progettare fin dall'inizio e ci siamo confrontati con sfide interessanti: le sfide tecnologiche.<\/p>\n

Scalabilit\u00e0<\/h3>\n

\nSe prima avevamo, diciamo cos\u00ec, 8 sistemi di billing con 15 milioni di abbonati<\/b>, ora doveva risultare 100 milioni di abbonati e oltre<\/b>\u00a0\u2014 il carico \u00e8 considerevolmente maggiore.<\/p>\n

Siamo diventati comparabili in scala ai grandi attori di internet, come Mail.ru o Netflix.<\/p><\/blockquote>\n

\nMa il progresso successivo nell'aumento del carico e della base di abbonati ha presentato serie sfide.<\/p>\n

La geografia del nostro vasto paese<\/h3>\n

\nTra Kaliningrado e Vladivostok 7500 km e 10 fusi orari<\/b>. La velocit\u00e0 della luce \u00e8 finita e a tali distanze i ritardi sono gi\u00e0 significativi. 150 ms sui pi\u00f9 avanzati canali ottici moderni sono troppi per una tariffazione in tempo reale, specialmente come accade attualmente nel telecomunicazioni in Russia. Inoltre, \u00e8 necessario aggiornarsi entro un giorno lavorativo e, con diversi fusi orari, questo diventa un problema.<\/p>\n

Non offriamo semplicemente servizi a pagamento, ma abbiamo tariffe complesse, pacchetti e diversi modificatori. Dobbiamo non solo autorizzare o vietare a un abbonato di parlare, ma dargli una certa quota: calcolare le chiamate e le azioni in tempo reale in modo che lui non se ne accorga.<\/p>\n

Affidabilit\u00e0<\/h3>\n

<\/p>\n

Questo \u00e8 il rovescio della medaglia della centralizzazione.<\/p><\/blockquote>\n

\nSe raggruppiamo tutti gli abbonati in un unico sistema, qualsiasi evento d'emergenza e disastro risulterebbe catastrofico per il business. Pertanto, progettiamo il sistema in modo da escludere l'influenza di incidenti su tutta la base di abbonati.<\/p>\n

Questa \u00e8 nuovamente una conseguenza del rifiuto della scalabilit\u00e0 verticale. Quando siamo passati a una scalabilit\u00e0 orizzontale, abbiamo aumentato il numero di server da centinaia a migliaia. \u00c8 necessario gestirli e costruire la sostituibilit\u00e0, riservare automaticamente l'infrastruttura IT e ripristinare il sistema distribuito.<\/p>\n

Davanti a noi si sono presentate sfide interessanti. Abbiamo progettato il sistema e in quel momento abbiamo cercato best practice globali per verificare quanto fossimo in linea, quanto seguissero tecnologie all'avanguardia.<\/p>\n

Best practice globale<\/h2>\n

<\/p>\n

Incredibilmente, ma nel settore telecomunicazioni globale non abbiamo trovato alcun riferimento.<\/p><\/blockquote>\n

\nL'Europa \u00e8 risultata deficitaria in termini di numero di abbonati e scala, mentre gli Stati Uniti per la variet\u00e0 delle loro tariffe. Abbiamo visto qualcosa in Cina, e abbiamo trovato esperti in India, prendendo specialisti da Vodafone India.<\/p>\n

Per l'analisi dell'architettura, abbiamo riunito un Dream Team guidato da IBM - architetti provenienti da diversi settori. Queste persone erano in grado di valutare adeguatamente ci\u00f2 che stavamo facendo e di portare nella nostra architettura determinate conoscenze.<\/p>\n

Scala<\/h2>\n

\nAlcuni numeri per illustrare.<\/p>\n

Progettiamo il sistema per 80 milioni di abbonati con un margine per un miliardo<\/b>. In questo modo eliminiamo le future soglie. Non \u00e8 perch\u00e9 intendiamo conquistare la Cina, ma a causa della spinta dell'IoT e del M2M.<\/p>\n

300 milioni di documenti elaborati in tempo reale<\/b>. Anche se abbiamo 80 milioni di abbonati, lavoriamo anche con i clienti potenziali e con quelli che ci hanno lasciato, se dobbiamo riscuotere crediti. Pertanto i volumi reali sono notevolmente pi\u00f9 alti.<\/p>\n

2 miliardi di transazioni<\/b> cambiano il saldo quotidianamente \u2014 si tratta di pagamenti, addebiti, chiamate e altri eventi.\u00a0200 TB di dati vengono modificati attivamente<\/b>, cambiano leggermente pi\u00f9 lentamente 8 PB di dati<\/b>, e questi non sono archivio, ma dati vivi in un'unica fatturazione. La scala nei data center \u00e8 5.000 server su 14 sedi<\/b>.<\/p>\n

Stack tecnologico<\/h2>\n

\nQuando abbiamo pianificato l'architettura e ci siamo messi a costruire il sistema, abbiamo importato le tecnologie pi\u00f9 interessanti e avanzate. Ne \u00e8 risultato uno stack tecnologico, familiare a qualsiasi attore di Internet e alle aziende che realizzano sistemi ad alto carico. <\/p>\n

\"Architettura
\n
\nLo stack \u00e8 simile a quello di altri grandi attori: Netflix, Twitter, Viber. \u00c8 composto da 6 componenti, ma vogliamo ridurlo e unificarlo.<\/p>\n

La flessibilit\u00e0 \u00e8 importante, ma in una grande corporazione l'unificazione \u00e8 essenziale.<\/p><\/blockquote>\n

\nNon abbiamo intenzione di sostituire Oracle con Tarantool. Nella realt\u00e0 delle grandi aziende, questo \u00e8 utopico, oppure un lungo peregrinaggio di 5-10 anni con esiti incerti. Tuttavia, possiamo sostituire Cassandra e Couchbase con Tarantool, e a questo puntiamo.<\/p>\n

Perch\u00e9 Tarantool?<\/h2>\n

\nCi sono 4 semplici criteri per cui abbiamo scelto questo database.<\/p>\n

Velocit\u00e0<\/b>Abbiamo condotto test di carico su sistemi industriali di MegaFon. Tarantool ha vinto, dimostrando la migliore performance.<\/p>\n

Non si pu\u00f2 dire che altri sistemi non soddisfino le esigenze di MegaFon. Le attuali soluzioni in-memory sono cos\u00ec performanti che l'azienda ha abbondanza di risorse. Tuttavia, ci interessa collaborare con un leader, non con chi \u00e8 in fondo alla classifica, incluso nel test di carico.<\/p>\n

Tarantool soddisfa le esigenze dell'azienda anche a lungo termine.<\/p><\/blockquote>\n

\nCosto totale di possesso (TCO)<\/b>Il supporto per Couchbase a questi volumi di MegaFon costa una fortuna, mentre con Tarantool la situazione \u00e8 molto pi\u00f9 favorevole e la funzionalit\u00e0 \u00e8 simile.<\/p>\n

Un'altra piacevole caratteristica, che ha influito sulla nostra scelta, \u00e8 che Tarantool lavora meglio di altri database con la memoria. Mostra efficienza massima<\/b>.<\/p>\n

Affidabilit\u00e0<\/b>. MegaFon investe nella affidabilit\u00e0, forse come nessun altro. Quindi, quando abbiamo guardato a Tarantool, abbiamo capito che dovevamo fare in modo che soddisfacesse le nostre esigenze.<\/p>\n

Abbiamo investito il nostro tempo e le nostre finanze, e insieme a Mail.ru abbiamo creato una versione enterprise che ora \u00e8 utilizzata in diverse altre aziende.<\/p>\n

Tarantool-enterprise ci ha soddisfatti completamente per quanto riguarda sicurezza, affidabilit\u00e0 e registrazione.<\/p><\/blockquote>\n

<\/p>\n

Collaborazioni<\/h3>\n

\nLa cosa pi\u00f9 importante per me \u00e8 il contatto diretto con lo sviluppatore<\/b>. Questo \u00e8 ci\u00f2 che ci ha conquistato del team di Tarantool.<\/p>\n

Se vai da un operatore, soprattutto se lavora con un cliente chiave, e dici che hai bisogno di un database in grado di fare questo, questo e quest'altro, di solito risponde:<\/p>\n

\u2014 Va bene, mettete i requisiti in fondo a quella pila: forse, un giorno, ci arriveremo.<\/i><\/p>\n

Molti hanno una roadmap per i prossimi 2-3 anni, e integrarsi \u00e8 praticamente impossibile, mentre gli sviluppatori di Tarantool attraggono grazie alla loro trasparenza, non solo con MegaFon, e adattano il loro sistema alle esigenze del cliente. \u00c8 fantastico, e ci piace molto.<\/p>\n

Dove abbiamo applicato Tarantool<\/h2>\n

\nNel nostro caso, Tarantool viene utilizzato in diversi elementi. Il primo \u00e8 nel progetto pilota<\/b>, che abbiamo realizzato sul sistema del catalogo degli indirizzi. Un tempo volevamo che fosse un sistema simile a Yandex.Maps e Google Maps, ma \u00e8 venuto fuori un po' diverso. <\/p>\n

Per esempio, il catalogo degli indirizzi nell'interfaccia di vendita. Su Oracle, la ricerca dell'indirizzo desiderato richiede 12-13 secondi \u2014 numeri scomodi. Quando passiamo a Tarantool, sostituendo Oracle con un altro DB nella console e eseguendo la stessa ricerca, otteniamo un'accelerazione di 200 volte! La citt\u00e0 appare dopo la terza lettera. Ora stiamo adattando l'interfaccia per fare in modo che ci\u00f2 avvenga dopo la prima. Tuttavia, la velocit\u00e0 di risposta \u00e8 completamente diversa \u2014 gi\u00e0 millisecondi invece di secondi.<\/p>\n

Il secondo utilizzo \u00e8 un tema di moda che si chiama IT a doppia velocit\u00e0<\/b>. Tutto ci\u00f2 perch\u00e9 i consulenti da ogni angolo dicono che le aziende dovrebbero muoversi in questa direzione.<\/p>\n

\"Architettura
\n
\nQui c'\u00e8 uno strato di infrastruttura, sopra ci sono i domini, per esempio, il sistema di fatturazione, come nel settore delle telecomunicazioni, i sistemi aziendali, la reportistica aziendale. Questo \u00e8 il nucleo che non deve essere toccato. Cio\u00e8, certo, si pu\u00f2 fare, ma in modo paranoico assicurando la qualit\u00e0, perch\u00e9 porta denaro all'azienda.<\/p>\n

Successivamente c'\u00e8 lo strato dei microservizi \u2014 ci\u00f2 che differenzia l'operatore o un altro attore. I microservizi possono essere creati rapidamente sulla base di alcune cache, estraendo dati da vari domini. Qui c'\u00e8 spazio per esperimenti<\/b>\u00a0\u2014 se qualcosa non funziona, chiudo un microservizio e ne apro un altro. Questo assicura un reale miglioramento del time-to-market e aumenta l'affidabilit\u00e0 e la velocit\u00e0 dell'azienda.<\/p>\n

I microservizi sono, probabilmente, il ruolo principale di Tarantool in MTS. <\/p><\/blockquote>\n

<\/p>\n

Dove prevediamo di applicare Tarantool<\/h2>\n

\nSe paragoniamo il nostro successo nel progetto di billing con i programmi di trasformazione di Deutsche Telekom, Svyaznoy, Vodafone India, risulta sorprendentemente dinamico e creativo. Durante l'implementazione di questo progetto, non solo \u00e8 stata trasformata MegaFon e la sua struttura, ma \u00e8 emersa anche Tarantool-enterprise di Mail.ru, mentre il nostro fornitore Nexign (precedentemente \"Peter-Service\") ha lanciato BSS Box (una soluzione di billing pronta all'uso).<\/p>\n

In un certo senso, questo \u00e8 un progetto storico per il mercato russo. Pu\u00f2 essere paragonato a quanto descritto nel libro di Frederick Brooks \"The Mythical Man-Month\". All'epoca, negli anni '60, IBM reclut\u00f2 5.000 persone per sviluppare il nuovo sistema operativo OS\/360 per i mainframe. Noi ne abbiamo meno: 1.800, ma siamo agili, e considerando l'uso dell'open source e nuovi approcci, lavoriamo in modo pi\u00f9 produttivo.<\/p>\n

Di seguito sono riportati i domini del billing o, per dirla in modo pi\u00f9 ampio, dei sistemi business. Le persone nel settore enterprise conoscono bene il CRM. Altri sistemi dovrebbero gi\u00e0 essere accessibili a tutti: Open API, API Gateway.<\/p>\n

\"Architettura
\n<\/p>\n

Open API<\/h3>\n

\nRivediamo ancora i numeri e come funziona attualmente Open API. Il suo carico \u00e8 di 10.000 transazioni al secondo<\/b>. Poich\u00e9 prevediamo di sviluppare attivamente il livello dei microservizi e costruire un'API pubblica di Megafon, ci aspettiamo una maggiore crescita in futuro proprio in questo settore.\u00a0100.000 transazioni ci saranno sicuramente.<\/b>.<\/p>\n

Non so se riusciremo a competere in SSO con Mail.ru \u2014 loro hanno circa 1.000.000 di transazioni al secondo. La loro soluzione ci interessa moltissimo e pianifichiamo di adottare la loro esperienza \u2014 ad esempio, per realizzare un backup funzionale SSO utilizzando Tarantool. Attualmente, i sviluppatori di Mail.ru se ne stanno occupando per noi.<\/p>\n

CRM<\/h2>\n

\nCRM \u2014 sono quei 80 milioni di abbonati che vogliamo portare a un miliardo, poich\u00e9 abbiamo gi\u00e0 300 milioni di documenti che includono una storia di tre anni. Ci aspettiamo davvero nuovi servizi e qui la crescita si concentra sui servizi collegati.<\/b>\u00c8 una sfera che crescer\u00e0 sempre di pi\u00f9, perch\u00e9 i servizi aumenteranno. Di conseguenza, avremo bisogno di una storia, non vogliamo inciampare su questo.<\/p>\n

La parte di billing relativa alla fatturazione e alla gestione del debito dei clienti si \u00e8 trasformata in un dominio separato.<\/b>. Per migliorare le prestazioni, \u00e8 stato applicato un modello architetturale di architettura a dominio.<\/b>.<\/p>\n

Il sistema \u00e8 suddiviso in domini, il carico \u00e8 distribuito e garantisce ridondanza. Inoltre, \u00e8 stato implementato un lavoro con l'architettura distribuita.<\/p><\/blockquote>\n

\nTutto il resto riguarda soluzioni di livello enterprise. Nel nostro sistema di archiviazione delle chiamate \u2014 2 miliardi al giorno<\/b>, 60 miliardi al mese. A volte dobbiamo ricalcolarli mensilmente, e meglio farlo rapidamente. Monitoraggio finanziario<\/b>\u00a0\u2014 questi sono proprio i 300 milioni che continuano a crescere: gli abbonati spesso cambiano operatore, alimentando questa parte.<\/p>\n

Il componente pi\u00f9 tipico delle telecomunicazioni mobili \u00e8 la tariffazione online<\/b>. Questi sono i sistemi che permettono di effettuare o meno una chiamata, prendendo decisioni in tempo reale. Qui gestiamo 30.000 transazioni al secondo, ma considerando la crescita del trasferimento dati, prevediamo 250.000 transazioni<\/b>, e quindi siamo molto interessati a Tarantool.<\/p>\n

L'immagine precedente rappresenta i domini in cui prevediamo di applicare Tarantool. Il CRM, ovviamente, \u00e8 pi\u00f9 ampio e intendiamo utilizzarlo nel nucleo stesso. <\/p>\n

La nostra cifra stimata del TTH di 100 milioni di utenti mi preoccupa come architetto: e se diventassero 101 milioni? Dovremmo rifare tutto? Per evitare ci\u00f2, utilizziamo la cache, aumentando cos\u00ec anche la disponibilit\u00e0.<\/p>\n

\"Architettura
\n
\nEsistono fondamentalmente due approcci all'utilizzo di Tarantool. Il primo \u00e8 costruire tutte le cache a livello di microservizi<\/b>. Da quello che capisco, questa \u00e8 la strada intrapresa da VimpelCom, creando una cache per i clienti.<\/p>\n

Noi, invece, siamo meno dipendenti dai fornitori, stiamo cambiando il nucleo del BSS, quindi abbiamo un'unica scheda clienti gi\u00e0 preconfigurata. Ma vogliamo espanderla. Per questo adottiamo un approccio leggermente diverso: creiamo cache all'interno dei sistemi<\/b>.<\/p>\n

In questo modo c'\u00e8 meno disallineamento: un sistema si occupa sia della cache che della fonte principale.<\/p><\/blockquote>\n

\nQuesto approccio si adatta bene alla soluzione Tarantool con scheletro transazionale, dove vengono aggiornate solo le parti relative alle modifiche, ovvero i cambiamenti dei dati. Tutto il resto pu\u00f2 essere conservato altrove. Non esiste un grande data lake, n\u00e9 una cache globale non gestita. Le cache sono progettate per il sistema, o per i prodotti, o per i clienti, o per semplificare la vita al supporto. Quando un abbonato deluso dalla qualit\u00e0 chiama, si desidera fornirgli un servizio di qualit\u00e0.<\/p>\n

RTO e RPO<\/h2>\n

\nIn IT ci sono due termini - RTO<\/b> e\u00a0RPO<\/b>. <\/p>\n

Recovery time objective<\/b>\u00a0\u00e8 il tempo necessario per ripristinare il servizio dopo un guasto. RTO = 0 significa che anche se qualcosa \u00e8 caduto, il servizio continua a funzionare.<\/p>\n

Recovery point objective<\/b>\u00a0\u00e8 il tempo di ripristino dei dati, ovvero quanti dati possiamo perdere in un certo periodo di tempo. RPO = 0 significa che non perdiamo dati.<\/p>\n

Compito per Tarantool<\/h2>\n

\nProviamo a risolvere un compito per Tarantool.<\/p>\n

Dato<\/b>: una ben nota cesta di richieste, ad esempio, su Amazon o altrove. Richiesta<\/b> affinch\u00e9 il carrello funzioni 24 ore su 24, 7 giorni su 7, o il 99,99% del tempo. Gli ordini che riceviamo devono mantenere l'ordine, perch\u00e9 non possiamo attivare o disattivare la connessione all'utente in modo caotico: tutto deve seguire un rigoroso ordine. L'abbonamento precedente influisce su quello successivo, quindi i dati sono importanti: nulla deve andare perso.<\/p>\n

Soluzione<\/b>. Si potrebbe provare a risolvere in modo diretto e chiedere agli sviluppatori del database, ma il compito non pu\u00f2 essere risolto matematicamente. Si potrebbero richiamare teoremi, leggi di conservazione, fisica quantistica, ma perch\u00e9 farlo: non \u00e8 possibile risolverlo a livello di database.<\/p>\n

Qui si applica il vecchio e caro approccio architetturale: \u00e8 necessario conoscere bene il dominio e, grazie a questo, risolvere questo enigma.<\/p>\n

\"Architettura
\n
\nLa nostra soluzione: creiamo un registro distribuito delle richieste su Tarantool - un cluster geograficamente distribuito<\/b>. Nello schema ci sono tre diversi data center: due prima degli Urali, uno dietro gli Urali, e distribuiamo tutte le richieste tra questi centri.<\/p>\n

Netflix, che ora \u00e8 considerato uno dei leader nel settore IT, fino al 2012 aveva solo un data center. La vigilia di Natale cattolica, il 24 dicembre, questo data center \u00e8 andato offline. Gli utenti in Canada e negli Stati Uniti sono rimasti senza i loro film preferiti, si sono molto arrabbiati e ne hanno scritto sui social. Ora Netflix ha tre data center sulla costa occidentale e orientale e uno in Europa occidentale. <\/p>\n

Iniziamo a costruire una soluzione geodistribuita - la resilienza \u00e8 importante per noi. <\/p><\/blockquote>\n

\nQuindi abbiamo un cluster, ma come gestire RPO = 0 e RTO = 0? La soluzione \u00e8 semplice, ma dipende dall'argomento.<\/p>\n

Cosa \u00e8 importante nelle richieste? Due parti: la costruzione del carrello\u00a0PRIMA<\/b> di prendere una decisione di acquisto, e\u00a0DOPO<\/b>. La parte PRIMA nelle telecomunicazioni \u00e8 solitamente chiamata order capturing<\/b> o order negotiation<\/b>. Nelle telecomunicazioni pu\u00f2 essere molto pi\u00f9 complesso che in un negozio online, perch\u00e9 \u00e8 necessario assistere il cliente, offrire 5 opzioni, e tutto questo richiede del tempo, ma il carrello si riempie. In quel momento \u00e8 possibile un fallimento, ma non \u00e8 grave, perch\u00e9 avviene in modalit\u00e0 interattiva sotto la supervisione di una persona. <\/p>\n

Se il Data Center di Mosca dovesse improvvisamente guastarsi, passeremo automaticamente a un altro Data Center e continueremo a lavorare. Teoricamente potrebbe andare perso un prodotto nel carrello, ma lo vedrete, aggiungerete nuovamente il prodotto al carrello e continuerete a lavorare. In questo caso, RTO = 0.<\/p>\n

Nello stesso momento, c'\u00e8 un'altra opzione: quando facciamo clic su \"submit\", vogliamo assicurarci che i dati non vadano persi. Da questo momento in poi, entra in funzione l'automazione \u2014 qui abbiamo gi\u00e0 RPO = 0. L'uso di questi due diversi schemi in un caso pu\u00f2 essere semplicemente un cluster geodistribuito con un master switchabile, mentre nell'altro caso potrebbe essere una registrazione quorum. I modelli possono variare, ma noi risolviamo il problema.<\/p>\n

Inoltre, avendo un registro distribuito delle richieste, possiamo scalare tutto ci\u00f2 \u2014 avere molti dispatcher ed esecutori che accedono a questo registro.<\/p>\n

\"Architettura
\n<\/p>\n

Cassandra e Tarantool insieme<\/h2>\n

\nC'\u00e8 anche un altro caso \u2014 \"vetrina dei bilanci\"<\/b>. Qui si presenta un caso interessante di applicazione congiunta di Cassandra e Tarantool.<\/p>\n

Utilizziamo Cassandra perch\u00e9 2 miliardi di chiamate al giorno non \u00e8 un limite, e ci saranno molti di pi\u00f9. I marketer amano colorare il traffico in base alle fonti, e i dettagli sui social media, per esempio, stanno aumentando. Questo contribuisce a costruire una storia pi\u00f9 ampia.<\/p>\n

Cassandra consente una scalabilit\u00e0 orizzontale per qualsiasi volume.<\/p><\/blockquote>\n

\nCi sentiamo a nostro agio con Cassandra, ma ha un problema: non \u00e8 molto performante in lettura. In scrittura va bene, 30.000 operazioni al secondo non sono un problema - il problema \u00e8 in lettura.<\/b>.<\/p>\n

Pertanto, \u00e8 emersa la questione della cache, e abbiamo anche risolto il seguente problema: esiste un vecchio caso tradizionale, in cui l'infrastruttura del commutatore per la tariffazione online produce file che carichiamo in Cassandra. Abbiamo affrontato il problema del caricamento affidabile di questi file, applicando persino il file transfer manager di IBM, ci sono soluzioni che gestiscono il trasferimento dei file in modo efficiente, utilizzando il protocollo UDP, per esempio, e non TCP. \u00c8 un'ottima cosa, ma il processo richiede comunque minuti, e finch\u00e9 non abbiamo completato il caricamento, l'operatore del call center non pu\u00f2 rispondere al cliente riguardo al suo saldo - bisogna aspettare.<\/p>\n

Per evitare che questo accada, abbiamo\u00a0applichiamo il failover funzionale parallelo<\/b>. Quando inviamo un evento tramite Kafka a Tarantool, ricalcolando gli aggregati in tempo reale, ad esempio, per oggi, otteniamo la cache dei saldi<\/b>, che pu\u00f2 restituire i saldi a qualsiasi velocit\u00e0, ad esempio, 100 mila transazioni al secondo e gli stessi 2 secondi.<\/p>\n

L'obiettivo \u00e8 che, dopo aver effettuato una chiamata, in soli 2 secondi nel pannello personale non ci sia solo il saldo modificato, ma anche un'informazione sul motivo per cui \u00e8 cambiato.<\/p>\n

Conclusione<\/h2>\n

\nQuesti sono stati degli esempi di utilizzo di Tarantool. Ci \u00e8 piaciuta molto l'apertura di Mail.ru, la loro disponibilit\u00e0 a considerare diversi casi. <\/p>\n

Ai consulenti di BCG o McKinsey, Accenture o IBM \u00e8 gi\u00e0 difficile sorprenderci con qualcosa di nuovo \u2014 molto di ci\u00f2 che propongono, noi lo facciamo gi\u00e0, lo abbiamo gi\u00e0 fatto o intendiamo farlo. Penso che Tarantool occupi una posizione dignitosa nel nostro stack tecnologico e sostituir\u00e0 molte tecnologie gi\u00e0 esistenti. Siamo in una fase attiva di sviluppo di questo progetto.<\/p>\n

La presentazione di Oleg e Andrey \u00e8 stata una delle migliori alla Tarantool Conference dell'anno scorso, e il 17 giugno Oleg Ivlev parler\u00e0 alla\u00a0T+ Conference 2019<\/a><\/noindex>\u00a0con una presentazione \u00abPerch\u00e9 Tarantool nell'Enterprise\u00bb<\/a><\/noindex>. Inoltre, da MegaFon interverr\u00e0 Aleksandr Deulin con una presentazione \u00abCache Tarantool e replica da Oracle\u00bb<\/a><\/noindex>. Scopriremo cosa \u00e8 cambiato e quali piani sono stati realizzati. Unisciti a noi: la conferenza \u00e8 gratuita, basta registrarsi<\/a><\/noindex>. Tutti i relatori sono stati accettati<\/a><\/noindex> e il programma della conferenza \u00e8 stato definito: nuovi casi, nuova esperienza nell'uso di Tarantool, architettura, enterprise, tutorial e microservizi.<\/p><\/blockquote>\n

Fonte: 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\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\udd47Architettura di fatturazione di nuova generazione: trasformazione con transizione a Tarantool | ProHoster","description":"Perch\u00e9 una corporation come MegaFon ha bisogno di Tarantool per la fatturazione? Dall'esterno sembra che di solito arrivi un fornitore, porti una grande scatola, colleghi la spina alla presa e voil\u00e0: ecco la fatturazione! In passato era cos\u00ec, ma ora \u00e8 obsoleto, e quei dinosauri sono gi\u00e0 estinti o si stanno estinguendo. Originariamente, la fatturazione era un sistema per l'emissione di fatture \u2014 un contapassi o una calcolatrice. Nel telecomunicazioni moderne, \u00e8 un sistema di automazione dell'intero ciclo di vita dell'interazione con il cliente.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/arhitektura-billinga-novogo-pokoleniya-transformatsiya-s-perehodom-na-tarantool","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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! \u041a\u043e\u0433\u0434\u0430-\u0442\u043e \u0442\u0430\u043a \u0438 \u0431\u044b\u043b\u043e, \u043d\u043e \u0441\u0435\u0439\u0447\u0430\u0441 \u044d\u0442\u043e \u0430\u0440\u0445\u0430\u0438\u043a\u0430, \u0438 \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 \u2014 \u0441\u0447\u0438\u0442\u0430\u043b\u043a\u0430 \u0438\u043b\u0438 \u043a\u0430\u043b\u044c\u043a\u0443\u043b\u044f\u0442\u043e\u0440. \u0412 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e\u043c \u0442\u0435\u043b\u0435\u043a\u043e\u043c\u0435 \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 \u0430\u0431\u043e\u043d\u0435\u043d\u0442\u043e\u043c","og:url":"https:\/\/prohoster.info\/it\/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"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/37650","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=37650"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/37650\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/28258"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=37650"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=37650"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=37650"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}