Wells Fargo SF Bay Area-Technologie

Skalierung .NET Core Apps und Microservices zu Höchstleistung

Für .NET, Java und Node.js

Von Iqbal Khan
Präsident & Technologie-Evangelist

Heutige Serveranwendungen müssen viele Transaktionen sehr schnell verarbeiten. Viele davon sind Webanwendungen, die täglich Millionen von Benutzern bedienen. Andere sind Microservices, die Millionen mobiler Apps oder intelligenter Geräte des Internets der Dinge (IoT) bedienen.

Die meisten dieser Anwendungen werden jetzt in Containern wie Kubernetes bereitgestellt, um die Bereitstellung, Skalierung und Verwaltung zu vereinfachen und zu automatisieren. Und die Wahl der Bereitstellungsumgebungen hat sich von On-Premises hin zu führenden Clouds wie AWS, Azure, Google Cloud und mehr verlagert.

Erfahren Sie, wie Sie solche Anwendungen entwickeln, die die heutigen extremen Leistungsanforderungen erfüllen, indem Sie Leistungsengpässe in Bezug auf Datenspeicherung und Datenbanken sowie die Kommunikation zwischen verschiedenen Teilen der Microservices-Anwendungen beseitigen.

Überblick

Vielen Dank, Mike, und danke, Jason, dass Sie mir die Gelegenheit gegeben haben, mit einer so wichtigen Gruppe bei Wells Fargo, der San Francisco Bay Area Technology Group, zu sprechen. Wie Mike erwähnte, arbeite ich bei Alachisoft und das Wort Alachi, das ich Mike und Jason erklärte, ist irgendwie abgeleitet vom Hindi-Wort Ellachi, was oder Elaichi, ein Gewürzname, Kardamom ist. Also haben wir das Unternehmen vor vielen Jahren nur benannt und wollten uns etwas Einzigartiges einfallen lassen, also haben wir uns das ausgedacht Alachisoft.

Unser Produkt ist eigentlich NCache. Also, ich werde nicht darüber reden NCache. Im heutigen Vortrag geht es um „Wie können Sie Ihre Webanwendungen und Microservices auf extreme Leistung skalieren?“ Wenn Sie diese Anwendungen in Java, .NET, .NET Core oder Node.js, dann sind Sie bei uns genau richtig.

Was ist Skalierbarkeit?

Lassen Sie uns also ein paar Definitionen verstehen, bevor ich zum eigentlichen Gespräch komme. Die erste lautet: Was ist Skalierbarkeit? Skalierbarkeit ist eigentlich eine hohe Anwendungsleistung, jedoch unter Spitzenlasten. Wenn Ihre Anwendung also mit nur 5 Benutzern superschnell arbeitet, ist sie nicht wirklich skalierbar, es sei denn, Sie haben die gleiche Superleistung in einer Geschwindigkeit mit 5000, 50,000 oder 500,000 Benutzern. Wenn Ihre Anwendung das kann, dann ist sie skalierbar, und natürlich wollen wir, dass viele unserer Anwendungen skalierbar sind, und ich werde darauf eingehen.

Was ist lineare Skalierbarkeit?

Die nächste Definition ist "Was ist lineare Skalierbarkeit?" Dies ist eher eine Anwendungsarchitektur und Bereitstellungsterminologie. Wenn Ihre Anwendung richtig aufgebaut ist, ist sie linear skalierbar, was bedeutet, dass Sie die Transaktionskapazität pro Sekunde erhöhen müssen, was bedeutet, wie viele Benutzer können Sie verarbeiten? Wie viele Bewerbungsanfragen können Sie bearbeiten? Wenn Sie dies erhöhen möchten, fügen Sie einfach weitere Server hinzu und jeder Server, den Sie hinzufügen, erhöht die Transaktionskapazität pro Sekunde linear.

Es gibt also keine Blockade, keinen Engpass. Offensichtlich sind die Lese- und Schreibkurven unterschiedlich, aber sie sind beide linear. Wenn Sie das können, ist Ihre Anwendung linear skalierbar und das wollen wir unbedingt.

Was ist nichtlineare Skalierbarkeit?

Das ist etwas, was wir nicht wollen, und wenn Sie Ihre Anwendung so konzipiert haben, dass es einige Engpässe gibt, so dass, wenn Sie Ihre Last auf die Anwendung erhöhen und mehr Boxen hinzufügen, etwas nachgibt und Ihre Anwendung startet zu verlangsamen, in der Tat, es stürzt sogar manchmal ab.

Wir wollen also definitiv nicht, dass unsere Anwendungen so konzipiert sind, dass sie nicht linear skalierbar sind.

Wer braucht Skalierbarkeit?

Okay, jetzt, wo wir verstanden haben, was Skalierbarkeit bedeutet, müssen wir als Nächstes verstehen, wer sie braucht? Welche Anwendungen benötigen Skalierbarkeit?

Web-Apps
Die häufigsten Anwendungen sind Webanwendungen. Diese sind für eine Bank wie Wells Fargo oder andere Banken, mit denen wir zusammenarbeiten, wie die Citi Group und die Bank of America und Barclays und die Bank of Tokyo. Dies sind kundenorientierte Anwendungen, Sie haben wellsfargo.com, das heißt für Verbraucherbanken und kleine Unternehmen, und diese Webanwendungen müssen in der Lage sein, viele Benutzer zu bewältigen, ohne langsamer zu werden. Daher ist es sehr wichtig, dass diese Anwendungen unter extremer Last superschnell arbeiten.
Webdienste / Web-API
Nummer zwei sind Webservices, Web-API-Anwendungen. Diese dienen im Allgemeinen dazu, viele mobile Anwendungen oder andere Anwendungen zu bedienen, die sie zur Ausführung bestimmter Aufgaben aufrufen. Wenn Sie also, sagen wir, Wells Fargo eine mobile Anwendung für Verbraucherbanken hat, muss diese mobile Anwendung mit einem Back-End kommunizieren, und dieses Back-End sind heute höchstwahrscheinlich Webdienste. Natürlich weiß ich das nicht, aber ich gehe davon aus, weil viele der anderen Banken, mit denen wir zusammenarbeiten, diese Situation haben, in der Webdienste diejenigen sind, die diese Anfrage für mobile Anwendungen bearbeiten. Und sie haben genau die gleiche Empfindlichkeit. Sie müssen in der Lage sein, eine Menge Last zu bewältigen, ohne langsamer zu werden.
Microservices
Microservices sind heutzutage ein sehr heißes Schlagwort, und ich werde gleich noch ein bisschen mehr darüber sprechen, aber im Wesentlichen geht es darum, dass Sie die Webservices auf eine neue, bessere Art und Weise neu gestalten, lassen Sie mich sag es jetzt einfach mal so.
Server-Apps
Der vierte Anwendungstyp ist jede andere Serveranwendung, die Sie möglicherweise haben. Dies könnte sein, dass Server-Apps Batch-Verarbeitung durchführen. Diese können auch Live-Transaktionen abwickeln, fallen aber unter eine andere Kategorie. Aber sie haben auch die gleiche Art von Transaktion pro Sekunde Durchsatzanforderung.

Wenn Sie also eine dieser vier Arten von Anwendungen entwickeln. Es gibt auch ein paar andere, sagen wir, Sie machen vielleicht Live-Machine Learning und KI, aber ich werde in diesem Vortrag nicht darauf eingehen, wir haben nicht genug Zeit. Aber sagen wir mal, wenn Sie diese vier Anwendungen haben, müssen sie definitiv skalierbar sein. Und dies ist das Gespräch, das über sie gehen wird. Technisch gesehen werden die Webanwendungen im Allgemeinen in Java oder ASP.NET, ASP entwickelt.NET Core, die die neue Version von ASP.NET und Node.js sind, und alle anderen drei Typen sind entweder Java oder .NET/.NET Core, Microservices entweder in Java oder .NET Core weil es die neue Technologie ist.

Einführung in Microservices

Für diejenigen unter Ihnen, die nicht wissen, wie Microservices aussehen, wollte ich Ihnen nur einen kurzen architektonischen Überblick darüber geben. Und für diejenigen, die es tun, ertrage es einfach mit mir. Microservices sind also der Grund, warum sie so beliebt werden, weil sie es Ihnen ermöglichen, Ihre monolithischen Anwendungen in Byte-große Microservices zu zerlegen, und jeder Microservice ist von anderen Microservices entkoppelt. Und diese Entkopplung bedeutet, dass sie sich nicht gegenseitig anrufen. Sie haben ihre eigenen, meist logischen Datenbanken. Sie müssen keine getrennten physischen Datenbanken haben, aber zumindest logischerweise haben sie normalerweise ihre eigenen. Einige der Microservices verwenden möglicherweise a NoSQL database, MongoDB oder etwas anderes. Einige von ihnen verwenden relationale Datenbanken, SQL Server, Oracle, DB2. Einige von ihnen gehen möglicherweise zu den alten Mainframe-Daten.

Die Entkopplung erfordert also, dass sie dann über eine Art Ereignisbus miteinander sprechen, was das Rohr auf der rechten Seite ist. Und sie werden von mobilen Anwendungen, Einzelseiten-Webanwendungen oder standardmäßigen MVC-Webanwendungen in Java, .NET oder Node.js über das API-Gateway aufgerufen. Dies ist also nur ein guter Überblick darüber, was Microservices sind. Und ich werde darauf eingehen, wie selbst sie die gleichen Skalierbarkeitsprobleme haben wie andere Anwendungen, die traditionell hatten.

App-Bereitstellungsumgebungen

Eine andere Sache, auf die ich schnell eingehen wollte, weil ich den Kontext um das herum setzen wollte, worüber ich sprechen werde, sind die verschiedenen Arten von Bereitstellungsumgebungen, mit denen wir uns im Laufe der Jahre auseinandersetzen mussten. Ich mache das jetzt seit mehr als 15 Jahren und die längste Zeit war alles vor Ort, Rechenzentren mit voller Kontrolle. Selbst jetzt haben viele der Banken, mit denen wir zusammenarbeiten, immer noch ihre eigenen Rechenzentren. Aber fast jeder bewegt sich in die Cloud oder plant zumindest, in die Cloud zu wechseln. Einige kleine und mittelständische Unternehmen wechseln in die Public Cloud. Viele größere Unternehmen, insbesondere Finanzdienstleister und Banken, bevorzugen im Allgemeinen eine private Cloud-Bereitstellung. Tatsächlich bevorzugen einige der Banken, mit denen wir zusammenarbeiten, eine private Cloud entweder auf einem Framework vom Typ Pivotal Cloud Foundry oder Red Hat Open Stack, das ihnen die vollständige Kontrolle über die private Cloud-Umgebung gibt, egal wo Private Cloud existiert. Ob es in einer öffentlichen Cloud als gemieteter Raum vorhanden ist oder sich auf ihrem Rechenzentrum befindet, das sie gerade haben, oder es ist etwas anderes, es gibt ihnen Freiheit. Aber so oder so gehen sie in die Cloud.

Und Kubernetes ist etwas, auf das ich später auch eingehen werde, aber es wird wirklich zu einem weiteren Schlagwort, genau wie Microservices. Denn es ist eine sehr leistungsfähige Technologie, die Ihre Dev Ops vereinfacht. Es bietet Ihnen auch Umgebungsübertragbarkeit. Was Sie also einmal tun, funktioniert in jeder Umgebung. Unabhängig davon, ob Sie sich vor Ort oder in einer der Clouds befinden, Sie haben dieselbe Bereitstellungsumgebung, die funktioniert. Und auch bei Kubernetes bevorzugen viele der Banken, mit denen wir zusammenarbeiten, eher cloudplattformneutrale Angebote wie Tanzu Kubernetes oder Red Hat OpenShift. Ich werde diese Konzepte später als Teil des Themas Skalierbarkeit, über das wir sprechen, noch einmal durchgehen.

Skalierbarkeitsproblem

Okay, kommen wir also auf das eigentliche Problem zurück, über das wir gesprochen haben: Gibt es ein Skalierbarkeitsproblem, das wir lösen müssen? Ja da ist. Aber es ist nicht in der Anwendungsebene. Es ist nicht in der Anwendungsarchitektur. Es liegt in der Datenspeicherung, die zum Flaschenhals wird. Und wenn ich das Wort Datenspeicherung sage, meine ich relationale Datenbanken oder Mainframe-Legacy-Datenbanken oder -Daten. NoSQL databases, sie haben nicht die gleiche Art von Engpass und werden immer häufiger verwendet. Aber leider können sie nicht die Antwort auf dieses ganze Skalierbarkeitsproblem sein.

Die Skalierbarkeitsengpässe

Wenn Sie dieses Bild sehen, werden Sie sehen, dass der Grund, warum relationale Datenbanken und Legacy-Mainframes ein Engpass sind, darin besteht, dass Sie im Gegensatz zur Anwendungsebene mehr Server hinzufügen können. Nehmen wir an, Sie haben die Web-Apps hier, die in einer Lastenausgleichsumgebung mit mehreren Servern bereitgestellt werden, Sie haben auch Webdienste und Microservices auf die gleiche Weise.

Auch hier spreche ich zu diesem Zeitpunkt nicht über ihre Umgebungen, sondern gebe Ihnen nur eine logische Aufschlüsselung der Tatsache, dass es sich um mehrere Server handelt. Durch die Möglichkeit, weitere Server hinzuzufügen, wird die Anwendungsebene also nie zu einem Engpass. Aber wenn Sie diese Ebene vergrößern, wird die Datenspeicherung immer mehr zu einem Engpass. Und obwohl NoSQL kein Engpass wird, der Grund dafür ist, dass es keine Antwort auf alle Ihre Probleme ist, weil, NoSQL erfordert, dass Sie Ihre Daten weg von relational und weg von Mainframe verschieben. Was in einer idealen Welt keine große Sache sein sollte, aber es ist eine große Sache. Die meisten Unternehmen können sich nicht vollständig vom Beziehungsgeschäft entfernen. Sie können sich nicht vollständig vom Mainframe entfernen. Sie können verwenden NoSQL da eine Kombination einiger Daten eingegeben werden könnte NoSQL database Viele Daten müssen jedoch weiterhin in relationalen Datenbanken und auf dem Mainframe gespeichert werden. Und solange das stimmt, bedeutet das, dass die Skalierbarkeitslösung, die wir uns ausdenken müssen, keine sein kann NoSQL database. Es muss etwas anderes sein als a NoSQL database. Es muss mit relationalen Datenbanken und mit der alten Mainframe-Datenbank funktionieren.

Engpässe bei Microservices

Microservices, wie ich Ihnen die Architektur gezeigt habe, bieten Ihnen keine eingebaute Skalierbarkeit. Auch sie haben die gleichen Leistungsengpässe wie Webservices oder Webapplikationen. Es sei denn, sie verwenden a NoSQL database, die sie natürlich nicht haben werden, aber selbst sie müssen mit dem Mainframe für Legacy-Daten sprechen, und viele von ihnen werden weiterhin mit relationalen Datenbanken sprechen. Und sie haben einen zusätzlichen potenziellen Engpass, nämlich den Event-Bus, der dazu da ist, miteinander zu kommunizieren.

Wenn Sie eine Umgebung mit sehr vielen Transaktionen haben, kann dieser Ereignisbus auch ein Engpass sein. Wenn Sie nicht die richtige Lösung für einen Eventbus haben.

Skalierbarkeitslösung

Es gibt also glücklicherweise eine Lösung dafür, und zwar einen verteilten In-Memory-Cache. Und ich werde auf die Gründe eingehen, warum es so ist? Aber lassen Sie mich nur einige Behauptungen aufstellen. Der Grund, warum es eine Lösung ist, ist, dass es extrem schnell ist. Es bietet lineare Skalierbarkeit und hohe Verfügbarkeit. Das sind also die drei Gründe, warum es eine Lösung für Skalierbarkeitsprobleme ist. Und es gibt einen zusätzlichen Vorteil, den Sie durch die Verwendung eines verteilten In-Memory-Cache erhalten, den Sie in einem großen Unternehmen wie Wells Fargo tatsächlich als Datenaustauschplattform für mehrere Anwendungen verwenden können. Ich werde das ein bisschen weiter ausführen, aber das ist eine Art Nebenleistung oder Nebeneffekt der Verwendung. Der Hauptgrund ist die Skalierbarkeit.

Verteilter In-Memory Cache

Wie liefert ein verteilter In-Memory-Cache diese Antwort? Wie ist die Lösung für dieses Problem? Der Grund, warum es eine Lösung ist, liegt darin, dass sich ein verteilter In-Memory-Cache zuallererst im Speicher befindet, also superschnell ist. In-Memory ist schneller als sogar NoSQL databases. Und zweitens wird es verteilt. Ein verteilter In-Memory-Cache ist eigentlich eine Sammlung mehrerer kostengünstiger Cache-Server. Und jeder Cache-Server ist kein Datenbanktyp eines Servers. Das sind eher Webserver, 4 bis 8 Kerne, manchmal mehr. 16 bis 32 GB RAM. Holen Sie sich für jede Anwendung so viele davon, wie Sie möchten, und erstellen Sie daraus eine superschnelle und hochgradig skalierbare Infrastruktur für die Anwendung. Sobald Sie eine Anwendungsebene haben, die Sie hier oben sehen, mit den Web-Apps, den Webdiensten und den Mikrodiensten und den Datenbanken, ob diese relational sind, diese veraltet sind oder NoSQL. Auch NoSQL, wie gesagt, ist nicht so schnell wie ein verteilter In-Memory-Cache.

Also, was macht der In-Memory-Distribution-Cache? Es erstellt einen Cluster dieser Cache-Server, und dieser Cluster bündelt den Speicher, die CPU und sogar die Netzwerkkartenkapazität aller dieser Cache-Server. Genau wie die Anwendungsebene und genau wie die NoSQL database, wenn auch noch leichter als die NoSQL database, fügen Sie einfach weitere Cache-Server hinzu, wenn Ihre Transaktionskapazität wächst. Jetzt haben Sie also plötzlich einen redundanten und obendrein, weil er In-Memory ist, muss er die Datenreplikation auf intelligente Weise bereitstellen, und ich werde das gleich durchgehen, um sicherzustellen, dass, wenn überhaupt, ein Cache-Server vorhanden ist ausfällt, gehen keine Daten verloren. Denn ansonsten ist jeder In-Memory-Speicher wertlos. Denn wenn Sie Gigabyte und Gigabyte an Daten verlieren, nur weil ein Server ausfällt, ist das keine sehr attraktive Lösung. Ein verteilter In-Memory-Cache verteilt also nicht nur die Daten, er repliziert sie auch auf intelligente Weise, ohne die Leistung zu beeinträchtigen und Skalierbarkeit.

Wenn Sie also einen verteilten In-Memory-Cache als Teil Ihrer Infrastruktur haben, haben Sie jetzt plötzlich die Möglichkeit, diesen Engpass zu beseitigen, da 80 % Ihrer Datenlesevorgänge in den verteilten Cache gehen. Die 20 % gehen an die eigentlichen Datenbanken, da die Datenbanken immer noch die Hauptdatenquelle sind. Daher müssen alle Aktualisierungen, die Sie an diesen Daten vornehmen, an der relationalen Datenbank des Legacy-Mainframes oder der NoSQL. Aber manchmal sogar mehr als 80 %, 90 % Ihres Lese- oder Schreibverkehrs können einfach auf den verteilten Cache beschränkt werden. Und plötzlich spüren Ihre Anwendungen keinen Engpass mehr.

Das ist jetzt so etwas wie ein wesentliches Anwendungsarchitekturmuster, bei dem Sie einen verteilten In-Memory-Cache haben müssen, wenn Sie möchten, dass Ihre Anwendungen skalieren können.

Verteilte Cache-Skalierbarkeit

Das sind ein paar Skalierbarkeits-Benchmark-Zahlen von NCache, wo Sie sehen können, dass Sie mit nur 4 bis 5 Knoten 2 Millionen Operationen pro Sekunde ausführen können. Und da es sich um eine lineare Skala handelt, fügen Sie einfach 4 weitere Knoten hinzu, wenn Sie auf 5 Millionen gehen möchten. Und wie Sie wissen, sind 2 Millionen Operationen pro Sekunde eine ziemlich hohe Transaktionslast, so dass die meisten Ihrer Anwendungen, wenn sie in dieser Last bleiben können, 90 % Ihrer Anwendungen mit dieser Art von Last zufrieden sein werden. Vielleicht werden einige nicht und sie brauchen mehr. Und wenn sie mehr benötigen, fügen Sie einfach weitere Server hinzu.

Allgemeine Verwendung von verteiltem Cache

Ich hoffe also, dass ich Sie inzwischen davon überzeugt habe, dass ein verteilter In-Memory-Cache eine großartige Idee für eine Anwendungsarchitektur ist. Die nächste oder erste Frage, die mir danach in den Sinn kommt, lautet also: Okay, wie kann ich als Anwendungsentwickler davon profitieren? Denn hier dreht sich alles um Anwendungen. Wie nutze ich einen verteilten Cache, um davon zu profitieren?

App-Daten-Caching
Es gibt also drei gängige Möglichkeiten, wie Sie einen verteilten Cache verwenden können. Nummer eins ist App-Daten-Caching. Dies ist die gebräuchlichste Methode, über die ich gerade gesprochen habe. Welche Daten Sie auch immer aus der Datenbank lesen, Sie behalten sie im Cache, also lesen Sie sie das nächste Mal einfach aus dem Cache, ganz einfach. Und was auch immer Sie aktualisieren, Sie aktualisieren sowohl den Cache als auch die Datenbank.

Nun, eine Sache, die Sie sofort verstehen müssen, ist, dass es beim Zwischenspeichern von Anwendungsdaten ein einzigartiges Problem gibt, nämlich dass die Daten jetzt an zwei Orten vorhanden sind, einer ist die Master-Datenbank, die Ihre relationale sein könnte, NoSQL oder Legacy-Mainframe und einer ist der Cache. Das erste, was schief gehen kann, ist, dass der Cache veraltet sein kann. Sie haben also die Daten aktualisiert, Sie haben eine Anwendung, die nicht mit dem Cache kommuniziert, sie geht und aktualisiert die Daten in der Datenbank, und plötzlich hat der Cache veraltete Daten und veraltete Daten sind wirklich schlecht. Ich bin sicher, Sie wissen das, mehr als jeder andere würde eine Bank wissen, dass veraltete Daten sehr schlecht sind. Einige veraltete Daten sind in Ordnung, aber viele veraltete Daten sind sehr schlecht. Das ist also der Grund, warum die meisten Leute, wenn sie an Caching denken, reflexartig reagieren, dass ich nur schreibgeschützte Daten zwischenspeichern werde, die sich nie ändern oder zumindest während der Lebensdauer meiner Anwendung oder was auch immer , in sehr langer Zeit wird es sich nicht ändern. Nun, wenn das nur etwa 10 %, 15 % Ihrer gesamten Daten sind. Wenn Sie nur 10 % oder 15 % zwischenspeichern, nutzen Sie einen verteilten Cache nicht wirklich aus. Sie müssen in der Lage sein, Daten zwischenzuspeichern, die sich vielleicht alle 5 Sekunden ändern. Oder sogar noch früher. Denn selbst für diese 5-10 Sekunden kann man es 10 Mal lesen. Und wenn Sie das mit Millionen von Transaktionen multiplizieren, die Ihre Anwendung jeden Tag verarbeitet, sparen Sie so viele Besuche der Datenbank und wie Sie an Skalierbarkeit gewinnen.

Jeder verteilte Cache, der diese Herausforderung nicht angeht, dass der Cache nicht veraltet sein sollte, er sollte immer frisch sein, wird Sie zwingen, ihn dann nicht vollständig zu verwenden. Das ist also das erste, was zu beachten ist.
Webanwendungsspezifisches Caching
Anwendungsfall Nummer zwei ist die Webanwendung. Und die häufigste Verwendung für Webanwendungen ist Sessions. Ob Sie Java, ASP.NET, ASP.NET Core oder Node.js, sie alle möchten ihre Sitzungen in einem schnellen und skalierbaren Speicher speichern. Und ein verteilter Cache ist ein viel besserer Speicher als alles andere, was es gibt. Egal ob Java oder .NET oder kein Node.js. Und es gibt andere Dinge wie, da ist die Seite Ausgabe-Caching. Es gibt auch Live-Webanwendungen. Im Fall von .NET wird dies aufgerufen SignalR, dass Sie einen verteilten Cache als Plattform verwenden können, um die Ereignisse zu teilen.

Aber eine Webanwendung, wenn es sich nicht um das Zwischenspeichern von App-Daten handelt, wenn die Webanwendung ihre Daten im verteilten Cache speichert, hat eine andere Art von Problem zu lösen. Das heißt, dass es jetzt keine Datenbank gibt, die eine Kopie dieser Daten enthält. Cache ist der Hauptspeicher. Und ein Cache als Hauptspeicher bedeutet, dass Sie diese Daten verlieren, wenn der Cache-Server ausfällt. Das ist nicht akzeptabel, denn Sie möchten keine Benutzersitzung verlieren, nur weil ein Cache-Server oder ein Webserver ausgefallen ist. Wenn Sie hohe Verfügbarkeit wünschen, muss der Cache über die Fähigkeit verfügen, diese Daten intelligent auf mehrere Server zu replizieren. Wenn also ein Cache-Server ausfällt, verlieren Sie diese Daten nicht. Das ist also der wichtige Teil. App-Daten-Caching hat eine andere Herausforderung. Webanwendungsspezifisches Caching hat andere Herausforderungen.
Pub / Sub-Messaging, CQ & Events
Und der dritte Anwendungsfall ist, dass Sie verwenden können, und das ist etwas, das viele Leute überhaupt nicht wissen, nämlich dass Sie einen verteilten Cache als verwenden können Pub/Sub-Messaging Plattform und Veranstaltungen. Wir haben uns unterhalten und ich werde Ihnen zeigen, dass selbst Microservices Pub/Sub beherrschen müssen. Wenn sie also den verteilten Cache als Pub/Sub-Messaging-Plattform zusätzlich zum Zwischenspeichern von Anwendungsdaten verwenden, stellt Pub/Sub-Messaging für sie keinen Engpass dar.

Es gibt viele andere Messaging-Produkte, die viele Messaging-Funktionen haben. Und ein verteilter Cache erfüllt nicht alle diese Funktionen, aber der verteilte Cache schafft eine sehr schnelle In-Memory-Messaging-Plattform für diese Nachrichten, die nur innerhalb dieser Microservices- oder Webanwendungsumgebung geteilt werden müssen. Es ist also eine viel einfachere Umgebung, in der Sie diese Nachrichten nicht stundenlang aufbewahren müssen. Sie müssen vielleicht nur innerhalb der nächsten Millisekunden geteilt werden. Aber es gibt so viele Transaktionsaktivitäten, dass ohne eine wirklich verteilte In-Memory-Architektur die Messaging-Plattform selbst zu einem Engpass wird. Nun ist also nicht nur die Datenspeicherung ein Engpass, sondern auch Ihre Messaging-Plattform. Denken Sie also daran. Und wiederum hat die Messaging-Plattform das gleiche Problem wie ein webanwendungsspezifisches Caching, das darin besteht, dass normalerweise, was auch immer als Nachricht aufbewahrt wird, keine Sicherungskopie in der Datenbank vorhanden ist. Nun, es könnte eine transformierte Version einiger Daten sein, die bereits in der Datenbank vorhanden sind, und Sie können sie möglicherweise neu erstellen, möchten dies aber nicht. Sie möchten also diese Daten nicht verlieren, Sie möchten diese Nachrichten nicht verlieren. Aus diesem Grund muss ein guter verteilter Cache nicht nur schnell und skalierbar sein, sondern auch diese intelligente Replikation nicht nur für webspezifisches Caching, sondern auch für Pub/Sub-Messaging bereitstellen.

Kubernetes und verteiltes Caching

So haben wir eine Kubernetes-Umgebung, in der sowohl Webanwendungen als auch Microservices ausgeführt werden und die einen verteilten Cache verwendet. Dieser grüne Bereich ist also ein Kubernetes-Cluster. Und Kubernetes hat dieses Konzept eines Clusters. Innerhalb jedes Clusters gibt es mehrere Bereitstellungen. Jedes dieser drei Rechtecke ist also eine Bereitstellung. Es gibt also eine Web-App-Bereitstellung, zwei Microservices-Bereitstellungen, eine verteilte Cache-Bereitstellung und ein API-Gateway für die Microservices.

Ich werde nicht auf die Einzelheiten der Funktionsweise von Kubernetes eingehen, aber im Grunde verwenden Microservices in einer Umgebung wie dieser den verteilten Cache sowohl für das Zwischenspeichern von Anwendungsdaten als auch für das Pub/Sub-Messaging. Während die Webanwendung den verteilten Cache für das Zwischenspeichern von Anwendungsdaten und Websitzungen verwendet.

Die meisten Webanwendungen haben keine Pub/Sub-Messaging weil Pub/Sub-Messaging normalerweise einen stabilen Serverprozess erfordert, um miteinander zu kommunizieren. Aber wie auch immer, einige von ihnen könnten es, aber die meisten tun es nicht. Aber die gleiche Caching-Infrastruktur, die Sie für das Caching von Anwendungsdaten eingerichtet haben, kann für Websitzungen und auch für Pub/Sub-Messaging verwendet werden, und in diesem Fall handelt es sich, wie Sie sehen können, um Docker-Instanzen als Pods . Dies können Windows- oder Linux-Boxen sein, wissen Sie, das hängt von Ihrer Präferenz ab, welchen Weg Sie einschlagen möchten. Die meisten Banken verschieben heutzutage alles auf Linux und sogar .NET Core weil es Linux unterstützt. Jetzt können Sie sowohl .NET- als auch Java-Anwendungen und natürlich Node.js unter Linux haben.

So sieht also eine Kubernetes-Umgebung sowohl für Dienste und Webanwendungen als auch für das Hosten eines verteilten Caches aus. Eine Sache, auf die ich hier hinweisen wollte, ist, dass ein verteilter Cache, der in Kubernetes leben soll, mit Kubernetes kompatibel sein muss. Es muss einen so genannten Kubernetes-Operator implementiert haben. NCache hat es. Unabhängig davon, welchen verteilten Cache Sie sich ansehen, stellen Sie sicher, dass er mit Kubernetes kompatibel ist.

Übersicht über App-Daten-Caching (API)

Das ist also meine einzige Kodierfolie. Ich werde nicht weiter auf die Codierung eingehen. Die ganze Idee dahinter ist, okay, Anwendungsdaten-Caching ist der Hauptanwendungsfall für verteilten Cache, den jede Anwendung, die Sie entwickeln, nutzen sollte. Ob Webanwendung, Webservices oder Microservices. Und Sie können sehen, dass dies eine sehr einfache API ist, die ein verteilter Cache hat.

Cache-Verbindung

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

Abrufen von Daten

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

Schreiben von Daten

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");

Sie haben einen Cache-Handle, Sie tun cache.Get, cache.Contains. Es gibt einen Schlüssel, der normalerweise eine Zeichenfolge ist, und Sie erhalten einen Wert zurück, und ein Wert kann entweder ein Objekt sein, es könnte ein .NET-Objekt sein, es könnte ein Java-Objekt sein, es könnte ein JSON-Dokument sein. Node.js funktioniert offensichtlich in JSON. Aber Sie könnten sogar .NET- und Java-Anwendungen ihre Objekte oder Daten als JSON speichern lassen. Und das ermöglicht es Ihnen sogar, dies als Plattform für die gemeinsame Nutzung von Daten zu verwenden, da Sie eine Java-Anwendung haben, die beispielsweise ein Kundenobjekt speichert, das ein Java-Kundenobjekt war. Wenn es im verteilten Cache gespeichert wird, sagen wir mal so NCache Es wird in ein JSON-Dokument umgewandelt und dann, wenn eine Node.js- oder eine .NET-Anwendung oder .NET Core Anwendung will es holen sie bekommen es … Sagen wir, .NET Core Die Anwendung erhält es als .NET-Kundenobjekt oder als JSON-Dokument, und Node.js würde wahrscheinlich sowieso nur ein JSON-Dokument erhalten. Also, Einfachheit ist da, Abrufen, Hinzufügen, Einfügen, Entfernen so einfach wie es nur geht. Die Lernkurve bei der Verwendung eines verteilten Caches ist also sehr schnell.

Funktionen des App-Daten-Cachings

Ich werde nur schnell einige der wichtigsten Bereiche des App Data Caching durchgehen, denn wenn Sie den verteilten Cache verwenden, ist der größte Anwendungsfall das App Data Caching. Und worauf müssen Sie achten? Die Nummer eins, wie ich bereits erwähnt hatte, es gibt zwei Kopien der Daten, eine in der Datenbank, eine im Cache, also wie halten Sie den Cache aktuell?

Verfall (absolut & gleitend)
Nummer eins ist eine Funktion namens Ablauf das fast jeder verteilte Cache als Feature hat und normalerweise ist es das Absoluter Ablauf. Manche nennen es TTL oder Time to live Expirations. Der andere Ablauf wird aufgerufen Gleitender Ablauf Dies ist nicht für das Zwischenspeichern von App-Daten gedacht, sondern eher für den Sitzungstyp einer Situation, in der Sie das Objekt ablaufen lassen möchten, wenn es für eine bestimmte Zeit nicht verwendet wird. Aber, Absolute Expiration, Sie sagen zum Cache, dass ich weiß, dass sich diese Daten, die ich zwischenspeichere, in den nächsten fünf Minuten oder in den nächsten fünf Stunden oder 24 Stunden nicht ändern werden. Was auch immer die Art der Daten ist, die Sie angeben können. Und am Ende dieser Zeit läuft der Cache automatisch ab. Die Anwendung kann es also einfach hinzufügen und weitermachen. Die Anwendung muss sich nicht darum kümmern, all diese Daten im Auge zu behalten. Das ist also das Minimum, das jeder Cache haben sollte, und die meisten von ihnen haben es. Aber das Problem oder die Begrenzung der Ablaufzeiten ist, dass Sie nur eine fundierte Vermutung anstellen. In einigen Fällen ist es in Ordnung, weil sich die Daten nicht so häufig ändern, aber wie ich bereits erwähnt habe, liegt der wahre Vorteil im Zwischenspeichern von Transaktionsdaten. Bei Transaktionsdaten möchten Sie also genauer sein.
Cache mit Datenbank synchronisieren
Ein weiteres Merkmal, das ein verteilter Cache haben sollte, ist, dass er Ihre Datenbank bis zu einem gewissen Grad kennen sollte, damit er sich selbst mit den Daten synchronisieren kann, die er zwischengespeichert hat. Wenn sich diese Daten ändern, ändern sich die entsprechenden Daten in der Datenbank Cache sollte dieses Element entweder automatisch aus dem Cache entfernen, damit Ihre Anwendung es beim nächsten Mal nicht im Cache findet und gezwungen ist, es aus der Datenbank zu holen, oder der Cache sollte eine Kopie von neu laden es. Und das Neuladen ist nur durch eine andere Funktion möglich, über die ich sprechen werde, sie heißt durchlesen und durchschreiben. Aber, wenn Sie den Cache mit der Datenbank synchronisieren können.

Es gibt also zwei Möglichkeiten, wie Sie synchronisieren können. Einer ist ereignisbasiert. Die meisten Datenbanken haben heutzutage also die Datenänderungsereignisse. SQL Server hat es, Oracle hat es, MongoDB, Cosmos DB, sie alle haben es. Cosmos DB nennt es glaube ich Change Feed, MongoDB nennt es Change Stream und SQL Server nennt es SQL Dependency und Oracle nennt es Database Notifications oder so ähnlich.

Wenn also Ihr verteilter Cache diese Funktionen in der Datenbank nutzt, kann er eine Art Beziehung zwischen seinen zwischengespeicherten Elementen und den Datensätzen der Datenbank herstellen. Wenn sich also diese Daten ändern, benachrichtigt die Datenbank den verteilten Cache, dass sich diese Daten geändert haben. Bitte kümmern Sie sich um Ihre eigene Kopie davon. Ihr Cache kann es also entweder entfernen oder aus der Datenbank neu laden, und wenn die Datenbank keine Ereignisse als Funktion hat, können Sie Polling als weiteren Mechanismus verwenden.
Umgang mit relationalen Daten
Die dritte Sache, die Sie tun möchten, ist, wenn Sie relationale Daten zwischenspeichern, gibt es einige Probleme der Datenintegrität im Zusammenhang mit Beziehungen, Eins-zu-Vielen, Eins-zu-Eins. Wenn Sie also dem Cache mitteilen können, dass dieser Artikel, ich habe dieses Kundenobjekt und ich habe dieses Auftragsobjekt, sie verwandt sind. Wenn also die Anwendung das Kundenobjekt entfernt, entfernt der Cache automatisch alle Bestellungen. Auf diese Weise gibt es also keine, wie Sie es nennen, baumelnden Referenzen im Cache. Es sind solche Sachen, wenn Sie das tun können, dann wird Ihr Cache wieder immer frisch sein.
SQL-Abfragen
Wenn Ihr Cache also mit diesen Funktionen mindestens die ersten beiden Funktionen hat, können Sie sicher sein, alle Arten von Daten in den Cache zu stellen. Und sobald Sie dieses Vertrauen haben, werden Sie anfangen, viele Daten in den Cache zu legen. Und sobald Sie viele Daten in den Cache stellen, tritt ein weiteres Problem auf, nämlich dass es jetzt nicht mehr ausreicht, Daten basierend auf Schlüsseln zu finden. Sie möchten also in der Lage sein, Daten so zu finden, wie Sie sie in der Datenbank finden können, also SQL-Abfragen. Für .NET, .NET Core Es gibt auch ein LINQ. Also, wenn Sie Daten basierend auf Objektattributen suchen können. Sie können so etwas wie „Gib mir alle Kundenobjekte“ sagen, wobei die Stadt San Francisco ist. Dann verhält es sich eher wie eine Datenbank. Es gibt auch Referenzdaten, die Sie durchsuchen können. Es gibt viele Nachschlagedaten, die Sie durchsuchen können. Wenn Sie also die Daten durchsuchen können, wird der Cache jetzt freundlicher. Sie fühlen sich sicherer, wenn Sie immer mehr Daten zwischenspeichern, weil Sie sie finden können. Denn wenn Sie keine SQL-Abfragen machen könnten, dann wird Ihre Anwendung plötzlich sehr kompliziert. Sie müssen jeden Schlüssel, den Sie gespeichert haben, im Auge behalten.
Gruppen, Tags, benannte Tags
Der andere Aspekt ist wieder in der gleichen Beziehung, dass Sie in der Lage sein möchten, verwandte Daten zu gruppieren, damit Sie sie alle auf einmal abrufen können. Verschiedene verteilte Caches bieten also dieses Konzept von Gruppen und Tags und Namens-Tags, sodass Sie dann alles erhalten können, was zu diesem einen Tag passt. Oder alles aus dem Cache löschen oder aus dem Cache holen. Durch die Fähigkeit, Daten schnell zu finden, wird es neben den Schlüsseln sehr wichtig, sobald Sie beginnen, mehr und mehr Daten zwischenzuspeichern.
Durchlesen und Durchschreiben
Dies ist die Funktion, über die ich gesprochen habe, die Read-Through-Write-Through-Funktion. Die Bedeutung dieser Funktion ist, sagen wir, … Lassen Sie mich zuerst erklären, was das ist. Wenn Sie also einen verteilten Cache haben und diese Funktion nicht haben, dann liest Ihre Anwendung alle Daten, legt sie in den Cache und aktualisiert auch die Datenbank damit. Aber da Sie den Cache für mehrere Anwendungen immer relevanter machen, soll der Cache jetzt … wenn der Cache autarker werden kann, kann er sich um sich selbst kümmern, dann vereinfacht das die Anwendungen. Dann haben Sie mehrere Anwendungen, die diesen Cache einfach als In-Memory-Darstellung der Stammdatenquellen behandeln. Sie wissen, wie sie könnten, wie gesagt, Mainframe, relational oder NoSQL. Sie gehen also zu diesem verteilten In-Memory-Cache als Schlüsselwertspeicher, was sehr unkompliziert, sehr einfach ist, alles befindet sich im Speicher, also ist es superschnell und der verteilte Cache kann die Daten lesen, wenn sie nicht zum Lesen verfügbar sind -through ist etwas, das Ihr Code im verteilten Cache registriert. Der verteilte Cache ruft also Ihren Code auf, geht zur Datenbank und liest das entsprechende Element. Nehmen wir also an, Sie führen einen Cache durch. Gehen Sie auf einen bestimmten Schlüssel und dieses Element war nicht im Cache, ruft der Cache den Read-Through auf, um es aus der Datenbank zu holen.
Hinterschreiben
Auf die gleiche Weise können Sie den Cache auch verwenden, um die Daten nicht nur im Cache zu aktualisieren, sondern auch den Cache in der Datenbank aktualisieren zu lassen. Und das Write-Behind ist eine erweiterte Version davon, bei der die Cache-Aktualisierung synchron erfolgt, die Datenbankaktualisierung jedoch asynchron.
Cache-Loader / Refresher
Der Cache Loader und Refresher ist wieder eine weitere Möglichkeit, den Cache aufzuwärmen. Wenn Sie den Cache starten, füllen Sie ihn mit allen Daten, von denen Sie wissen, dass Sie sie immer haben werden. Auf diese Weise müssen Sie also nicht jedes Mal Read-Through aufrufen. Sobald Sie also diesen Cache mit, sagen wir, Millionen von Objekten geladen haben, ist der Cache-Refresher eine weitere Funktion, die bestimmte Teilmengen dieser Daten basierend auf den von Ihnen festgelegten Geschäftsregeln regelmäßig aktualisieren kann. Diese könnten ereignisbasiert sein, sie könnten zeitbasiert sein, was auch immer Ihre Geschäftslogik sagt. Sie können sagen, okay, gehen Sie und holen Sie sich eine aktuellere Kopie der Daten aus der Stammdatenquelle.

Nun, in vielen dieser Situationen haben Sie dieses Szenario, in dem es in Ordnung ist, eine veraltete Kopie davon zu haben, wenn die Daten nicht sehr geschäftssensibel sind, wenn es nicht zu spät oder zu sehr verzögert ist. Aber mit diesen drei Funktionen, Read-Through, Write-Through und Cache Loader/Refresher, haben Sie jetzt plötzlich einen Cache, der sehr intelligent ist. Es kann sich selbst aus mehreren Datenquellen laden und nicht nur innerhalb der Anwendung verfügbar machen, wie ich bereits erwähnt habe, sondern über mehrere Anwendungen hinweg.

Es gibt also mehrere Anwendungen, wie ich bereits erwähnt habe, das ist der Nebeneffekt. Der Nebennutzen der Verwendung eines verteilten In-Memory-Cache. Was bedeutet das? Das bedeutet, dass der verteilte Cache jetzt zu einer gemeinsamen Infrastruktur für mehrere Anwendungen wird. Wenn also Anwendungen Daten miteinander teilen müssen, anstatt sich gegenseitig anrufen oder auf ihre Datenbanken zugreifen zu müssen, legen Sie sie einfach in einen sehr einfach zu verstehenden Schlüsselwertspeicher, der sich im Speicher befindet, superschnell und hochgradig skalierbar ist. Und weil all die Funktionen, die ich erwähnt habe, Read-Through, Write-Through, Cache Loader, Refresher, all die anderen SQL-Suchen, all dies macht dies zu einer datenbankähnlichen Sache, aber es ist keine Master-Datenquelle.

In der Datenfreigabeplattform ist der Cache also nicht der Master. Es ist nur eine Kopie anderer Master, aber es ist nur zum Teilen gedacht. Und ich weiß, dass sich viele Unternehmen heutzutage stark darauf konzentrieren, mehrere Anwendungen zu konsolidieren, um eine gemeinsame Ansicht und eine gemeinsame Funktionalität zu haben.

Ich weiß, dass viele der Banken, mit denen wir gesprochen haben, möchten, dass die Customer Journey über mehrere Anwendungen hinweg verstanden wird. Wie kommunizieren diese Anwendungen also miteinander? Was ist dieser zentrale Punkt, an dem sie Daten miteinander teilen können? Es muss etwas im Speicher sein. Wenn es nicht im Speicher ist, wird es ein weiterer Engpass sein. Und das Schöne an In-Memory ist, dass Sie es jederzeit neu starten können und es keinen Datenverlust gibt. Denn es werden lediglich Daten aus den Stammdatenquellen neu geladen. Aber es wird sich selbst zur Verfügung stellen. Und da es redundant ist, wird es auf mehrere Server repliziert. Wissen Sie, die Wahrscheinlichkeit, einen verteilten Cache vollständig zu verlieren, ist sehr, sehr gering. Und ich werde einige der anderen Funktionen durchgehen, bei denen Sie tatsächlich denselben Cache in mehreren Regionen, mehreren Rechenzentren, einem in San Francisco, einem in New York und so und so weiter live haben können. Und auf diese Weise weiß ich, dass ich, wenn Sie eine Notfallwiederherstellungssituation haben, in den Nachrichten gesehen habe, dass Sie vor ein paar Jahren mit einer ziemlich großen Abschaltung konfrontiert waren. Nun, Situationen wie diese erfordern eine echte Notfallwiederherstellung. Also muss alles über mehrere Regionen hinweg repliziert werden. Und wenn Sie einen verteilten Cache für die gemeinsame Nutzung von Daten verwenden, sollte dieser verteilte Cache auch aus mehreren Gründen repliziert werden, darauf gehe ich ein. Dies ist jedoch ein sehr, sehr wichtiger Nebennutzen für große Unternehmen, insbesondere wie Wells Fargo, um mehrere Anwendungen zusammenzuführen. Und wieder können Sie mehrere davon haben, denn Sie sind ein so großes Unternehmen, dass Sie möglicherweise keinen Master für das gesamte Unternehmen haben, oder Sie können. Oder Sie haben mehrere davon in bestimmten Teilen Ihres Unternehmens, um Daten auszutauschen.

Verteilte Cache-Architektur

Nachdem ich nun über alle Möglichkeiten gesprochen habe, wie Sie einen verteilten Cache verwenden können, was sollten Sie in Bezug auf seine Architektur von einem guten verteilten Cache erwarten?

Hochverfügbarkeit

Nummer eins ist Hochverfügbarkeit. Da ein verteilter Cache in Live-Produktionsumgebungen verwendet wird, müssen Sie sehr skeptisch sein, wenn er Ihnen keine wirklich hohe Verfügbarkeit bietet, und hohe Verfügbarkeit bedeutet, dass der Cluster, den der verteilte Cache erstellt, einen Peer haben muss. To-Peer-Architektur. Wenn es keine Peer-to-Peer-Architektur hat, wenn es ein Master-Slave-Ding hat, dann wissen Sie, dass Slaves schreibgeschützt oder funktionsunfähig werden, sobald der Master stirbt. Daher ist die Möglichkeit, Server hinzuzufügen oder zu entfernen, jeder Server zur Laufzeit sehr wichtig.

Lineare Skalierbarkeit

Nummer zwei ist die lineare Skalierbarkeit, die durch die Partitionierung der Daten entsteht. Ich werde einfach zur nächsten Folie gehen und darüber sprechen. Die Partitionierung erfolgt also auf zwei Arten, eine einfache Partitionierung ohne Replikation und die zweite Partitionierung mit Replikation. Ein verteilter Cache bietet Ihnen also, wie ich bereits erwähnt habe, Redundanz und eine intelligente Replikation.

Was ist diese intelligente Replikation? Intelligente Replikation bedeutet, dass alle Daten … die Daten partitioniert sind und jede Partition auf einem anderen Server gesichert wird, und das alles dynamisch. Es ist also eine Selbstheilung. Wenn Sie also einen neuen Server hinzufügen, wird eine neue Partition erstellt und neue Replikate werden erstellt und die Daten werden automatisch ausgeglichen.

Also, hier ist ein Beispiel. Angenommen, Sie haben mit einem Cache-Cluster mit zwei Servern begonnen und wollten einen dritten hinzufügen, weil Ihre Transaktionslast zunimmt. Sobald Sie einen dritten Server hinzufügen, wird automatisch eine dritte Partition erstellt. Jetzt haben Sie drei Partitionen. Also müssen auch die Nachbauten nachjustieren. All das geschieht dynamisch oder automatisch.

Hochverfügbarkeit (Datenausgleich) beim Hinzufügen/Entfernen eines Knotens

Und auf die gleiche Weise, sagen wir, Sie wollen es oder ein Server ist aus irgendeinem Grund ausgefallen. Nehmen wir an, Server 3 ist ausgefallen, Partition 3 ist ausgefallen. Sobald Partition 3 ausgefallen ist, wird Replica 3 aktiv. Und jetzt haben Sie eine Anomalie, bei der Sie zwei Server und drei Partitionen haben. Jetzt muss es sich also automatisch wieder in zwei Partitionen und zwei Replikate zusammenführen. All dies sollte automatisch ohne menschliches Eingreifen erfolgen. Wenn es menschliches Eingreifen erfordert, ist es nicht wirklich hochverfügbar. NoSQL databases, da es sich um Datenbanken handelt, die mit der dauerhaften Speicherung vieler Daten umgehen müssen, bieten sie diese dynamische Neupartitionierung nicht. Und es ist okay für a NoSQL database. Aber es ist nicht in Ordnung für einen In-Memory-Speicher. In-Memory-Speicher muss viel schneller sein, viel agiler beim Auf- und Absteigen in Bezug auf die Anzahl der Server.

WAN-Replikation

Hier ist die hohe Verfügbarkeit, wenn Sie mehrere Standorte haben. Wenn Sie also einen verteilten Cache an Standort 1 haben, sagen wir in San Francisco, und Standort 2 haben möchten, können Sie einen Aktiv-Passiv- oder einen Aktiv-Aktiv-Cache verwenden. Früher sahen wir eher Aktiv-Passiv, jetzt wechseln fast alle wegen der Cloud zu Aktiv-Aktiv. Es ist viel einfacher, die Infrastruktur zum Laufen zu bringen. Die Leute haben also nur Aktiv-Aktiv-Sites.

Und bei der Aktiv-Aktiv-Herausforderung ist mehr, weil beide Seiten möglicherweise dieselben Daten aktualisieren, sodass in den verteilten Cache eine Konfliktlösungsfunktion integriert sein muss NCache hat, aber Sie müssen sich darüber im Klaren sein, dass Sie, um echte Hochverfügbarkeit zu erreichen, über ein Rechenzentrum hinausgehen und in mehrere Rechenzentren gehen müssen.

In vielen Situationen sind zwei Rechenzentren möglicherweise nicht ausreichend. Wenn Sie also über drei oder mehr Rechenzentren verfügen, müssen Sie dennoch über die gleiche Aktiv-Aktiv-Replikationsfunktion verfügen. Wenn also ein Rechenzentrum ausfällt, sollten die anderen beiden Rechenzentren in der Lage sein, die Last zu übernehmen, und Sie sollten in der Lage sein, dieses eine Rechenzentrum wieder hochzufahren und es wieder anzuschließen, und Ihre Benutzer sollten keine Unterbrechung sehen.

Hochverfügbarkeit (WAN-Replikation): 3+ Aktiv-Aktiv

Wenn Sie dieses Ziel mit einem verteilten Cache erreichen können, alles dynamisch, ohne menschliches Zutun … natürlich erfordert die Wiederherstellung eines Rechenzentrums wieder menschliches Eingreifen. Aber es sollte kein menschliches Eingreifen geben, wenn ein Rechenzentrum ausfällt, damit die Hochverfügbarkeit wirklich hoch ist. Wenn es auch nur fünf Minuten nach unten geht, ist es nicht akzeptabel.

Das ist das Ende meines Vortrags. Ich habe versucht, es so schnell wie möglich zu halten, nur damit wir noch etwas Zeit haben. Ich werde Ihnen nur einige zusammenfassende Gedanken geben. Ich denke, das Wichtigste, was ich vermitteln wollte, ist, dass ich für jede Anwendung, die Sie entwickeln, dringend empfehle, dass Sie für die drei Anwendungsfälle, über die ich gesprochen habe, einen verteilten In-Memory-Cache haben müssen. Und dann sollten Sie es idealerweise auch für den Datenaustausch über mehrere Anwendungen hinweg verwenden. Und in jedem Fall sollten Sie selbst innerhalb derselben Anwendung versuchen, mehrere Standorte zu haben, um sicherzustellen, dass Sie die Notfallwiederherstellung darin haben.

Und ich spreche hier von 15 Jahren Erfahrung. Wir haben dies getan. NCache ist seit mehr als 15 Jahren auf dem Markt und wir arbeiten mit vielen Banken zusammen. Wir waren traditionell ein .NET-Shop, aber NCache unterstützt jetzt vollständig .NET und Java und Node.js. Sowohl clientseitiger als auch serverseitiger Code für .NET und Java, wobei Node.js nur die Client-API ist. Das ist das Ende meines Vortrags.

Danke Iqbal. Ich kann nicht genug betonen, wie zeitgemäß und relevant diese Präsentation war, während wir bei Wells Fargo den Modernisierungspfad beschreiten. Vielen Dank dafür. Team, ich werde Sie daran erinnern, wenn Sie Fragen haben, stellen Sie sie bitte in Ihrem Chat. Wir haben eine Reihe von Fragen, Iqbal. Viele der Fragen des Teams sind da, werden diese Präsentation und das Video zur Verfügung gestellt? Die Antwort ist ja. Diese wird Ihnen nach der Präsentation auf Anfrage zur Verfügung gestellt. Wir senden Ihnen den Link zu. Also, Iqbal, hier sind einige der Fragen, die hereingekommen sind.

Wie gehen verteilte Caches mit sensiblen Daten um? Wie transparente Verschlüsselung ist eine Frage.

Ja, ich glaube, ich hatte keine Zeit, um darauf einzugehen, aber das ist auch ein sehr wichtiger Aspekt. Ein Produkt wie NCachebietet zum Beispiel Sicherheitdienst auf mehreren Ebenen. Es gibt die Authentifizierung, Autorisierung, Sicherheit. Es gibt die Verschlüsselung. Also mehrere Verschlüsselungsalgorithmen. Einige 128-Bit-, einige 256-Bit-Verschlüsselung. Da ist TLS, Transportsicherheit. Der Cache für eine Bank wie Wells Fargo muss also Sicherheit bieten, und deshalb arbeiten wir mit Banken zusammen. Das ist die Funktion, die wir schon lange haben. Daten können also verschlüsselt werden. Und wieder, all dies ist automatisch. Dazu ist keine Programmierung erforderlich. Das sind nur Konfigurationen. Aber ein verteilter Cache muss die Sicherheit durch diese verschiedenen Merkmale ansprechen.

Die nächste Frage ist, was ist der Unterschied zwischen Datenbanken wie Oracle-Cache-Objekten und -Speicher und einem anderen Speicher-Cache vor Oracle? Kann ich grundsätzlich das gleiche Ergebnis erzielen, indem ich Oracle mehr Speicher zuweise?

Ich denke, das Schlüsselwort ist "verteilt". Alles, was nicht verteilt ist, kann schnell, aber nicht skalierbar sein. Deshalb war meine erste Folie die Definition des Wortes Skalierbarkeit. Können Sie als Bereitstellung von 1 Box auf 10 Boxen auf 50 Boxen gehen? Einige unserer Kunden haben eine Anwendungsserverfarm mit 150 oder mehr Anwendungsservern. Und wissen Sie, wir arbeiten auch mit … Übrigens ist die State Street Bank auch ein weiterer Kunde von uns, und damit kann kein In-Memory-Caching durch einen einzelnen Datenbankserver damit umgehen. Ja, das ist eine sehr wichtige Funktion, um Oracle und SQL Server und andere schnell zu machen, aber sie können nicht skalierbar sein. Skalierbarkeit kann nur durch Verteilung erreicht werden.

Wie funktioniert NCache Leistung im Vergleich zu Redis, Kohärenz und andere Marktprodukte. Und dann ist ein weiterer Teil der Frage, haben Sie in Ihrer Roadmap Pläne, zusätzliche Programmiersprachen wie Scala oder Python zu unterstützen? Lassen Sie mich eigentlich zuerst die zweite Frage beantworten. Ja, wir werden Scala und Python sehr gerne unterstützen. In der Tat werden wir das dieses Jahr tun. Wir unterstützen Java nun seit fast 10 Jahren. Die meisten Kunden, die verwenden NCache, wenn sie ein großes Unternehmen sind, verwenden sie es sowohl für Java als auch für .NET. Auch wenn sie es vielleicht aus einer .NET-Perspektive kaufen. Das ist also das erste.

Die zweite Frage war, wie funktioniert NCache Leistung vergleichen mit Redis und andere? Ich meine, sie sind alle schnell. Ich werde niemanden schlecht aussehen lassen und ich denke, ihr solltet euren eigenen Vergleich anstellen, aber sie sind alle schnell. Ich denke, das Einzige, wovor ich Sie warnen möchte, ist, dass einige der Spieler Ihnen einen falschen Eindruck vermitteln, wenn sie die Benchmarks durchführen. Zum Beispiel beinhalten die Benchmarks, die wir geben, den kompletten Hin- und Rückweg. Wenn Sie also eine cache.Get- oder cache.Insert-Operation ausführen, wird diese Operation nicht abgeschlossen, es sei denn, diese Einfügeoperation kommt zurück zur Anwendung. Aber einige der anderen Anbieter würden Ihnen tatsächlich einen viel größeren Benchmark als unseren zeigen, aber sie werden das tun, was sie Feuer und Vergessen nennen. Also, wenn ich es nur versende und mir keine Gedanken darüber mache, kann ich natürlich viel mehr tun. Und zwar auf der Java-Seite Hazelcast und Redis Labs sind an genau demselben Punkt hintereinander hergelaufen. Also belasse ich es einfach dabei.

Sie haben mit anderen Banken und so weiter gearbeitet, andere Compliance-Probleme im Zusammenhang mit der Verwendung von PCI-Daten zurück zu den sensiblen Daten im Cache-Bereich. Sind Sie dort auf Probleme bei der Einhaltung gesetzlicher Vorschriften gestoßen?

Nicht wirklich. Ich meine damit zunächst einmal die Tatsache, dass wir all diese verschiedenen Sicherheitsmerkmale verschlüsseln, sowohl auf Datenebene. Denn Sie können Daten vor dem Zwischenspeichern und auch auf Transportebene verschlüsseln. Wir haben auch Authentifizierung und Autorisierung auf der Serverseite, und dies ist die Seite des Cache-Servers. Und ich denke, das reicht für … und obendrein läuft ein Cache in einem gesicherten Rechenzentrum. Ein Cache ist nicht etwas, das für eine externe Entität zugänglich ist. Wenn Sie also all dies mit der Tatsache kombinieren, dass Cache-Läufe im Inneren hatten, hatten wir keine und, wissen Sie, wir hatten … ich meine zum Beispiel, die Citi Group und die Bank of America und Barclays haben sie verwendet NCache seit mehr als einem Jahrzehnt und hatte keine Probleme.

Wie funktioniert es mit Mainframe-Datenbanken?

Ich denke, ein Mainframe ist etwas, das Sie … Sagen wir, das werden Sie höchstwahrscheinlich … Sie haben wahrscheinlich heute Webdienste und Sie werden wahrscheinlich einige Microservices entwickeln, um Anwendungen den Zugriff auf den Mainframe zu ermöglichen. Mainframe ist ein weiterer Fall, in dem das Abrufen von Daten vom Mainframe sehr kostspielig ist. Sowohl in Bezug auf die Geschwindigkeit als auch, wenn Ihr Mainframe außerhalb gehostet wird, müssen Sie möglicherweise sogar pro Transaktion oder pro Reise bezahlen. Wenn Sie also, wie gesagt, mehr dieser Daten in Ihrem Kubernetes- oder Microservices-Layer zwischenspeichern und weniger Fahrten zum Mainframe unternehmen können, werden Sie nicht nur an Leistung gewinnen, sondern wahrscheinlich auch viel Geld sparen.

Wie wird die Konsistenz und Verfügbarkeit der Daten über den verteilten In-Memory-Cache sichergestellt, wenn Knoten hinzugefügt und entfernt werden?

So kann ich zumindest darüber reden NCache zur Verbesserung der Gesundheitsgerechtigkeit NCache stellt sicher, dass beim Hinzufügen oder Entfernen von Knoten alle vorgenommenen Aktualisierungen und vorgenommenen Änderungen mit der Tatsache abgeschlossen werden, dass wir die Zustandsübertragung durchführen, sagen wir, wir verschieben die Partitionierung und so weiter, NCache ist sich bewusst, dass es sicherstellen muss, dass alle diese Aktualisierungen korrekt angewendet werden, während sichergestellt wird, dass der Knoten hinzugefügt wird und die Zustandsübertragung, was wir Zustandsübertragung nennen, das ist der Datenausgleich, um Daten von einer Partition auf die andere zu verschieben passiert auch immer wieder. So, NCache sorgt dafür.

Wenn Microservices mit ihren eigenen Datenbanken vertrieben werden, wie ich auf dem Bild gesehen habe, wie können diese dem Kunden ein Omni-Channel-Erlebnis bieten?

Also, der verteilte Datenbankteil, ich denke, die Jury ist sich nicht sicher, wie verteilt diese Datenbanken sein werden. Wie partitioniert diese Datenbanken sein werden. Weil, wie ich in meinem Vortrag sagte, zumindest theoretisch jeder Microservice seine eigene logische Datenbank haben kann, auch wenn sie sich physisch auf denselben Datenbankservern befinden, denn wenn Sie Dinge bereitstellen, werden Sie das nicht haben 100 verschiedene Datenbankserver, jeder für jeden Microservice. Sie werden einige konsolidierte Datenbankserver haben. Die Tatsache, dass Sie eine Trennung haben, gibt Ihnen wahrscheinlich etwas mehr Flexibilität NoSQL Aber es ist immer noch unklar, wie viel Sie wirklich mit dieser Einschränkung einer relationalen Datenbank davonkommen können. Meine Vorhersage ist, dass Sie mit den gleichen relationalen Datenbankservern enden werden. Sie können die logische Trennung haben oder nicht. Sie haben möglicherweise separate Schemas oder dasselbe Schema, Sie sprechen nur mit verschiedenen Tabellen, aber die Datenbankserver werden immer noch dieselben sein. Es ist also das gleiche Problem, das Sie selbst bei Webdiensten angehen, sie werden es bei Microservices angehen. Ich denke, mit der Zeit läuft. Ich kann dir nicht genug danken. Das war sehr interessant. Die Fragen fluten weiter herein, aber es ist klar, dass wir nicht alle erreichen können. Damit gebe ich es Ihnen zurück.