{"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 di billing di nuova generazione: trasformazione con il passaggio a Tarantool","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Perch\u00e9 una corporation come MegaFon ha bisogno di Tarantool nella fatturazione? Dall'esterno sembra che di solito arrivi un fornitore, porti una grande scatola, colleghi la spina nella presa e voil\u00e0, \u00e8 fatta la fatturazione! Una volta era cos\u00ec, ma ora \u00e8 un'eresia, e quei dinosauri sono gi\u00e0 estinti o stanno scomparendo. Inizialmente, la fatturazione era un sistema per emettere fatture - un contapassi o una calcolatrice. Nei moderni servizi di telecomunicazione, \u00e8 un sistema di automazione dell'intero ciclo di vita dell'interazione con l'abbonato, dalla stipula del contratto alla risoluzione<\/b>, inclusa la tarificazione in tempo reale, l'accettazione dei pagamenti e molto altro. La fatturazione nelle compagnie di telecomunicazioni somiglia a un robot da combattimento - grande, potente e armato fino ai denti.<\/p>\n

\"Architettura
\n
\nE cosa c'entra Tarantool? Ne parleranno Oleg Ivlev<\/b> e\u00a0Andrey Knyazev<\/b>. Oleg \u00e8 il chief architect della compagnia 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 \u00e8 necessario R&D nelle corporation, cos'\u00e8 Tarantool, come l'impasse della scalabilit\u00e0 verticale e la globalizzazione siano state le premesse per l'emergere di questo DB in azienda, le sfide tecnologiche, la trasformazione dell'architettura, e come la tech stack di MegaFon assomigli a Netflix, Google e Amazon.
\n<\/a><\/noindex>
\n

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

Il progetto \"Fatturazione Unificata\"<\/h2>\n

\nIl progetto di cui si parler\u00e0 si chiama \"Fatturazione Unificata\". \u00c8 proprio in questo che Tarantool ha dimostrato le sue migliori qualit\u00e0. <\/p>\n

\"Architettura
\n
\nLa crescita delle prestazioni dell'hardware Hi-End non riusciva a tenere il passo con la crescita del numero di abbonati e dei servizi, si prevedeva una ulteriore crescita del numero di abbonati e servizi grazie a M2M, IoT, e le peculiarit\u00e0 delle filiali portavano a un aggravamento del time-to-market. L'azienda ha deciso di creare un'unica sistema aziendale con un'architettura modulare unica a livello mondiale, in sostituzione delle 8 diverse attuali fatturazioni.<\/p>\n

MegaFon \u00e8 otto aziende in una<\/b>. Nel 2009 \u00e8 terminata la riorganizzazione: le filiali in tutta la Russia si sono unite in un'unica azienda OAO \"MegaFon\" (ora PJSC). Cos\u00ec, nell'azienda sono apparse 8 fatturazioni con le proprie soluzioni \"personalizzate\", peculiarit\u00e0 delle filiali e diverse strutture organizzative, IT e marketing.<\/p>\n

Tutto stava andando bene finch\u00e9 non ci siamo trovati a dover lanciare un prodotto federale comune. Sono emerse molte complessit\u00e0: alcuni avevano tariffe che arrotondavano per eccesso, altri per difetto, e altri ancora secondo la media aritmetica. Ci sono migliaia di questi aspetti.<\/p>\n

Nonostante la versione del sistema di fatturazione sia una, con un solo fornitore, le impostazioni erano cos\u00ec diverse che l'unione richiedeva tempo. Abbiamo cercato di ridurre il loro numero, ma ci siamo imbattuti in un secondo problema, familiare a molte corporazioni.<\/p>\n

Scalabilit\u00e0 verticale<\/b>. Anche l'hardware pi\u00f9 avanzato dell'epoca non soddisfaceva le esigenze. Utilizzavamo apparecchiature Hewlett-Packard, della linea Superdome Hi-End, ma non erano sufficienti nemmeno per due filiali. Volevamo una scalabilit\u00e0 orizzontale senza grandi costi operativi e investimenti di capitale.<\/p>\n

Aspettativa di crescita del numero di abbonati e servizi<\/b>. I consulenti avevano da tempo portato nel mondo delle telecomunicazioni storie su IoT e M2M: arriver\u00e0 il momento in cui ogni telefono e ogni ferro da stiro avr\u00e0 una SIM, e ogni frigorifero ne avr\u00e0 due. Oggi abbiamo un certo numero di abbonati, ma nel prossimo futuro saranno di gran lunga di pi\u00f9.<\/p>\n

Sfide tecnologiche<\/h2>\n

\nQueste quattro ragioni ci hanno spinto a effettuare cambiamenti seri. Avevamo una scelta tra modernizzare il sistema e progettare da zero. Abbiamo riflettuto a lungo, preso decisioni importanti, indetto gare. Alla fine abbiamo deciso di progettare fin dall'inizio e ci siamo messi alla prova con sfide interessanti: sfide tecnologiche.<\/p>\n

Scalabilit\u00e0<\/h3>\n

\nSe in passato c'erano, diciamo cos\u00ec, 8 fatturazioni per 15 milioni di abbonati<\/b>, ora dovevamo ottenere 100 milioni di abbonati e oltre<\/b>\u00a0\u2014 il carico era di gran lunga superiore.<\/p>\n

Siamo diventati comparabili in termini di scala con grandi attori di Internet come Mail.ru o Netflix.<\/p><\/blockquote>\n

\nMa il movimento successivo per aumentare il carico e il numero di abbonati ha posto davanti a noi compiti seri.<\/p>\n

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

\nTra Kaliningrad e Vladivostok 7500 km e 10 fusi orari<\/b>. La velocit\u00e0 della luce \u00e8 finita e a tali distanze i ritardi diventano significativi. 150 ms sui canali ottici pi\u00f9 avanzati \u00e8 troppo per la fatturazione in tempo reale, specialmente per quella attuale nelle telecomunicazioni in Russia. Inoltre, \u00e8 necessario aggiornarsi in un giorno lavorativo, e con diversi fusi orari questo diventa un problema.<\/p>\n

Non offriamo semplicemente servizi con abbonamento, ma abbiamo tariffe complesse, pacchetti e variatori. Non dobbiamo solo permettere o vietare all'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

Resilienza<\/h3>\n

<\/p>\n

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

\nSe raggruppiamo tutti gli abbonati in un unico sistema, qualsiasi evento di emergenza e catastrofe \u00e8 disastroso per il business. Pertanto, progettiamo il sistema in modo da escludere l'impatto delle emergenze su tutto il bacino di abbonati.<\/p>\n

Questo \u00e8 di nuovo una conseguenza del rifiuto della scalabilit\u00e0 verticale. Quando siamo passati alla scalabilit\u00e0 orizzontale, abbiamo aumentato il numero di server da centinaia a migliaia. Bisogna gestirli e costruire interscambiabilit\u00e0, riservare automaticamente l'infrastruttura IT e ripristinare il sistema distribuito.<\/p>\n

Abbiamo affrontato sfide cos\u00ec interessanti. Abbiamo progettato il sistema e in quel momento abbiamo cercato esperienze di successo a livello mondiale per verificare quanto fossimo in linea con le tendenze e quanto seguissero le tecnologie avanzate.<\/p>\n

Esperienza mondiale<\/h2>\n

<\/p>\n

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

\nL'Europa ha perso in termini di numero di abbonati e di scala, gli Stati Uniti per l'ampiezza delle loro tariffe. Abbiamo esaminato qualcosa in Cina e trovato altro in India, portando esperti da Vodafone India.<\/p>\n

Per analizzare l'architettura, abbiamo riunito una Dream Team guidata da IBM - architetti provenienti da vari settori. Queste persone potrebbero valutare in modo adeguato ci\u00f2 che stiamo facendo e portare nella nostra architettura determinate conoscenze.<\/p>\n

Scalabilit\u00e0<\/h2>\n

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

Progettiamo il sistema per 80 milioni di abbonati con un margine per un miliardo<\/b>. Cos\u00ec rimuoviamo le soglie future. Non perch\u00e9 abbiamo intenzione di conquistare la Cina, ma a causa della pressione dell'IoT e del M2M.<\/p>\n

300 milioni di documenti vengono elaborati in tempo reale<\/b>. Anche se abbiamo 80 milioni di abbonati, lavoriamo anche con clienti potenziali e con coloro che ci hanno lasciato, se \u00e8 necessario recuperare crediti. Pertanto, i volumi reali sono notevolmente maggiori.<\/p>\n

2 miliardi di transazioni<\/b> cambiano quotidianamente il saldo: si tratta di pagamenti, accrediti, chiamate e altri eventi.\u00a0200 TB di dati cambiano attivamente<\/b>, un po' pi\u00f9 lentamente cambiano 8 PB di dati<\/b>, e non \u00e8 un archivio, ma dati live in un unico billing. Scalabilit\u00e0 sui datacenter - 5 mila server su 14 siti<\/b>.<\/p>\n

Stack tecnologico<\/h2>\n

\nQuando abbiamo pianificato l'architettura e ci siamo messi a costruire il sistema, abbiamo fatto nostro le tecnologie pi\u00f9 interessanti e avanzate. \u00c8 nato uno stack tecnologico, familiare a qualsiasi attore di internet e a corporation che realizzano sistemi ad alta capacit\u00e0. <\/p>\n

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

Flessibilit\u00e0 \u00e8 importante, ma in una grande corporazione senza unificazione non si pu\u00f2 andare avanti.<\/p><\/blockquote>\n

\nNon abbiamo intenzione di sostituire Oracle con Tarantool. Nella realt\u00e0 delle grandi aziende \u00e8 un'utopia, o una crociata di 5-10 anni con un esito incerto. Ma Cassandra e Couchbase possono essere sostituiti con Tarantool, e a questo miriamo.<\/p>\n

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

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

Velocit\u00e0<\/b>. Abbiamo condotto test di carico sui sistemi industriali di MegaFon. Tarantool ha vinto - ha mostrato le migliori prestazioni.<\/p>\n

Non si pu\u00f2 dire che altri sistemi non soddisfano le esigenze di MegaFon. Le attuali soluzioni di memoria sono cos\u00ec performanti che questa riserva \u00e8 pi\u00f9 che sufficiente all'azienda. Ma ci interessa collaborare con un leader, non con chi \u00e8 in coda, anche in relazione ai test di carico.<\/p>\n

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

\nCosto totale di propriet\u00e0 (TCO)<\/b>. Il supporto per Couchbase sui volumi di MegaFon costa cifre astronomiche, mentre la situazione con Tarantool \u00e8 molto pi\u00f9 favorevole e in termini di funzionalit\u00e0 sono simili.<\/p>\n

Un'altra caratteristica piacevole che ha influenzato un po' la nostra scelta - Tarantool lavora meglio delle altre basi con la memoria. Mostra la massima efficienza.<\/b>.<\/p>\n

Affidabilit\u00e0<\/b>. MegaFon investe nella sicurezza, probabilmente come nessun altro. Quindi, quando abbiamo esaminato Tarantool, abbiamo capito che dovevamo assicurarci che soddisfacesse le nostre esigenze.<\/p>\n

Abbiamo investito tempo e denaro, e insieme a Mail.ru abbiamo creato una versione enterprise, gi\u00e0 utilizzata in altre aziende.<\/p>\n

Tarantool-enterprise ci ha completamente soddisfatti in termini di sicurezza, affidabilit\u00e0, e log.<\/p><\/blockquote>\n

<\/p>\n

Partnership<\/h3>\n

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

Se vieni da un giocatore, specialmente uno che lavora con un cliente ancorato, e dici che hai bisogno che il DB sappia fare questo, questo e quest'altro, di solito risponde:<\/p>\n

\u2014 Va bene, mettete le richieste in fondo a quella pila \u2014 prima o poi, probabilmente, ci arriveremo.<\/i><\/p>\n

Molti hanno una roadmap per i prossimi 2-3 anni, e integrarsi l\u00ec dentro \u00e8 praticamente impossibile, mentre gli sviluppatori di Tarantool conquistano con la loro apertura, sia con MegaFon che con altri, e adattano il loro sistema per il cliente. Questo \u00e8 fantastico, e ci piace molto.<\/p>\n

Dove abbiamo applicato Tarantool<\/h2>\n

\nDa noi Tarantool viene utilizzato in diversi elementi. Il primo \u00e8 nel pilota<\/b>, che abbiamo creato sul sistema del catalogo indirizzi. Volevamo che fosse un sistema simile a Yandex.Maps e Google Maps, ma \u00e8 venuto fuori in modo diverso. <\/p>\n

Per esempio, il catalogo indirizzi nell'interfaccia di vendita. Su Oracle la ricerca di un indirizzo richiede 12-13 secondi \u2014 cifre poco confortanti. Quando ci spostiamo su Tarantool, sostituiamo Oracle con un altro DB nella console e facciamo la stessa ricerca, otteniamo un'accelerazione di 200 volte! La citt\u00e0 compare dopo la terza lettera. Ora stiamo adattando l'interfaccia affinch\u00e9 questo avvenga dopo la prima. Tuttavia, la velocit\u00e0 di risposta \u00e8 completamente diversa \u2014 gi\u00e0 millisecondi invece di secondi.<\/p>\n

La seconda applicazione \u00e8 un argomento di moda chiamato IT a due velocit\u00e0<\/b>. Tutto perch\u00e9 i consulenti da ogni parte dicono che le corporazioni dovrebbero andarci.<\/p>\n

\"Architettura
\n
\nC'\u00e8 uno strato di infrastruttura, sopra ci sono i domini, ad esempio, un sistema di billing, come quello delle telecomunicazioni, sistemi aziendali, reportistica aziendale. Questo \u00e8 il nucleo, che non bisogna toccare. Cio\u00e8, certo, si pu\u00f2 fare, ma con un'ossessione paranoica per garantire la qualit\u00e0, perch\u00e9 questo porta soldi alle corporazioni.<\/p>\n

Poi c'\u00e8 uno strato di microservizi \u2014 ci\u00f2 che differenzia l'operatore o un altro giocatore. I microservizi possono essere creati rapidamente sulla base di alcune cache, portando i dati da diversi domini. Qui c'\u00e8 un campo per esperimenti<\/b>\u00a0\u2014 se qualcosa non funziona, chiudi un microservizio e apri un altro. Questo garantisce un time-to-market realmente aumentato e incrementa l'affidabilit\u00e0 e la velocit\u00e0 dell'azienda.<\/p>\n

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

<\/p>\n

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

\nSe paragoniamo il nostro progetto di billing di successo con i programmi di trasformazione di Deutsche Telekom, Svjazn'kom, Vodafone India, risulta incredibilmente dinamico e creativo. Nel processo di realizzazione di questo progetto non solo \u00e8 stata trasformata MegaFon e la sua struttura, ma \u00e8 nato anche Tarantool-enterprise presso Mail.ru, e dal nostro fornitore Nexign (precedentemente \"Peterservizi\") \u2013 BSS Box (soluzione di billing in scatola).<\/p>\n

Questo \u00e8, in un certo senso, un progetto storico per il mercato russo. Pu\u00f2 essere paragonato a quanto descritto nel libro di Frederick Brooks \"Il mito dell'uomo mese\". Allora, negli anni '60, per sviluppare un nuovo sistema operativo OS\/360 per i mainframe, IBM coinvolse 5.000 persone. Noi siamo meno \u2013 1.800, ma i nostri in maglietta a righe, e tenendo conto dell'uso dell'open source e di nuovi approcci, lavoriamo in modo pi\u00f9 produttivo.<\/p>\n

Di seguito sono riportati i domini di billing o, per dirla in modo pi\u00f9 ampio, \u2013 sistemi aziendali. Le persone dell'enterprise conoscono perfettamente il CRM. Altri sistemi dovrebbero gi\u00e0 essere a disposizione di tutti: Open API, API Gateway.<\/p>\n

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

Open API<\/h3>\n

\nRivediamo di nuovo i numeri e come funziona attualmente l'Open API. Il suo carico \u00e8 10.000 transazioni al secondo<\/b>. Poich\u00e9 prevediamo di sviluppare attivamente il layer dei microservizi e costruire un API pubblico per MegaFon, ci aspettiamo una maggiore crescita in futuro proprio in questo settore.\u00a0Sicuramente 100.000 transazioni ci saranno<\/b>.<\/p>\n

Non so se ci confronteremo in SSO con Mail.ru \u2013 i ragazzi hanno, a quanto pare, 1.000.000 transazioni al secondo. La loro soluzione \u00e8 estremamente interessante per noi e prevediamo di apprendere dalla loro esperienza \u2013 ad esempio, creare una riserva funzionale SSO con l'aiuto di Tarantool. Attualmente i programmatori di Mail.ru se ne stanno occupando per noi.<\/p>\n

CRM<\/h2>\n

\nIl CRM sono i famosi 80 milioni di abbonati che vogliamo portare a un miliardo, perch\u00e9 ci sono gi\u00e0 300 milioni di documenti che includono una storia di tre anni. Aspettiamo davvero nuovi servizi, e qui il punto di crescita sono i servizi connessi<\/b>. Questo \u00e8 un ambito che crescer\u00e0, perch\u00e9 i servizi saranno sempre di pi\u00f9. Di conseguenza, avremo bisogno di una storia, non vogliamo inciampare su questo.<\/p>\n

Il billing stesso nella parte di emissione fatture e gestione dei crediti dei clienti si \u00e8 trasformato in un dominio separato<\/b>. Per aumentare la produttivit\u00e0, \u00e8 stato applicato un modello architetturale di architettura a dominio<\/b>.<\/p>\n

Il sistema \u00e8 suddiviso in domini, il carico \u00e8 distribuito e garantita la disponibilit\u00e0. Inoltre, sono stati effettuati interventi sull'architettura distribuita.<\/p><\/blockquote>\n

\nTutto il resto \u00e8 costituito da soluzioni di livello enterprise. Nel database delle chiamate - 2 miliardi al giorno<\/b>, 60 miliardi al mese. A volte \u00e8 necessario ricalcolarli per mese, e meglio farlo rapidamente. Monitoraggio finanziario<\/b>\u00a0\u00e8 proprio l'insieme di 300 milioni che cresce costantemente: gli abbonati spesso passano da un operatore all'altro, aumentando questa parte.<\/p>\n

Il componente pi\u00f9 telecomunicativo della telefonia mobile \u00e8 la tariffazione online<\/b>. Questi sono i sistemi che ti permettono di chiamare o meno, prendendo decisioni in tempo reale. Qui il carico \u00e8 di 30.000 transazioni al secondo, ma tenendo conto della crescita della trasmissione dati, prevediamo 250.000 transazioni<\/b>, ed \u00e8 per questo che siamo molto interessati a Tarantool.<\/p>\n

L'immagine precedente mostra i domini in cui intendiamo applicare Tarantool. L'intero CRM, ovviamente, \u00e8 pi\u00f9 ampio e intendiamo applicarlo nel nucleo stesso. <\/p>\n

La nostra cifra programmata TTH di 100 milioni di abbonati preoccupa me come architetto: e se fossero 101 milioni? Di nuovo tutto da rifare? Per evitare ci\u00f2, utilizziamo cache, aumentando al contempo la disponibilit\u00e0.<\/p>\n

\"Architettura
\n
\nFondamentalmente, ci sono due approcci all'applicazione di Tarantool. Il primo \u00e8 costruire tutte le cache a livello di microservizi<\/b>. A quanto pare, su questa strada sta procedendo VimpelCom, creando cache per i clienti.<\/p>\n

Noi, invece, siamo meno dipendenti dai fornitori, cambiamo il nucleo BSS, quindi abbiamo una scheda clienti gi\u00e0 di serie. Ma vogliamo ampliare questo. Pertanto, applichiamo un approccio leggermente diverso \u2014 creiamo cache all'interno dei sistemi<\/b>.<\/p>\n

In questo modo si riduce la desincronizzazione: un sistema si occupa sia della cache che della fonte principale.<\/p><\/blockquote>\n

\nIl metodo si adatta bene all'approccio di Tarantool con uno scheletro transazionale, dove vengono aggiornati solo i pezzi relativi agli aggiornamenti, cio\u00e8 le modifiche ai dati. Tutto il resto pu\u00f2 essere conservato altrove. Non ci sono enormi data lake, cache globali incontrollabili. Le cache vengono progettate per il sistema, o per i prodotti, o per i clienti, o per semplificare la vita al servizio. Quando chiama un abbonato frustrato per la qualit\u00e0, si desidera servirlo in modo efficace.<\/p>\n

RTO e RPO<\/h2>\n

\nNel settore IT esistono due termini - RTO<\/b> e\u00a0RPO<\/b>. <\/p>\n

Recovery time objective<\/b>\u00a0\u2014 \u00e8 il tempo di ripristino del servizio dopo un guasto. RTO = 0 significa che anche se qualcosa va in crash, il servizio continua a funzionare.<\/p>\n

obiettivo di punto di ripristino<\/b>\u00a0\u2014 \u00e8 il tempo di recupero dei dati, quanta informazione 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 il compito per Tarantool.<\/p>\n

Dati<\/b>: un chiaro carrello di ordini, ad esempio, su Amazon o altrove. Richiesta<\/b> affinch\u00e9 il carrello funzioni 24 ore su 24, 7 giorni su 7, o 99,99% del tempo. Gli ordini che ci arrivano devono mantenere un certo ordine, perch\u00e9 non possiamo attivare o disattivare la connessione al cliente in modo caotico \u2014 tutto deve essere rigorosamente sequenziale. L'abbonamento precedente influisce su quello successivo, quindi i dati sono importanti \u2014 nulla deve andare perso.<\/p>\n

Soluzione<\/b>. Si potrebbe provare a risolverlo in modo diretto e chiedere ai programmatori del DB, ma il problema non \u00e8 matematicamente risolvibile. Si possono ricordare teoremi, leggi di conservazione, fisica quantistica, ma perch\u00e9 \u2014 non \u00e8 possibile risolverlo a livello di DB.<\/p>\n

Qui funziona il vecchio e caro approccio architetturale \u2014 \u00e8 necessario conoscere bene il dominio per risolvere questo enigma.<\/p>\n

\"Architettura
\n
\nLa nostra soluzione: creiamo un registro distribuito di richieste su Tarantool \u2014 cluster geodistribuito<\/b>. Nello schema ci sono tre diversi centri di elaborazione dati \u2014 due prima degli Urali, uno oltre 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. Alla vigilia del Natale cattolico, il 24 dicembre, quel data center ha smesso di funzionare. Gli utenti in Canada e negli Stati Uniti sono rimasti senza i loro film preferiti, si sono molto rattristati e hanno scritto di questo sui social media. Ora Netflix ha tre data center sulla costa occidentale-orientale e uno in Europa occidentale. <\/p>\n

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

\nQuindi, abbiamo un cluster, ma come affrontare RPO = 0 e RTO = 0? La soluzione \u00e8 semplice, dipende dal dominio.<\/p>\n

Cosa \u00e8 importante nelle richieste? Due parti: la fase di riempimento del carrello\u00a0PRIMA<\/b> di prendere una decisione d'acquisto, e\u00a0DOPO<\/b>. La parte PRIMA nel telecomunicazioni \u00e8 solitamente chiamata cattura ordine<\/b> o negoziazione dell'ordine<\/b>. Nel settore delle telecomunicazioni, questo pu\u00f2 essere molto pi\u00f9 complesso rispetto a un negozio online, poich\u00e9 \u00e8 necessario assistere il cliente, offrire 5 opzioni, e tutto ci\u00f2 richiede del tempo, ma il carrello si riempie. In questo momento \u00e8 possibile un guasto, ma non \u00e8 un problema, perch\u00e9 si svolge in modalit\u00e0 interattiva sotto la supervisione di una persona. <\/p>\n

Se il Data Center di Mosca dovesse improvvisamente guastarsi, passando automaticamente a un altro Data Center, continueremo a lavorare. Teoricamente potrebbe perdersi un prodotto nel carrello, ma lo vedete, potete riempire di nuovo il carrello e continuare a lavorare. In questo caso RTO = 0.<\/p>\n

Allo stesso momento, c'\u00e8 un'altra opzione: quando premiamo 'submit', vogliamo che i dati non vengano persi. Da questo momento viene attivata l'automazione - qui RPO = 0. L'applicazione di questi due diversi modelli in un caso pu\u00f2 essere semplicemente un cluster geograficamente distribuito con un master switchable, nell'altro caso potrebbe essere qualche tipo di scrittura quorum. I modelli possono variare, ma risolviamo il problema.<\/p>\n

Inoltre, avendo un registro distribuito delle richieste, possiamo anche scalare tutto questo - avere molti dispatcher ed esecutori che si rivolgono a questo registro.<\/p>\n

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

Cassandra e Tarantool insieme<\/h2>\n

\nC'\u00e8 un altro caso - \"vetrina dei saldi\"<\/b>. Qui c'\u00e8 proprio un caso interessante di applicazione congiunta di Cassandra e Tarantool.<\/p>\n

Utilizziamo Cassandra perch\u00e9 2 miliardi di chiamate al giorno non sono un limite, e ce ne saranno di pi\u00f9. I marketer amano segmentare il traffico per fonte, emergono sempre pi\u00f9 dettagli sui social network, per esempio. Questo aumenta la storia.<\/p>\n

Cassandra consente di scalare orizzontalmente a qualsiasi volume.<\/p><\/blockquote>\n

\nCi sentiamo a nostro agio con Cassandra, ma ha un problema: non \u00e8 buona nella lettura. Nella scrittura tutto va bene, 30.000 al secondo non \u00e8 un problema - il problema \u00e8 nella lettura<\/b>.<\/p>\n

Pertanto \u00e8 emersa la questione della cache, e abbiamo anche deciso di affrontare il seguente problema: esiste un vecchio caso tradizionale, quando i dati dall\u2019online tariffazione del cambiatore arrivano in file, che carichiamo in Cassandra. Abbiamo affrontato il problema dell'affidabilit\u00e0 nel caricamento di questi file, abbiamo persino applicato il consiglio del manager IBM per il trasferimento file - ci sono soluzioni che gestiscono il trasferimento dei file in modo efficiente, utilizzando ad esempio il protocollo UDP, e non TCP. Questo \u00e8 buono, ma ci vogliono comunque dei minuti, e finch\u00e9 non carichiamo tutto questo, l'operatore nel call center non pu\u00f2 rispondere al cliente riguardo a cosa sia successo al suo saldo - bisogna aspettare.<\/p>\n

Per evitare che ci\u00f2 accada, noi\u00a0utilizziamo un backup funzionale parallelo<\/b>. Quando inviamo un evento attraverso Kafka a Tarantool, ricalcolando gli aggregati in tempo reale, ad esempio per oggi, otteniamo una cache dei saldi<\/b>, che pu\u00f2 restituire 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 gi\u00e0 dopo 2 secondi nell'area personale non ci sia solo il saldo modificato, ma anche le informazioni su perch\u00e9 sia cambiato.<\/p>\n

Conclusione<\/h2>\n

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

Per i consulenti di BCG, McKinsey, Accenture o IBM \u00e8 gi\u00e0 difficile sorprenderci con qualcosa di nuovo: molto di quanto propongono, o lo facciamo gi\u00e0, o l'abbiamo fatto, oppure lo stiamo pianificando. Penso che Tarantool avr\u00e0 un posto di riguardo nel nostro stack tecnologico e sostituir\u00e0 molte delle tecnologie gi\u00e0 esistenti. Siamo nella fase attiva di sviluppo di questo progetto.<\/p>\n

La presentazione di Oleg e Andrey \u00e8 stata una delle migliori alla Tarantool Conference dello scorso anno, e gi\u00e0 il 17 giugno Oleg Ivlev si esibir\u00e0 alla\u00a0T+ Conference 2019<\/a><\/noindex>\u00a0con una presentazione \u00abPerch\u00e9 Tarantool in Enterprise\u00bb<\/a><\/noindex>. Anche da MegaFon parler\u00e0 Alexander Deulin con una presentazione \u00abCache di Tarantool e replicazione da Oracle\u00bb<\/a><\/noindex>. Scopriremo cosa \u00e8 cambiato, quali piani sono stati realizzati. Unitevi a noi - la conferenza \u00e8 gratuita, basta solo registrarsi<\/a><\/noindex>. Tutti le presentazioni sono state accettate<\/a><\/noindex> e il programma della conferenza \u00e8 stato formato: nuovi casi, nuove esperienze di utilizzo 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 della fatturazione di nuova generazione: trasformazione con il passaggio a Tarantool | ProHoster","description":"Perch\u00e9 una societ\u00e0 come MegaFon ha bisogno di Tarantool nella fatturazione? Dall'esterno sembra che di solito arrivi un fornitore, porti una grande scatola, colleghi la spina nella presa e voil\u00e0: ecco la fatturazione!","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!","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}