Tecnologia Wells Fargo SF Bay Area

scalata .NET Core App e microservizi per prestazioni estreme

Per .NET, Java e Node.js

Di Iqbal Khan
Presidente ed evangelista tecnologico

Le applicazioni server di oggi devono elaborare molte transazioni molto velocemente. Molte di queste sono applicazioni web che servono milioni di utenti ogni giorno. Altri sono microservizi che servono milioni di app mobili o dispositivi intelligenti Internet of Things (IoT).

La maggior parte di queste applicazioni viene ora distribuita in contenitori come Kubernetes per semplificare e automatizzare la distribuzione, il ridimensionamento e la gestione. Inoltre, la scelta degli ambienti di distribuzione si è spostata dall'on-premise a cloud leader come AWS, Azure, Google Cloud e altri ancora.

Scopri come sviluppare applicazioni che soddisfano gli odierni requisiti di prestazioni estreme rimuovendo i colli di bottiglia delle prestazioni relativi all'archiviazione dei dati e ai database e anche la comunicazione tra le diverse parti delle applicazioni di microservizi.

Panoramica

Grazie mille Mike e grazie Jason per avermi dato l'opportunità di parlare con un gruppo così importante a Wells Fargo, il San Francisco Bay Area Technology Group. Come ha detto Mike, io lavoro a Alachisoft e la parola Alachi, che stavo spiegando a Mike e Jason, è una specie di derivata dalla parola hindi Ellachi che è o Elaichi, che è un nome di spezia cardamomo. Quindi, stavamo solo nominando l'azienda molti anni fa e volevamo creare qualcosa di unico, quindi abbiamo pensato Alachisoft.

Il nostro prodotto lo è in realtà NCache. Quindi, non ho intenzione di parlare NCache. Il discorso di oggi riguarda "Come puoi scalare le tue applicazioni Web e i microservizi a prestazioni estreme?" Se stai sviluppando queste applicazioni in Java, .NET, .NET Core o Node.js, allora sei arrivato al discorso giusto.

Che cos'è la scalabilità?

Quindi, cerchiamo di capire alcune definizioni, prima di entrare nel discorso vero e proprio. Il primo è: cos'è la scalabilità? La scalabilità è in realtà prestazioni elevate dell'applicazione ma con carichi di picco. Quindi, se la tua applicazione ha prestazioni super veloci con solo 5 utenti, non è realmente scalabile a meno che tu non abbia le stesse super prestazioni in una velocità con 5000, 50,000 o 500,000 utenti. Se la tua applicazione può farlo, allora è scalabile e ovviamente vogliamo che molte delle nostre applicazioni siano scalabili e ne parlerò.

Che cos'è la scalabilità lineare?

La definizione successiva è "Cos'è la scalabilità lineare?" Questa è più un'architettura dell'applicazione e una terminologia di distribuzione. Se la tua applicazione è progettata correttamente, sarà linearmente scalabile, il che significa che se hai bisogno di aumentare la capacità di transazione al secondo, che significa quanti utenti puoi gestire? Quante richieste di applicazione puoi gestire? Se vuoi aumentarlo, aggiungi semplicemente più server e ogni server che aggiungi aumenta la capacità delle transazioni al secondo in modo lineare.

Quindi, non c'è blocco, non c'è collo di bottiglia. Ovviamente, le curve di lettura e scrittura sono diverse ma sono entrambe lineari. Se puoi farlo, la tua applicazione è linearmente scalabile e questo è qualcosa che vogliamo assolutamente.

Che cos'è la scalabilità non lineare?

Questo è qualcosa che non vogliamo ed è se hai progettato la tua applicazione in un modo in cui ci sono alcuni colli di bottiglia, quindi, man mano che aumenti il ​​carico sull'applicazione e aggiungi più caselle, qualcosa inizia a cedere e la tua applicazione si avvia per rallentare, infatti, anche a volte si blocca.

Quindi, non vogliamo assolutamente che le nostre applicazioni siano progettate per essere non linearmente scalabili.

Chi ha bisogno della scalabilità?

Ok, quindi, ora che abbiamo capito cosa significa scalabilità, la prossima cosa da capire è, chi ne ha bisogno? Quali applicazioni necessitano di scalabilità?

• App Web

  Le applicazioni più comuni sono le applicazioni web. Questi sono per una banca come Wells Fargo o altre banche con cui lavoriamo come Citi Group e, Bank of America e, Barclays e, Bank of Tokyo. Queste sono applicazioni rivolte ai clienti, hai wellsfargo.com, che è per il consumer banking e le piccole imprese e queste applicazioni web devono essere in grado di gestire molti utenti senza rallentare. Quindi, è molto importante che queste applicazioni funzionino in modo super veloce sotto carico estremo.

• Servizi Web/API Web

  Il numero due sono i servizi web, le applicazioni API web. Questi sono generalmente lì per servire molte applicazioni mobili o qualsiasi altra applicazione che li chiama per svolgere determinate attività. Quindi, se hai, diciamo, Wells Fargo ha un'applicazione mobile per il consumer banking, quell'applicazione mobile deve parlare con un back-end e quel back-end oggi è molto probabilmente servizi web. Ovviamente, non lo so, ma presumo che lo sia, perché molte delle altre banche con cui lavoriamo hanno questa situazione in cui i servizi Web sono quelli che gestiscono questa richiesta di applicazione mobile. E hanno la stessa identica sensibilità. Devono essere in grado di gestire molto carico senza rallentare.

• Microservices

  Microservizi è qualcosa che è una parola d'ordine molto in voga in questi giorni e, ne parlerò un po' di più tra un po', ma essenzialmente è che stai riprogettando i servizi web in un modo nuovo e migliore, fammi dillo così in questo momento.

• Applicazioni server

  Il quarto tipo di applicazione è qualsiasi altra app server che potresti avere. Potrebbero essere che le app del server stiano eseguendo l'elaborazione batch. Questi potrebbero anche gestire transazioni in tempo reale, ma rientrano in un'altra categoria. Ma hanno anche lo stesso tipo di requisito di velocità effettiva di transazione al secondo.

Quindi, se stai sviluppando uno di questi quattro tipi di applicazioni. Ce ne sono anche altri, diciamo, potresti fare live machine learning e intelligenza artificiale, ma non ne parlerò in questo discorso, non abbiamo abbastanza tempo. Ma, diciamo, se hai queste quattro applicazioni, hai sicuramente bisogno che siano scalabili. E questo è il discorso che li esaminerà. Per quanto riguarda la tecnologia, le applicazioni web in genere, sono sviluppate in Java o ASP.NET, ASP.NET Core, essendo la nuova versione di ASP.NET e Node.js e, tutti gli altri tre tipi sono Java o .NET/.NET Core, I microservizi sono in Java o .NET Core perché è la nuova tecnologia.

Introduzione ai microservizi

Per quelli di voi che non sanno che aspetto hanno i microservizi, volevo solo darvi una breve visione architettonica di esso. E, per chi lo fa, abbi pazienza con me. Quindi, un microservizio, il motivo per cui stanno diventando così popolari perché ti consentono di suddividere le tue applicazioni monolitiche in microservizi di dimensioni byte e ogni microservizio è disaccoppiato da altri microservizi. E quel disaccoppiamento significa che non si chiamano a vicenda. Hanno i loro database solitamente logici. Non devono avere database fisici separati ma, almeno logicamente, di solito hanno i propri. Alcuni dei microservizi potrebbero utilizzare a NoSQL database, MongoDB o qualcos'altro. Alcuni di loro utilizzeranno database relazionali, SQL Server, Oracle, DB2. Alcuni di loro potrebbero andare ai dati del mainframe legacy.

Quindi, il disaccoppiamento richiede loro di parlare tra loro attraverso una sorta di bus di eventi, che è quello che è il tubo sul lato destro. Inoltre, vengono chiamati da applicazioni mobili, applicazioni Web a pagina singola o applicazioni Web MVC standard in Java, .NET o Node.js, tramite il gateway API. Quindi, questa è solo una buona visione di cosa sono i microservizi. E andrò a vedere come anche loro hanno gli stessi problemi di scalabilità che altre applicazioni hanno avuto tradizionalmente.

Ambienti di distribuzione delle app

Un'altra cosa a cui volevo toccare rapidamente la base perché volevo inserire il contesto attorno a ciò di cui parlerò, i diversi tipi di ambienti di distribuzione che abbiamo dovuto affrontare nel corso degli anni. Lo faccio da più di 15 anni ormai e per molto tempo è stato tutto in locale, data center con il pieno controllo. Anche ora, molte delle banche con cui lavoriamo, sono ancora con i propri data center. Ma quasi tutti si stanno spostando o almeno pianificano di passare al cloud. Alcune piccole e medie imprese passano al cloud pubblico. Soprattutto molte aziende più grandi, ancora una volta i servizi finanziari e le banche preferiscono generalmente un'implementazione di cloud privato. In effetti, alcune delle banche con cui lavoriamo preferiscono un cloud privato su un framework di tipo Pivotal Cloud Foundry o Red Hat Open Stack, che offre loro il controllo totale sull'ambiente del cloud privato, indipendentemente da dove il esiste il cloud privato. Indipendentemente dal fatto che esista all'interno di un cloud pubblico come spazio affittato o che sia sopra il loro data center che hanno in questo momento, o sia qualcos'altro, dà loro la libertà. Ma, in entrambi i casi, stanno andando sul cloud.

E Kubernetes è qualcosa che toccherò anche in seguito, ma sta diventando davvero un'altra parola d'ordine proprio come Microservizi. Perché è una tecnologia molto potente che semplifica le tue operazioni di sviluppo. Ti dà anche la portabilità dell'ambiente. Quindi, qualunque cosa tu faccia una volta, funziona in ogni ambiente. Indipendentemente dal fatto che tu sia in locale o in qualsiasi cloud, hai lo stesso ambiente di distribuzione che funziona. E, anche in Kubernetes, molte delle banche con cui collaboriamo preferiscono un'offerta più neutrale per la piattaforma cloud come Tanzu Kubernetes o Red Hat OpenShift. Quindi, esaminerò questi concetti in seguito come parte dell'argomento della scalabilità di cui stiamo parlando.

Problema di scalabilità

Ok, quindi, torniamo al vero problema di cui abbiamo parlato, ovvero, c'è un problema di scalabilità che dobbiamo risolvere? Si C'è. Ma non è nel livello dell'applicazione. Non è nell'architettura dell'applicazione. È nell'archiviazione dei dati, che diventa il collo di bottiglia. E, quando dico la parola archiviazione dei dati, intendo database relazionali o database o dati legacy mainframe. NoSQL databases, non hanno lo stesso tipo di collo di bottiglia e vengono utilizzati sempre di più. Ma, sfortunatamente, non possono essere la risposta a questo intero problema di scalabilità.

I colli di bottiglia della scalabilità

Se vedi questa immagine, vedrai che il motivo per cui i database relazionali e il mainframe legacy sono un collo di bottiglia è perché, a differenza del livello dell'applicazione, dove puoi aggiungere più server. Diciamo che hai le app Web qui distribuite in un ambiente con bilanciamento del carico multi-server, hai anche servizi Web e microservizi allo stesso modo.

Ancora una volta, non sto parlando dei loro ambienti in questo momento, ma ti sto solo dando una suddivisione logica dell'essere più server. Pertanto, la possibilità di aggiungere più server significa che il livello dell'applicazione non diventa mai un collo di bottiglia. Ma, man mano che aumenti le dimensioni di quel livello, l'archiviazione dei dati diventa sempre più un collo di bottiglia. E, anche se NoSQL non diventa un collo di bottiglia, il motivo per cui non è una risposta a tutti i tuoi problemi è perché, NoSQL richiede di spostare i tuoi dati dal relazionale e lontano dal mainframe. Il che, in un mondo ideale, non dovrebbe essere un grosso problema, ma è un grosso problema. La maggior parte delle aziende non può abbandonare completamente la relazione. Non possono allontanarsi completamente dal mainframe. Possono usare NoSQL poiché è possibile inserire una combinazione di alcuni dati NoSQL database ma molti dati devono continuare a essere nei database relazionali e nel mainframe. E, fintanto che ciò è vero, ciò significa che qualunque soluzione di scalabilità dobbiamo trovare non può essere un NoSQL database. Deve essere qualcos'altro oltre a NoSQL database. Deve funzionare con database relazionali e con il database mainframe legacy.

Colli di bottiglia dei microservizi

I microservizi, come ti ho mostrato l'architettura, anche se non ti danno una scalabilità incorporata. Anche loro hanno gli stessi colli di bottiglia delle prestazioni dei servizi Web o delle applicazioni Web. A meno che non stiano usando a NoSQL database, che ovviamente non avranno, ma anche loro devono parlare con il mainframe per i dati legacy e molti di loro continueranno a parlare con i database relazionali. E hanno un ulteriore potenziale collo di bottiglia che è il bus di eventi che è lì per comunicare tra loro.

Se si dispone di un ambiente di transazione molto elevato, anche il bus di eventi può essere un collo di bottiglia. Se non hai la soluzione giusta per il bus per eventi.

Soluzione di scalabilità

Quindi, fortunatamente c'è una soluzione a questo ed è una cache distribuita in memoria. E, andrò nei motivi per cui lo è? Ma, lasciatemi, fare solo alcune affermazioni. Il motivo per cui è una soluzione è perché è estremamente veloce. Offre una scalabilità lineare e un'elevata disponibilità. Quindi, questi sono i tre motivi per cui è una soluzione per il problema della scalabilità. Inoltre, c'è un ulteriore vantaggio che ottieni utilizzando una cache distribuita in memoria che in una grande azienda come Wells Fargo, puoi effettivamente utilizzarla come piattaforma di condivisione dei dati su più applicazioni. Ne parlerò un po' di più, ma è una sorta di vantaggio marginale o come un vantaggio collaterale dell'utilizzo di questo. Il motivo principale è la scalabilità.

Cache distribuita in memoria

Quindi, in che modo una cache distribuita in memoria fornisce questa risposta? Com'è quella soluzione a quel problema? Il motivo per cui è una soluzione è perché una cache distribuita in memoria, prima di tutto è in memoria, quindi è super veloce. In-memory è più veloce che pari NoSQL databaseS. E, in secondo luogo, è distribuito. Una cache di distribuzione in memoria è in realtà una raccolta di più server cache a basso costo. Inoltre, ogni server cache non è un tipo di database di un server. Questi sono più simili a server Web, da 4 a 8 core, a volte di più. Da 16 a 32 giga di RAM. Ottieni quanti ne desideri per ogni applicazione e creala come un'infrastruttura super veloce e altamente scalabile per l'applicazione. Una volta che hai il livello delle applicazioni che vedi qui con le app Web, i servizi Web e i microservizi e i database, siano essi relazionali, legacy o NoSQL. Anche NoSQL, come ho detto, non è veloce come una cache distribuita in memoria.

Quindi, cosa fa la cache di distribuzione in memoria? Crea un cluster di questi server cache e quel cluster raggruppa insieme la memoria, la CPU e persino la capacità della scheda di rete di tutti questi server cache. Proprio come il livello dell'applicazione e, proprio come il NoSQL database, anche se ancora più facilmente del NoSQL database, continui ad aggiungere più server cache man mano che la tua capacità di transazione aumenta. Quindi, ora improvvisamente hai un ridondante e, per di più, poiché è in memoria, deve fornire la replica dei dati in modo intelligente e lo esaminerò tra un po' per assicurarmi che se c'è un server cache va giù, non perdi alcun dato. Perché altrimenti, qualsiasi archivio in memoria non ha valore. Perché, se perdi gigabyte e gigabyte di dati solo perché un server si interrompe, non è davvero una soluzione molto interessante. Quindi, una cache distribuita in memoria non solo distribuisce i dati, ma li replica anche in modo intelligente senza compromettere le prestazioni e scalabilità.

Quindi, avendo una cache distribuita in memoria come parte della tua infrastruttura, improvvisamente ora hai la possibilità di rimuovere quel collo di bottiglia, l'80% delle letture dei tuoi dati andrà alla cache distribuita. Il 20% va ai database effettivi perché i database sono ancora l'origine dei dati principali. Pertanto, tutti gli aggiornamenti apportati a tali dati devono essere apportati al database relazionale del mainframe legacy o del NoSQL. Ma, a volte anche più dell'80%, il 90% del traffico di lettura o scrittura può essere limitato alla cache distribuita. E, improvvisamente, le tue applicazioni non sentono più alcun collo di bottiglia.

Quindi, questo è un po' come un modello essenziale dell'architettura dell'applicazione ora, in cui devi avere una cache distribuita in memoria, se vuoi che le tue applicazioni siano in grado di scalare.

Scalabilità della cache distribuita

Questi sono alcuni numeri di benchmark di scalabilità di NCache, dove puoi vedere che con soli 4-5 nodi puoi eseguire 2 milioni di operazioni al secondo. E, poiché è una scala lineare, quindi, se vuoi arrivare a 4 milioni, aggiungi altri 5 nodi. E, come sai, 2 milioni di operazioni al secondo sono un carico di transazioni piuttosto elevato, che la maggior parte delle tue applicazioni, se riescono a rimanere in quel carico, il 90% delle tue applicazioni sarà felice all'interno di quel tipo di carico. Forse alcuni non lo faranno e hanno bisogno di più. E, quando ne hanno bisogno di più, aggiungi semplicemente più server.

Usi comuni della cache distribuita

Quindi, spero che ormai ti ho convinto che una cache distribuita in memoria è un'ottima idea per quanto riguarda l'architettura di un'applicazione. Quindi, la prossima o la prima domanda che viene in mente dopo è, ok, come posso trarne vantaggio, come sviluppatore di applicazioni? Perché si tratta di applicazioni. Come posso utilizzare una cache distribuita per trarne vantaggio?

• Memorizzazione nella cache dei dati dell'app

  Quindi, ci sono tre modi comuni per utilizzare una cache distribuita. Il numero uno lo è Memorizzazione nella cache dei dati dell'app. Questo è il modo più comune di cui stavo parlando. Ovvero, qualunque dato tu stia leggendo dal database, lo tieni nella cache, quindi la prossima volta lo leggi dalla cache, molto semplice. E, qualunque cosa tu aggiorni, aggiorni sia la cache che il database.

  Ora, una cosa che devi capire immediatamente, che per la memorizzazione nella cache dei dati dell'applicazione esiste un problema unico, ovvero che ora i dati esistono in due posti, uno è il database principale, che potrebbe essere il tuo relazionale, NoSQL o mainframe legacy e uno è la cache. Quindi, la prima cosa che può andare storta è che la cache potrebbe diventare obsoleta. Quindi, hai aggiornato i dati, hai un'applicazione che non sta parlando con la cache, va e aggiorna i dati nel database e, improvvisamente, la cache ha dati obsoleti e i dati non aggiornati sono davvero pessimi. Sono sicuro, voi ragazzi lo sapete, più di chiunque altro una banca saprebbe che i dati stantii sono pessimi. Alcuni dati obsoleti vanno bene, ma molti dati obsoleti sono pessimi. Quindi, questo è il motivo per cui la maggior parte delle persone quando pensano alla memorizzazione nella cache, la reazione istintiva è che va bene, memorizzerò nella cache solo i dati di sola lettura, che non cambiano mai o, almeno durante la vita della mia applicazione o qualunque cosa sia , tra molto tempo non cambierà. Bene, se è solo il 10% circa, il 15% dei tuoi dati totali. Se hai intenzione di memorizzare nella cache solo il 10%, il 15%, non stai davvero sfruttando una cache distribuita. Devi essere in grado di memorizzare nella cache i dati che cambiano forse ogni 5 secondi. O, anche prima. Perché anche per quei 5-10 Secondi potresti leggerlo 10 volte. E, quando lo moltiplichi per milioni di transazioni che la tua applicazione elabora ogni giorno, risparmi tanti viaggi nel database e come guadagnerai la scalabilità.

  Quindi, qualsiasi cache distribuita che non risolve questo problema salta questa sfida, che la cache non dovrebbe diventare obsoleta, dovrebbe essere sempre fresca, ti costringerà a non usarla completamente. Quindi, questa è la prima cosa da tenere a mente.

• Memorizzazione nella cache specifica per app Web

  Il secondo caso d'uso è l'applicazione web. E l'uso più comune per l'applicazione web è sessioni. Sia che tu abbia Java, ASP.NET, ASP.NET Core o Node.js, tutti vogliono salvare le proprie sessioni in un archivio veloce e scalabile. E una cache distribuita è un archivio molto migliore di qualsiasi altra cosa disponibile. Che si tratti di Java o .NET o no Node.js. E ci sono altre cose come, c'è la pagina cache di output. Ci sono anche applicazioni web live. In caso di .NET viene chiamato Segnale R, che puoi utilizzare una cache distribuita come piattaforma per condividere gli eventi.

  Tuttavia, un'applicazione Web, quando è diversa dalla memorizzazione nella cache dei dati dell'app, quando l'applicazione Web memorizza i propri dati nella cache distribuita, ha un diverso tipo di problema da affrontare. Cioè, che ora, non esiste un database che abbia una copia di quei dati. La cache è il negozio principale. E una cache che è un archivio principale significa che se il server della cache si interrompe, perdi quei dati. Il che non è accettabile, non vuoi perdere una sessione utente solo perché un server cache o un server web si è interrotto. Se si desidera avere un'elevata disponibilità, è necessario che la cache abbia le caratteristiche della capacità di replicare i dati in modo intelligente su più server. Quindi, se un server cache si interrompe, non perdi quei dati. Quindi, questa è la parte importante. La memorizzazione nella cache dei dati delle app presenta una sfida diversa. La memorizzazione nella cache specifica dell'applicazione Web presenta una sfida diversa.

• Messaggistica Pub/Sub, CQ ed Eventi

  E il terzo caso d'uso è che puoi usare e, questo è qualcosa che molte persone non sanno affatto, ovvero che puoi usare una cache distribuita come Messaggistica Pub/Sub piattaforma ed Eventi. Abbiamo parlato e ti mostrerò che anche i microservizi devono fare Pub/Sub. Pertanto, se utilizzano la cache distribuita come piattaforma di messaggistica Pub/Sub oltre a utilizzarla per la memorizzazione nella cache dei dati dell'applicazione, la messaggistica Pub/Sub non sarà un collo di bottiglia per loro.

  Ci sono molti altri prodotti di messaggistica che hanno molte funzioni di messaggistica. Inoltre, una cache distribuita non corrisponde a tutte queste funzionalità, ma ciò che fa la cache distribuita è che crea una piattaforma di messaggistica in memoria molto veloce per quei messaggi che devono solo essere condivisi all'interno di questo ambiente di microservizi o applicazioni web. Quindi, è un ambiente molto più semplice in cui non è necessario mantenere quei messaggi in giro per ore. Devono solo essere condivisi entro pochi millisecondi forse. Ma c'è così tanta attività di transazione che, senza un'architettura realmente distribuita in memoria, la piattaforma di messaggistica stessa diventa un collo di bottiglia. Quindi, oltre al fatto che l'archiviazione dei dati è un collo di bottiglia, anche la tua piattaforma di messaggistica è un collo di bottiglia. Quindi, tienilo a mente. E, ancora una volta, la piattaforma di messaggistica ha lo stesso problema di una memorizzazione nella cache specifica di un'applicazione Web, ovvero che, di solito, qualunque cosa venga conservata come messaggio, non ha una copia di backup nel database. Bene, potrebbe essere una versione trasformata di alcuni dati che esistono già nel database e potresti essere in grado di ricrearlo ma non lo desideri. Quindi, non vuoi perdere quei dati, non vuoi perdere quei messaggi. Quindi, ecco perché una buona cache distribuita non solo deve essere veloce e scalabile, ma deve anche fornire quella replica intelligente non solo per la memorizzazione nella cache specifica per il Web, ma anche per la messaggistica Pub/Sub.

Kubernetes e cache distribuita

Ecco come abbiamo un ambiente Kubernetes che esegue sia applicazioni Web che microservizi e utilizza una cache distribuita. Quindi, questa area verde è un ammasso di Kubernetes. E Kubernetes ha questo concetto di cluster. All'interno di ogni cluster sono presenti più distribuzioni. Quindi, ognuno di questi tre rettangoli di scatole è una distribuzione. Quindi, c'è una distribuzione di app Web, ci sono due distribuzioni di microservizi e c'è una distribuzione di cache distribuita e c'è un gateway API per i microservizi.

Non entrerò nei dettagli di come funziona Kubernetes, ma fondamentalmente, in un ambiente come questo, i microservizi utilizzano la cache distribuita sia per la memorizzazione nella cache dei dati dell'applicazione che per la messaggistica Pub/Sub. Considerando che l'applicazione Web utilizza la cache distribuita per la memorizzazione nella cache dei dati dell'applicazione e le sessioni Web.

La maggior parte delle applicazioni web non ha un Messaggistica Pub/Sub perché Pub/Sub Messaging di solito richiede una sorta di processo server stabile per comunicare tra loro. Ma comunque, alcuni di loro potrebbero ma la maggior parte no. Tuttavia, la stessa infrastruttura di memorizzazione nella cache che hai in atto per la memorizzazione nella cache dei dati dell'applicazione può essere utilizzata per sessioni Web e può essere utilizzata anche per Pub/Sub Messaging e queste sono, in questo caso, come puoi vedere, queste sono istanze Docker come Pod . Queste potrebbero essere scatole Windows o Linux, sai, dipende dalle tue preferenze su quale strada vuoi andare. La maggior parte delle banche in questi giorni sta spostando tutto su Linux e persino .NET Core perché supporta Linux. Ora puoi avere sia applicazioni .NET che Java e ovviamente Node.js su Linux.

Quindi, questo è l'aspetto di un ambiente Kubernetes sia per i servizi che per le applicazioni Web e anche per l'hosting di una cache distribuita. Una cosa che volevo sottolineare qui è che una cache distribuita per vivere in Kubernetes deve essere compatibile con Kubernetes. Deve aver implementato quello che chiamano Operatore Kubernetes. NCache ce l'ha. Quindi, qualunque sia la cache distribuita che guardi, assicurati che sia compatibile con Kubernetes.

Panoramica della memorizzazione nella cache dei dati dell'app (API)

Quindi, questa è la mia unica diapositiva di codifica. Non ho intenzione di approfondire la programmazione di questo. L'idea generale di questo è che, ok, Application Data Caching è il caso d'uso principale per la cache distribuita, che dovrebbe utilizzare ogni applicazione che stai sviluppando. Che si tratti di un'applicazione Web, di servizi Web o di microservizi. E puoi vedere che questa è un'API molto semplice che ha una cache distribuita.

• Connessione cache

  ICache cache = CacheManager.GetCache(“myDistributedCache”);
  cache.Dispose();

• Recuperando i dati

  Employee employee = cache.Get<Employee>("Employee:1000"); 
  bool isPresent = cache.Contains("Employee:1000");

• Scrittura di dati

  cache.Add("Employee:1000", employee);
  cache.AddAsync("Employee:1000", employee);
  
  cache.Insert("Employee:1000", employee);
  cache.InsertAsync("Employee:1000", employee);
  
  Employee employee = (Employee) cache.Remove("Employee:1000");
  cache.RemoveAsync("Employee:1000");

Hai un handle di cache, fai cache.Get, cache.Contains. C'è una chiave che di solito è una stringa e, si ottiene un valore e un valore può essere sia un oggetto, potrebbe essere un oggetto .NET, potrebbe essere un oggetto Java, potrebbe essere un documento JSON. Node.js ovviamente funziona in JSON. Ma potresti anche fare in modo che le applicazioni .NET e Java memorizzino i loro oggetti o dati come JSON. E ciò in realtà ti consente di usarlo anche come piattaforma di condivisione dei dati perché hai un'applicazione Java che memorizza, diciamo, un oggetto cliente che era un oggetto cliente Java. Quando viene archiviato nella cache distribuita, diciamo, come NCache viene trasformato in un documento JSON e quindi quando un'applicazione Node.js o .NET o .NET Core l'applicazione vuole recuperarlo, lo ottengono ... Diciamo, .NET Core l'applicazione lo otterrà come oggetto cliente .NET o documento JSON e Node.js probabilmente otterrebbe comunque solo un documento JSON. Quindi, la semplicità è lì, Ottieni, Aggiungi, Inserisci, Rimuovi nel modo più semplice possibile. Quindi, la curva di apprendimento è molto rapida nell'utilizzo di una cache distribuita.

Funzionalità di memorizzazione nella cache dei dati dell'app

Esaminerò rapidamente alcune delle aree chiave in App Data Caching perché, se utilizzerai la cache distribuita, il caso d'uso più grande è App Data Caching. E di cosa devi essere consapevole? Il numero uno, come avevo detto, ci sono due copie dei dati una nel database e una nella cache, quindi come mantieni la cache fresca?

• Scadenze (assolute e scorrevoli)

  Il numero uno è una caratteristica chiamata Scadenza che quasi ogni cache distribuita ha come funzionalità e, di solito è il Scadenza assoluta. Alcuni lo chiamano TTL o o tempo per vivere le scadenze. Viene chiamata l'altra scadenza Scadenza scorrevole che non è per App Data Caching, è più per il tipo di sessione di una situazione in cui si desidera far scadere l'oggetto se nessuno lo usa per un certo periodo di tempo. Ma, alla scadenza assoluta, stai dicendo alla cache che so che questi dati che sto memorizzando nella cache non cambieranno per i prossimi cinque minuti o per le prossime cinque ore o 24 ore. Qualunque sia la natura dei dati, puoi specificarla. E, alla fine di quel tempo, la cache scadrà automaticamente. Quindi, l'applicazione può semplicemente aggiungerlo e andare avanti. L'applicazione non deve preoccuparsi di tenere traccia di tutti quei dati. Quindi, questo è il minimo che ogni cache dovrebbe avere e la maggior parte di esse ce l'ha. Ma il problema o la limitazione delle scadenze è che stai solo facendo un'ipotesi plausibile. In alcuni casi va bene perché i dati non cambiano così frequentemente ma, come accennato in precedenza, il vero vantaggio è nella memorizzazione nella cache dei dati transazionali. Quindi, nei dati transazionali vuoi essere più accurato.

• Sincronizza la cache con il database

  Un'altra caratteristica che dovrebbe avere una cache distribuita è che dovrebbe essere a conoscenza del tuo database in una certa misura, in modo che possa sincronizzarsi con i dati che ha memorizzato nella cache, se quei dati, i dati corrispondenti nel database cambiano, allora il cache dovrebbe rimuovere automaticamente quell'elemento dalla cache, in modo che la prossima volta che la tua applicazione lo desidera, non lo trovi nella cache e sarà forzato a recuperarlo dal database o la cache dovrebbe ricaricare una copia di esso. E la ricarica è possibile solo attraverso un'altra funzione di cui parlerò, si chiama read-through e write-through. Ma, se riesci a sincronizzare la cache con il database.

  Quindi, ci sono due modi per sincronizzare. Uno è basato sugli eventi. Quindi, la maggior parte dei database in questi giorni ora ha gli eventi di modifica dei dati. Ce l'ha SQL Server, ce l'ha Oracle, MongoDB, Cosmos DB ce l'hanno tutti. Cosmos DB lo chiama Penso che cambia feed, MongoDB lo chiama change stream e SQL Server lo chiama SQL Dependency e Oracle, penso che lo chiami Notifiche del database o qualcosa del genere.

  Quindi, se la tua cache distribuita sta sfruttando queste capacità nel database, in modo che possa creare una sorta di relazione tra i suoi elementi memorizzati nella cache e i set di record del database. Quindi, quando quei dati cambiano, il database notifica alla cache distribuita che ok questi dati sono cambiati, prenditi cura della tua copia di essi. Quindi, la tua cache può rimuoverla o ricaricare dal database e se il database non ha eventi come funzionalità, puoi utilizzare il polling come un altro meccanismo.

• Gestire i dati relazionali

  La terza cosa che vuoi fare è se stai memorizzando nella cache i dati relazionali, ci sono alcuni problemi di integrità dei dati relativi alle relazioni, uno-a-molti, uno-a-uno. Quindi, se puoi dire alla cache che questo articolo, ho questo oggetto cliente e ho questo oggetto ordine, sono correlati. Quindi, se l'applicazione rimuove l'oggetto cliente, la cache rimuove automaticamente tutti gli ordini. Quindi, in questo modo non ci sono, sai, quelli che chiami riferimenti penzolanti nella cache. È roba del genere, se puoi farlo, la tua cache sarà di nuovo sempre fresca.

• Query SQL

  Quindi, con queste funzionalità, se la tua cache ha almeno le prime due funzionalità, avrai la sicurezza di inserire tutti i tipi di dati nella cache. E, una volta acquisita tale sicurezza, inizierai a mettere molti dati nella cache. E, una volta inseriti molti dati nella cache, si presenta un altro problema, che ora è solo trovare i dati basati sulle chiavi non è sufficiente. Quindi, vuoi essere in grado di trovare i dati proprio come puoi trovarli nel database, che sono le query SQL. Per .NET, .NET Core c'è anche un LINQ. Quindi, se puoi cercare i dati in base agli attributi dell'oggetto. Puoi dire qualcosa come dammi tutti gli oggetti dei clienti, dove la città è San Francisco. Quindi si comporta più come un database. Ci sono anche dati di riferimento che puoi cercare. Ci sono molti dati di ricerca che puoi cercare. Quindi, se puoi cercare i dati, ora la cache diventa più amichevole. Ti senti più sicuro di memorizzare nella cache sempre più dati perché puoi trovarli. Perché, se non puoi eseguire query SQL, la tua applicazione diventa improvvisamente molto complicata. Devi tenere traccia di ogni chiave che hai memorizzato.

• Gruppi, Tag, Tag con nome

  L'altro aspetto è di nuovo nella stessa relazione: vuoi essere in grado di raggruppare i dati correlati in modo da poterli recuperare tutti in una volta. Quindi, diverse cache distribuite forniscono questo concetto di gruppi, tag e tag dei nomi che puoi quindi ottenere tutto ciò che corrisponde a questo tag. Oppure eliminalo tutto dalla cache o recuperalo dalla cache. Quindi, grazie alla capacità di trovare rapidamente i dati, oltre alle chiavi diventa molto importante una volta che inizi a memorizzare nella cache sempre più dati.

• Read-through e Write-through

  Questa è la funzione di cui stavo parlando, la funzione di lettura e scrittura. L'importanza di questa caratteristica è che, diciamo... Lasciatemi prima spiegare di cosa si tratta. Quindi, quando si dispone di una cache distribuita, se non si dispone di questa funzione, l'applicazione legge tutti i dati, li inserisce nella cache e aggiorna anche il database con esso. Ma, poiché rendi la cache sempre più rilevante per più applicazioni, ora la cache dovrebbe ... se la cache può diventare più autosufficiente, può prendersi cura di se stessa, quindi questo semplifica le applicazioni. Quindi hai più applicazioni che stanno semplicemente trattando quella cache come una rappresentazione in memoria di qualunque fossero le origini dati master. Sai, come potrebbero, come ho detto mainframe, relazionale o NoSQL. Quindi, vanno a questa cache distribuita in memoria come archivio di valori chiave, il che è molto semplice molto semplice, è tutto in memoria, quindi è super veloce e la cache distribuita è in grado di leggere i dati, se non è disponibile per la lettura -through è qualcosa che è il tuo codice che viene registrato nella cache distribuita. Quindi, la cache distribuita chiama il tuo codice, va al database e legge l'elemento corrispondente. Quindi, diciamo che fai una cache. Prendi una determinata chiave e quell'elemento non era nella cache, la cache chiamerà il read-through per andare a prenderlo dal database.

• Scrivi dietro

  Allo stesso modo puoi anche usare la cache per aggiornare i dati non solo nella cache ma anche per aggiornare la cache nel database. E il write-behind è una versione più avanzata di esso in cui l'aggiornamento della cache avviene in modo sincrono ma l'aggiornamento del database avviene in modo asincrono.

• Caricatore di cache/Aggiornamento

  Il caricatore e l'aggiornamento della cache sono ancora un altro modo in cui puoi riscaldare la cache. Quando avvii la cache, la popola con tutti i dati che sai che avrai sempre. Quindi, in questo modo non devi chiamare il read-through ogni volta. Quindi, una volta caricata quella cache con, diciamo, milioni di oggetti, l'aggiornamento della cache è un'altra funzionalità che può aggiornare periodicamente determinati sottoinsiemi di tali dati, in base alle regole aziendali specificate. Quelli potrebbero essere basati sugli eventi, potrebbero essere basati sul tempo, qualunque cosa dica la tua logica aziendale. Puoi dire, va bene, vai a recuperare una copia più recente dei dati dall'origine dati master.

  Ora, in molte di queste situazioni, avrai questo scenario in cui se i dati non sono molto sensibili al business, va bene averne una copia non aggiornata, se non è troppo tardi o troppo tardi. Ma avendo tutte e tre le funzionalità, read-through, write-through e caricatore/aggiornamento della cache, improvvisamente ora hai una cache che è molto intelligente. Può entrare e caricarsi da più origini dati e rendersi disponibile non solo all'interno dell'applicazione, come ho già detto, ma in più applicazioni.

Piattaforma di condivisione dei dati

Quindi, ci sono più applicazioni, come ho detto prima, è il vantaggio collaterale. Il vantaggio marginale dell'utilizzo di una cache distribuita in memoria. Che cosa vuol dire? Ciò significa che ora la cache distribuita diventa un'infrastruttura comune tra più applicazioni. Quindi, quando le applicazioni devono condividere i dati tra loro, invece di chiamarsi o accedere ai loro database, mettili in un key value store molto semplice da capire, che è in memoria, super veloce e altamente scalabile. E, poiché tutte le funzionalità che ho menzionato come read-through, write-through, caricatore della cache, aggiornamento, tutte le altre ricerche SQL, tutte rendono questo un database simile ma non è un'origine dati master.

Quindi, nella piattaforma di condivisione dei dati, la cache non è il master. È solo una copia di altri master ma è inteso solo per scopi di condivisione. E so che molte aziende in questi giorni si stanno concentrando molto sul consolidamento di più applicazioni per avere una vista comune, una funzionalità comune.

So che molte delle banche con cui abbiamo parlato vogliono che il percorso del cliente sia compreso in più applicazioni. Quindi, in che modo queste applicazioni parlano tra loro? Qual è il punto centrale in cui possono condividere i dati tra loro? Deve essere qualcosa in memoria. Se non è in memoria, sarà l'ennesimo collo di bottiglia. E il bello di in-memory è che puoi sempre riavviarlo e non c'è perdita di dati. Perché, ricarica semplicemente i dati dalle origini dati master. Ma si renderà disponibile. Inoltre, poiché è ridondante, si replica su più server. Sai, la probabilità di perdere completamente una cache distribuita è molto molto bassa. E esaminerò alcune delle altre funzionalità in cui puoi effettivamente avere la stessa cache live in più regioni, più data center, uno a San Francisco, uno a New York e così via. E, in questo modo, se avete qualche situazione di ripristino di emergenza, so di aver visto nelle notizie che alcuni anni fa voi ragazzi avete dovuto affrontare un arresto piuttosto grave. Bene, situazioni del genere richiedono un vero ripristino di emergenza. Quindi, tutto deve essere replicato su più regioni. E, quando usi una cache distribuita per scopi di condivisione dei dati, anche quella cache distribuita dovrebbe essere replicata per più motivi, andrò a quello. Ma questo è un vantaggio marginale molto molto importante per le grandi aziende, in particolare come Wells Fargo, per riunire più applicazioni. E, ancora una volta, puoi averne più di questi perché, sei una grande azienda, potresti non avere un master per l'intera azienda o potresti. Oppure potresti avere più di questi in alcune parti della tua azienda per condividere i dati.

Architettura della cache distribuita

Ora che ho parlato di tutti i modi in cui puoi utilizzare una cache distribuita, cosa dovresti aspettarti da una buona cache distribuita in termini di architettura?

Alta disponibilità

Il numero uno è l'alta disponibilità. Poiché una cache distribuita viene utilizzata in ambienti di produzione live, se non ti offre una disponibilità veramente elevata, devi essere molto scettico al riguardo e l'alta disponibilità significa che il cluster che la cache distribuita sta creando deve avere un peer- architettura to-peer. Se non ha un'architettura peer-to-peer, se ha un master slave, una volta che il master muore, sai, gli slave diventano di sola lettura o inutilizzabili. Quindi, la possibilità di aggiungere o rimuovere server, qualsiasi server in fase di esecuzione è molto critica.

Scalabilità lineare

Il numero due è la scalabilità lineare e ciò deriva dal partizionamento dei dati. Vado solo alla diapositiva successiva e ne parlerò. Quindi il partizionamento avviene in due modi, uno solo partizionamento senza replica e, il secondo è partizionamento con replica. Quindi, una cache distribuita, come ho detto, ti fornisce ridondanza e una replica intelligente.

Cos'è quella replica intelligente? La replica intelligente significa che ogni dato è... i dati sono partizionati e ogni partizione viene salvata su un server diverso e tutto ciò è dinamico. Quindi, è auto-guarigione. Quindi, quando si aggiunge un nuovo server, viene creata una nuova partizione e vengono create nuove repliche e i dati vengono automaticamente bilanciati.

Quindi, ecco un esempio. Supponiamo che tu abbia iniziato con un cluster di cache a due server e desideri aggiungerne un terzo perché il carico delle transazioni sta crescendo. Non appena aggiungi un terzo server, crea automaticamente una terza partizione. Ora hai tre partizioni. Quindi, anche le repliche devono riadattarlo. Tutto ciò avviene in modo dinamico o automatico.

E, allo stesso modo, diciamo, lo vuoi o un server si è interrotto per qualche motivo. Diciamo che il server 3 è inattivo, la partizione 3 è inattiva. Non appena la partizione 3 è inattiva, la replica 3 diventa attiva. E ora hai un'anomalia in cui hai due server e tre partizioni. Quindi, ora deve fondersi automaticamente in due partizioni e due repliche. Tutto ciò dovrebbe essere fatto automaticamente senza alcun intervento umano. Se richiede l'intervento umano, allora non è veramente ad alta disponibilità. NoSQL databases, poiché sono database che devono gestire l'archiviazione persistente di molti dati, non forniscono questo ripartizionamento dinamico. E va bene per a NoSQL database. Ma non va bene per un negozio in memoria. L'archivio in memoria deve essere molto più veloce, molto più agile nello spostarsi su e giù in termini di numero di server.

Replica WAN

Ecco quell'elevata disponibilità in cui hai più siti. Quindi, se hai una cache distribuita nel sito 1, diciamo a San Francisco e vuoi avere il sito 2, puoi avere un attivo-passivo o un attivo-attivo. Prima vedevamo di più attivo-passivo, ora quasi tutti stanno passando ad attivo-attivo a causa del cloud. È molto più facile far funzionare l'infrastruttura. Quindi, le persone hanno solo siti attivi-attivi.

E nella sfida attivo-attivo è più perché entrambe le parti potrebbero aggiornare gli stessi dati, quindi ci deve essere una capacità di risoluzione dei conflitti integrata nella cache distribuita che NCache ma, devi essere consapevole di questo che, per ottenere una vera disponibilità elevata, devi andare oltre un data center e devi entrare in più data center.

In molte situazioni è possibile che due data center non siano sufficienti, quindi, se si dispone di tre o più data center, è comunque necessario disporre della stessa capacità di replica attivo-attivo. Quindi, se un data center si interrompe, gli altri due data center dovrebbero essere in grado di assumerne il carico e quindi dovresti essere in grado di ripristinare quel data center e farlo ricongiungere e gli utenti non dovrebbero vedere alcuna interruzione.

Se riesci a raggiungere questo obiettivo con una cache distribuita, il tutto in modo dinamico, senza alcun essere umano ... di nuovo, ovviamente, il backup di un data center richiede l'intervento umano. Tuttavia, non dovrebbe esserci alcun intervento umano quando un data center si interrompe, affinché l'elevata disponibilità sia veramente elevata. Se mancano anche solo cinque minuti, non è accettabile.

Questa è la fine del mio discorso. Ho cercato di mantenerlo il più veloce possibile, solo per avere un po' di tempo a disposizione. Ti darò solo alcune riflessioni riassuntive. Penso che la cosa principale che volevo guidare sia che ogni applicazione che stai sviluppando, ti consiglio vivamente di avere una cache distribuita in memoria, per quei tre casi d'uso di cui ho parlato. E, idealmente, dovresti usarlo anche per la condivisione dei dati su più applicazioni. E, in entrambi i casi, anche all'interno della stessa applicazione dovresti provare ad avere più siti per assicurarti di avere il ripristino di emergenza in questo.

E sto parlando di questo da 15 anni di esperienza. Abbiamo fatto questo. NCache è sul mercato da più di 15 anni e collaboriamo con molte banche. Siamo stati tradizionalmente un negozio .NET ma NCache ora supporta completamente .NET e Java e Node.js. Sia il codice lato client che quello lato server per .NET e Java e Node.js sono solo l'API client. Questa è la fine del mio discorso.

Grazie, Iqbal. Non posso sottolineare abbastanza che, mentre noi di Wells Fargo percorriamo il percorso di modernizzazione, quanto sia stata tempestiva e rilevante questa presentazione. Quindi grazie. Team, ti ricorderò che se hai domande, vai avanti e chiedile nella tua chat. Abbiamo una serie di domande Iqbal. Molte delle domande che il team è in giro, questa presentazione e il video saranno resi disponibili? La risposta è si. Dopo la presentazione, questo sarà messo a tua disposizione su richiesta. Ti invieremo il link. Quindi, Iqbal, ecco alcune delle domande che sono arrivate.

In che modo le cache distribuite gestiscono i dati sensibili? Ad esempio, la crittografia trasparente è una domanda.

Sì, penso di non aver avuto tempo se non per approfondire, ma anche questo è un aspetto molto importante. Un prodotto simile NCache, ad esempio, fornisce problemi di a più livelli. C'è l'Autenticazione, Autorizzazione, Sicurezza. C'è la crittografia. Quindi, più algoritmi di crittografia. Alcuni 128 bit, alcuni 256 bit di crittografia. C'è il TLS, la sicurezza dei trasporti. Quindi, la cache per una banca come Wells Fargo deve fornire sicurezza ed ecco perché lavoriamo con le banche. Questa è la caratteristica che abbiamo da molto tempo. Quindi, i dati possono essere crittografati. E ancora, tutto questo è automatico. Non è necessaria alcuna programmazione per farlo. Queste sono solo configurazioni. Tuttavia, una cache distribuita deve affrontare la sicurezza attraverso queste diverse funzionalità.

La domanda successiva è: qual è la differenza nell'avere il database come gli oggetti e la memoria della cache Oracle e avere un'altra cache di memoria davanti a Oracle? Fondamentalmente, posso ottenere lo stesso risultato assegnando più memoria a Oracle?

Penso che la parola chiave sia "distribuito". Tutto ciò che non è distribuito, puoi essere veloce ma non scalabile. Ecco perché la mia prima diapositiva è stata la definizione della parola scalabilità. Puoi passare da 1 scatola a 10 scatole a 50 scatole come distribuzione? Alcuni dei nostri clienti hanno una server farm di applicazioni di 150 o più server di applicazioni. E, sai, lavoriamo anche con... tra l'altro anche State Street Bank è un altro nostro cliente, e con questo, non c'è assolutamente modo che la memorizzazione nella cache in memoria di un singolo server di database possa gestirlo. Sì, questa è una funzionalità molto importante per rendere veloci Oracle e SQL Server e altri, ma non possono essere scalabili. La scalabilità può essere raggiunta solo attraverso la distribuzione.

Che aspetto ha e come funziona il NCache prestazioni rispetto a Redis, Coerenza e altri prodotti di mercato. E poi l'altra parte della domanda è: hai dei piani nella tua roadmap per supportare linguaggi di programmazione aggiuntivi come Scala o Python? In realtà, permettetemi di rispondere prima alla seconda domanda. Sì, supporteremo molto Scala e Python. In effetti, lo faremo quest'anno. Supportiamo Java da quasi 10 anni ormai. La maggior parte dei clienti che utilizzano NCache, se sono grandi aziende lo usano sia per Java che per .NET. Anche se, potrebbero acquistarlo da una prospettiva .NET. Quindi, questo è il primo.

La seconda domanda era, come funziona NCache le prestazioni si confrontano con Redis e altri? Voglio dire, sono tutti veloci. Non farò fare brutta figura a nessuno e penso che dovreste fare il vostro confronto, ma sono tutti veloci. Penso che l'unica cosa contro cui ti metterei in guardia è che alcuni giocatori, sai, ti danno l'impressione sbagliata di fare i benchmark. Ad esempio, i parametri di riferimento che diamo includono il viaggio di andata e ritorno completo. Quindi, se stai eseguendo una cache.Get o cache.Insert, a meno che l'operazione di inserimento non ritorni all'applicazione, l'operazione non è stata completata. Ma alcuni degli altri fornitori ti mostrerebbero effettivamente un benchmark molto più grande del nostro, ma faranno quello che chiamano fuoco e dimenticanza. Quindi, se devo solo inviarlo e non preoccuparmene, ovviamente posso fare molto di più. E, infatti, dal lato Java Hazelcast e Redis I laboratori si sono dati l'un l'altro esattamente nello stesso punto. Quindi, lascio fare a quello.

Hai lavorato con altre banche e cose del genere, altri problemi di conformità sull'utilizzo dei dati PCI sui dati sensibili nello spazio della cache. Hai riscontrato problemi di conformità normativa lì?

In realtà no. Intendo, prima di tutto, il fatto che forniamo tutte quelle diverse funzionalità di sicurezza crittografate, sia a livello di dati. Perché puoi crittografare i dati prima di memorizzarli nella cache e, anche a livello di trasporto. Abbiamo anche l'autenticazione e l'autorizzazione all'estremità del server e, questa è l'estremità del server della cache. E penso che sia sufficiente per... e per di più una cache viene eseguita all'interno di un data center protetto. Una cache non è qualcosa che è accessibile a qualsiasi entità esterna. Quindi, quando si combinano tutti questi elementi con il fatto che la cache viene eseguita all'interno, non ne abbiamo avuti e, sai, ne abbiamo avuti ... Voglio dire, ad esempio, Citi Group e Bank of America e Barclays hanno utilizzato NCache da più di un decennio e non ha avuto problemi.

Come funzionerà con i database mainframe?

Penso che un mainframe sia qualcosa che voi... Diciamo, che molto probabilmente voi ragazzi... probabilmente avete servizi web oggi e probabilmente svilupperete dei microservizi per consentire alle applicazioni di accedere al mainframe. Il mainframe è un altro caso in cui recuperare i dati dal mainframe è molto costoso. Sia in termini di velocità che, a volte, anche se il tuo mainframe è ospitato all'esterno, potresti persino dover pagare per transazione o per viaggio. Quindi, se puoi memorizzare nella cache più di quei dati all'interno del tuo livello Kubernetes o Microservices, come ho detto, e fare meno viaggi al mainframe, non solo guadagnerai prestazioni ma probabilmente potrai anche risparmiare un sacco di soldi.

In che modo vengono garantite la coerenza e la disponibilità dei dati nella cache distribuita in memoria quando i nodi vengono aggiunti e rimossi?

Quindi, almeno posso parlarne NCache che NCache assicura che quando aggiungi o rimuovi nodi, qualsiasi aggiornamento in corso, qualsiasi modifica in corso venga completata con il fatto che stiamo eseguendo il trasferimento di stato, diciamo, stiamo spostando il partizionamento e cose del genere, NCache è consapevole del fatto che deve assicurarsi che tutti quegli aggiornamenti siano applicati correttamente mentre si assicura che il nodo venga aggiunto e il trasferimento di stato, ciò che chiamiamo trasferimento di stato che è il bilanciamento dei dati per spostare i dati da una partizione all'altra che continua anche ad accadere. Così, NCache lo assicura.

Quando si distribuiscono i microservizi con i propri database, come ho visto nella foto, come possono questi fornire un'esperienza omnicanale al cliente?

Quindi, per la parte del database distribuito, penso che la giuria sia fuori su come saranno distribuiti quei database. Come saranno partizionati quei database. Perché, come ho detto nel mio intervento, almeno in teoria ogni microservizio può avere il proprio database logico, anche se fisicamente potrebbero risiedere sugli stessi server di database, perché, quando si distribuiscono le cose, non si avrà 100 server di database diversi, ciascuno per ogni microservizio. Avrai alcuni server di database consolidati. Il fatto che tu abbia la separazione probabilmente ti dà un po' più di flessibilità, proprio come NoSQL ma la giuria è ancora fuori su quanto puoi davvero farla franca con quella limitazione di un database relazionale. La mia previsione è che finirai con gli stessi server di database relazionali. Potresti avere o meno la separazione logica. Potresti avere schemi separati o potresti avere lo stesso schema, stai solo parlando con tabelle diverse ma i server di database saranno sempre gli stessi. Quindi, è lo stesso problema che stai affrontando anche nei servizi Web, che affronteranno nei microservizi. Penso che con il tempo che sta per scadere. Non posso ringraziarti abbastanza. Questo è stato molto interessante. Le domande continuano ad affluire ma chiaramente non possiamo arrivarci a tutte. Quindi, con questo, te lo restituirò.

Cosa fare dopo?

• NCache Dettagli
• Scaricare NCache
• Richiedi una Demo LIVE personalizzata