Entwicklung von Azure Microservices & App Services mit NCache

Aufgezeichnetes Webinar
Von Ron Hussain und Adam J. Keller

Optimieren Sie die Leistung und Skalierbarkeit Ihrer Azure-Cloud-Apps für die Ausführung unter Spitzenlast. Verwenden Sie ein schnelles, skalierbares und gemeinsames Datenrepository, um die Erfahrung mit Azure-Dienstanwendungen ohne Daten- oder Sitzungsverlust zu verbessern.

Dieses Webinar zeigt, wie Sie Azure Microservices und App Services mit einem verteilten .NET-Cache in der Cloud integrieren.

Wir behandeln:

  • Einführung in Azure Microservices und App Services
  • Verwenden von NuGet-Paketen für NCache Client-Anwendungsressourcen
  • Making NCache API-Aufrufe von den Azure-Diensten
  • Erstellen und Bereitstellen eines verteilten Caches in Azure
  • Verwenden des Caches für Azure-Dienste
  • Überwachen des Caches, in dem Azure Microservices und App Services ausgeführt werden

Das Thema, das wir heute ausgewählt haben, ist die Verwendung NCache Dies ist das wichtigste verteilte Caching-System innerhalb von Azure-Diensten. Mein Hauptaugenmerk liegt heute auf Azure-Microservices. Ich werde über einige architektonische Details von Microservices sprechen. Ich werde einige Details darüber erläutern, warum Sie verteilten Cache in Mikrodiensten benötigen, welche Einschränkungen bestehen, und dann werde ich auch über App-Dienste-Projekte für Microsoft Azure-Webanwendungsdienste sprechen, für die Ihre Webanwendungen möglicherweise auch ein verteiltes Caching-System benötigen Umgang mit Daten, für Sitzungen, Ausgabe-Caching. Also, diese Art von Funktionen werde ich hervorheben. Die Hauptagenda, die ich heute behandeln werde, der praktische Teil in diesem Webinar, wird sich auf die Bereitstellungsarchitektur konzentrieren. Wie genau ein verteilter Cache bereitgestellt wird und wie genau Ihre Anwendungen eine Verbindung damit herstellen müssen.

Azure-Microservices und -App-Dienste

Zunächst werde ich also auf einige einführende Details zu Azure-Microservices und -App-Diensten eingehen

Was ist ein Microservice?

Was ist ein Mikrodienst? Das ist also ein sehr gebräuchlicher Begriff, den wir heutzutage oft hören. Es ist eine Plattform und wird von Microsoft Azure angeboten. Es gibt einige AWS und dann gibt es auch einige Drittanbieter. Normalerweise würde ich nur Akka.NET nennen, das ist auch eine sehr beliebte Plattform auf Java, und dann haben sie es auch in Richtung .NET gebracht. Ein Microservice ist eine Plattform, die die Geschäftsszenarien des Kunden kapselt und sich um bestimmte Probleme kümmert, die der Kunde innerhalb der Anwendung hat. Es könnte also von einem kleinen Ingenieurteam entwickelt werden. Es könnte in jeder Programmiersprache geschrieben werden.

Es könnte zustandsbehaftet sein, es könnte zustandslos sein, aber es ist etwas, das innerhalb der Anwendung unabhängig ist. Es kann also unabhängig versioniert, implementiert und bereitgestellt werden, und das Schöne an der Microservice-Architektur ist, dass sie unabhängig skaliert werden kann. Sie müssen nicht eine gesamte Anwendung skalieren. Wenn ein Teil innerhalb der Anwendung diese Eigenschaften erfüllt, können Sie ihn einfach als Microservice implementieren. Ihre Anwendung kann es als Microservice-Ressource verwenden und dann können Sie diesen bestimmten Teil skalieren, ohne sich um die Skalierbarkeit der gesamten Anwendung kümmern zu müssen. So erhalten Sie einen detaillierteren Ansatz für verschiedene Segmente innerhalb der Anwendung.

Ich habe hier zwei gemeinsame Punkte hervorgehoben, dass Ihre Microservices wohldefinierte Schnittstellenprotokolle sind und auch mit anderen Microservices interagieren. Und dann haben sie eindeutige Namen, die Sie in Microsoft Azure erhalten, und dann müssen sie im Falle von Fehlern konsistent und verfügbar bleiben. Das ist also ein weiteres wichtiges Merkmal eines Microservices. Dies ist etwas, das ich von der Microsoft MSDN-Website kopiert habe. Also, und ich bin mir ziemlich sicher, dass jeder weiß, was Microservice ist. Das sollte also einige grundlegende Details zu Microservices abdecken, okay?

Microsoft Azure-Service-Fabric

Hier ist das Diagramm, in dem Ihr Anwendungstyp einen Diensttyp hat, der zustandsbehaftet oder zustandslos sein kann. Das habe ich schon abgedeckt.

Microsoft-Azure-Service-Fabric

Es gibt einen anderen Anwendungstyp, der ebenfalls über eigene Microservices verfügen könnte und dann möglicherweise mit einigen Back-End-Datenquellen für Code und Konfigurationen kommuniziert. Möglicherweise wird ein Webdienst aufgerufen. Es könnte auch einige Daten haben, auf die es Zugriff benötigt, und dann sind sie es, wissen Sie ... Dies ist nur eine Idee, wie Microservices aufgebaut sind. Es könnte mehrere Anwendungen geben, und jede Anwendung könnte mehrere Microservices haben, die wiederum ein Cluster von Servern, Instanzcluster, sind. Sie könnten Partitionen innerhalb des Microservice haben. Das ist in erster Linie ein zustandsbehafteter Microservice. Wenn Sie über mehrere Microservices verfügen, können Sie zwischen zustandsbehafteten oder zustandslosen Microservices wählen.

Microsoft-Azure-Service-Fabric-2

Wenn es sich um zustandsbehaftete Microservices handelt, hätten Sie eine Datenpartition und dann gibt es Repliken anderer Partitionen. Wenn also eine Partition ausfällt, wird die Sicherung automatisch verfügbar gemacht. Das ist also Teil von Microsoft Azure, das ist auch ein allgemeiner Teil der Microservice-Architektur, und das ist es, was Amazon Ihnen auch bietet, Akka.NET, das auch das gleiche Frageformat hat. Microservice ist also etwas, das innerhalb seiner Architektur standardmäßig einen Zustand in sich selbst bereitstellt. Ich werde also hervorheben, wo genau Sie ein verteiltes Caching benötigen NCache. Warum genau Sie einen verteilten Cache benötigen und es einige Engpässe gibt, gibt es ein paar Probleme, die der verteilte Cache im Rahmen dieses Webinars lösen wird, das ich behandeln werde.

Einführung in Azure Web App Services

Dann werde ich auch über Azure-Webanwendungsdienste sprechen. Es ist einfacher, Webanwendungen in Microsoft Azure bereitzustellen.

Einführung in die Azure-Webapp-Dienste

Sie müssen nicht über eine vollständige VM verfügen. Es reduziert tatsächlich Ihre DevOps-Zeit, die Menge an benötigtem Fachwissen, die benötigte Zeit, es ist etwas, das verwaltet wird. Sie könnten also einfach eine instanzbasierte Anwendung in Microsoft Azure bereitstellen. Es ist eine vollständig isolierte dedizierte Umgebung für Ihre Anwendungen. Sie können es skalieren. Sie können mehrere Anwendungen hosten. Es können Ihre mobilen Apps, das Web oder Ihre Funktions-Apps sein, je nachdem, was zu diesem Zeitpunkt erforderlich ist, können Sie es mit unserem Microsoft Azure-Web-App-Servicemodell verwenden.

Und dann ist es hochgradig skalierbar, ich habe bereits erwähnt, dass die Isolierung garantiert ist. Sie erhalten einen sicheren Netzwerkzugriff und können dann auch eine hohe Speicherauslastung und andere benötigte Ressourcen nutzen. Und dies ist ein Übergang, den die meisten Bereitstellungen vornehmen, wo Sie statt der gesamten VM, die Ihre Anwendung in einem Webformular hostet, oder einem Webgartenszenario, in dem Sie die gesamte VM verwalten müssen, einen instanzbasierten Ansatz verfolgen können wo eine dienstbasierte Anwendung bereitgestellt werden kann, und es könnte eine typische MVC-Anwendung sein, die Sitzungen verwenden kann, die Datenbankaufrufe verwenden kann. Also, alle Arten von regulären MVC-Webanwendungsbezogenen Konzepten, aber es ist nur so, dass die Bereitstellung etwas anders ist.

Verteiltes Caching

Nachdem wir nun Azure-Microservices und Azure-Webanwendungsdienste definiert haben, richtig? Microservice in Microsoft Azure ist also ein Service-Fabric-Projekt, während Web-App-Dienste ein App-Service-Projekt sind. Ich werde also Details dazu hervorheben und über das Netzwerkteil sprechen, das Sie benötigen, um den verteilten Cache zu verwenden.

Was ist ein verteilter In-Memory-Cache?

Zuerst werde ich über verteilte Caching-Konzepte im Allgemeinen sprechen.

was-speicher-verteilter-cache

Was ist ein verteilter Cache? Ein verteilter Cache ist ein Cluster kostengünstiger Caching-Dienste, die für Speicher und ihre Ressourcen für die Rechenleistung und dann für ihre Speicherleistung zusammengefasst werden, und im Fall des verteilten Caches ist der Speicher der Hauptspeicher. Sie bündeln also alle Speicherressourcen in einer logischen Kapazität.

Dann können Sie Ihre Cache-Updates auf allen Cache-Servern synchronisieren. Zum Beispiel wird jede Aktualisierung, die auf einen bestimmten Server angewendet wird, auf alle Caching-Server angewendet. Verteilter Cache ist also ein Cluster aus mehreren kostengünstigen Cache-Servern, die zu einer logischen Kapazität zusammengefügt werden. Sie haben mehrere Server in Microsoft Azure, diese werden VMs sein. So, NCache wird auf einer virtuellen Maschine bereitgestellt. Dies ist die aktuelle Bereitstellungsoption. NCache kann auch im Docker bereitgestellt werden, oder? Das ist also eine weitere Bereitstellungsoption. Ein Cache-Server, der auf einer VM ausgeführt wird, wird also als separate Ressource innerhalb von Microsoft Azure behandelt, und das ist die typische Bereitstellung, soweit dies der Fall ist NCache serverseitige Konfiguration betroffen ist.

Das nächste Merkmal eines verteilten Caches ist, dass Sie alle Cache-Updates auf allen Caching-Servern synchronisieren sollten. Sie könnten 2 3 4 Caching-Server haben und diese sollten eine konsistente Sicht auf die Daten haben. Daten sollten für alle Anwendungen, die damit verbunden sind, in einem einheitlichen Zustand sichtbar sein.

Und dann könnte es für Speicher und Transaktionen linear skaliert werden, wenn Sie Ihre Kapazität erweitern, Sie mehr Speicherplatz benötigen, mehr Ressourcen, Sie einfach mehr und mehr Caching-Server einführen können, und es sollte linear wachsen. Und ... dann ist die Replikation ein weiterer Teil davon, der Daten replizieren sollte, denn alle Daten, die hinzugefügt werden, wenn der Server ausfällt, sollten automatisch repliziert werden. Die Replikation sollte basierend auf dem Betrieb erfolgen, dann sollten Daten verfügbar gemacht werden, wenn ein Server ausfällt.

Dies sind also einige allgemeine Merkmale des verteilten Caches.

Datenspeicherung ist Skalierbarkeitsengpass

In der Regel kommunizieren Ihre Anwendungen, seien es App-Dienste oder Mikrodienste, mit einigen Back-End-Datenquellen. In Microsoft Azure könnten Sie eine Folgeserverinstanz haben, die sich im selben V-Netz oder einem Kreuz-V-Netz befinden könnte, aber Sie sprechen immer noch mit dem Datenbankserver.

datenspeicherung-ist-engpass

Es könnte also langsam sein und möglicherweise nicht sehr skalierbar sein. Daher ist es sinnvoller, auch in Microsoft Azure eine verteilte Caching-Schicht einzuführen. Und ich werde auch über Anwendungsfälle in Bezug auf Microservices-In-App-Dienste sprechen.

NCache Einsatz

Dies ist eine typische Bereitstellung von NCache.

ncache Bereitstellung in Azure

In Microsoft Azure hätten Sie also VMs, die horizontal skalieren würden, Sie könnten einfach ein virtuelles Netzwerk erstellen, VMs erstellen und dann installieren NCache auf diesen VMs oder verwenden Sie unsere Azure- oder AWS-Images. Also, um es so zu sagen, und dann können Ihre Anwendungen Microservices, API-Apps, typische IIS-gehostete Apps auf anderen VMs verbinden, oder es könnten App-Dienste sein, mit denen sie sich alle verbinden können, und es erspart Ihnen den Weg zu den Backend-Datenquellen. Das ist also die allgemeine Idee einer typischen Bereitstellung von NCache und ich werde darauf zurückkommen, sobald wir zu unserer Bereitstellung für Microservices und Azure-App-Dienste übergehen. In der Cloud würde sich dies geringfügig ändern. Also, wir werden darüber reden.

Drei häufige Verwendungen von NCache

IN ORDNUNG! Dies ist die wichtigste Folie in diesem Webinar. Ich möchte hervorheben, wo genau Sie einen verteilten Cache in Microsoft Azure-Diensten verwenden würden, richtig? Sprechen Sie also normalerweise über Webanwendungen, Webdienste, Back-End-Anwendungen und Fensterdienste, die auf Daten aus einer zentralen Quelle zugreifen müssen und ein sehr schnelles Repository benötigen. Das ist also ein typischer Anwendungsfall. Mit Microsoft Azure haben Sie bereits eine sehr skalierbare Plattform. Ihre Anwendungen können linear skaliert werden, und das ist auch der typische Fall bei Webformularen und Webgarden.

Daher habe ich einige wichtige Anwendungsfälle aufgelistet, die Sie innerhalb von Microsoft Azure für Dienste verwenden können.

App-Daten-Caching

Zunächst einmal können Sie es für das Daten-Caching verwenden, und dies gilt für Microsoft Azure-Microservices sowie für App-Dienste. Wenn es staatenlose Dienste gibt, richtig? Da zustandsbehaftete Dienste ihre eigene Partitionierung erfordern würden und Sie dann auch Replikate hätten, haben zustandslose Dienste keine Replikate. Ein wichtiger Aspekt ist also, dass Sie eine zustandslose Anwendung haben, aber dennoch Datensicherheit haben möchten, richtig? In diesem Fall können Sie also Daten in einem verteilten Cache ablegen. Der verteilte Cache kann per Design den Replikationsaspekt und den Aspekt der Hochverfügbarkeit abdecken. Ihre Daten würden also auch den zustandslosen Microservices zur Verfügung gestellt.

Und der nächste Vorteil könnte auch im Microservice oder App-Service liegen, wenn es eine Webanwendung gibt, die mit einer Back-End-Datenquelle wie dem SQL-Server kommunizieren kann. Der SQL-Server ist also langsam. Es ist nicht etwas, das eine enorme Transaktionslast bewältigen kann. Als Reaktion darauf kann ein verteilter Cache mehrere Server haben, die linear skaliert und zu einer logischen Kapazität verbunden werden, richtig? So können Sie im Handumdrehen immer mehr Server hinzufügen. Und in Microsoft Azure ist es sehr einfach, das zu verwalten. Sie können einfach eine neue VM erstellen und Ihre Kapazität verdoppeln, wenn Sie immer mehr Caching-Server hinzufügen. Der Anwendungsfall für das Daten-Caching ist also zunächst der Arbeitsspeicher. Es ist also eine superschnelle Datenbankkapazität und außerdem eine sehr skalierbare Plattform, selbst in Microsoft Azure im Vergleich zu Ihrem Microsoft SQL-Server. Dies sind also zwei Vorteile, die Sie in den Microsoft Azure-App-Diensten und im Anwendungsfall von Microsoft erhalten. Sie müssen sich nur vorstellen NCache API-Aufruf und Sie fügen weiterhin Daten in einem Schlüsselwertpaar hinzu.

ASP.NET-spezifisches Caching

Der zweite Anwendungsfall ist spezifisch für Microsoft-Web-App-Dienste. Es bezieht sich auf ASP.NET-spezifisches Caching. Wenn Sie also einen App-Dienst haben, können Sie ihn verwenden NCache, mit dem Ihr App-Dienst kommuniziert NCache für Sitzungen sowie für die Ausgabe von Caching-Daten. Es kann übrigens auch die Objekt-Caching-API verwenden, da dieser Anwendungsfall auch für die ASP.NET-App-Dienste gilt. Ihr Sitzungsstatus ist also normalerweise Teil derselben App-Service-Instanz, die erfordert, dass Sie einen permanenten Sitzungslastenausgleich benötigen, oder er könnte Teil der Datenbank sein. In beiden Fällen, wenn es sich um eine Sticky-Session handelt, ist es begrenzt, wo Sie Sticky Load-Balancing haben müssen, was die Standardoption ist. Und dann wird es auf der Datenbankseite wieder langsam und dann ist es auch der Single Point of Failure.

Mit App-Diensten, mit NCache Als Sitzungsanbieter ist es zunächst einmal sehr skalierbar. Es ist extrem schnell und es gäbe keinen Single Point of Failure. Sitzungen werden serverübergreifend repliziert, sodass Sie hier einen Vorteil haben, wenn Sie die Verwendung eines verteilten Caches für Ihre ASP.NET-Anwendungen in Erwägung ziehen sollten. Und dann könnte dies auch eine Bereitstellung an mehreren Standorten sein, und das ist etwas, das ich heute ebenfalls behandeln möchte, wo wir eine an einem Standort bereitgestellte Anwendung mit Caching-Servern am selben Standort kommunizieren lassen und dann die Fähigkeit haben, zu kommunizieren auch zum Caching von Servern über die Site. Und ich werde hervorheben, welche Konfigurationen in Azure benötigt werden, aber das ist in Azure unmöglich NCache verteilte Caching-Angebote innerhalb von Microsoft Azure.

Der zweite Anwendungsfall betrifft das Caching der Ausgabe, richtig? Sie könnten also Ihre statischen Seiten in einem App-Dienst innerhalb einer als App-Dienst bereitgestellten Webanwendung verwenden. Wenn es statische Seiten gibt, cachen Sie den Inhalt dieser Seiten. Die gesamte Seitenausgabe kann zwischengespeichert werden, und Sie können diese Seitenausgabe das nächste Mal verwenden, wenn Sie auf dieselbe Seite zugreifen müssen. Das ist also ein weiterer Vorteil. Dies ist etwas, das ich in unserem typischen Webinar zur Leistung und Skalierbarkeit von ASP.NET behandle, in dem ich über vier verschiedene Möglichkeiten zur Optimierung der ASP.NET-Leistung spreche. Dasselbe Konzept würde also auf Microsoft Azure-App-Dienste angewendet, bei denen eine Webanwendung als App-Dienst bereitgestellt wird.

Freigabe von Pub/Sub- und Laufzeitdaten

Jetzt der dritte wichtige Anwendungsfall und das ist das Wichtigste, wenn es um Microservices geht. Obwohl es auch für App-Dienste gilt. Ihre App-Dienste müssen möglicherweise Daten teilen, wenn ein Anwendungsdienst mit einem anderen Anwendungsdienst kommuniziert, oder es können Daten sein, die zwischen zwei verschiedenen Anwendungen geteilt werden. Es gibt also Webanwendungen, die unterschiedlicher Natur sind, aber auf dieselben Daten angewiesen sind. Es könnte eine Berichterstattungsanwendung geben und es könnte einen Verbraucher davon geben, oder es könnte einen Produzenten in Bezug auf Produktkataloge geben, und dann gibt es eine andere Anwendung, die davon abhängig sein muss, sie muss einige Berichte basierend auf der ersten Anwendung generieren . Dieser Anwendungsfall erfordert also, dass Ihre Anwendungen Daten untereinander austauschen. Es gibt also keine Möglichkeit, die Datenbank zum Freigeben von Daten zu verwenden, aber das ist langsam und in einigen Fällen auch ein Single Point of Failure. Ein verteilter Cache ist sinnvoller, da Ihre Anwendungen in einem Client-Server-Modell eine Verbindung damit herstellen können. Mehrere Anwendungen können sich mit derselben Ebene und derselben Caching-Ebene verbinden und dann können sie dieselben Cache-Ressourcen verwenden und Zugriff auf dieselben Daten erhalten, und das ist etwas, das Sie aktivieren können.

Bei Azure-Microservices müssen wir es auf eine andere Ebene bringen. In Azure-Microservices sind diese zwar geclustert und ich habe bereits erwähnt, dass sie dort zustandsbehaftet und zustandslos sein können, richtig? Es könnte eine Anforderung geben, und das habe ich erwähnt, dass Ihre Microservices möglicherweise auch mit den Microservices interagieren müssen, richtig? Daher erfordert die Microservices-Architektur von Natur aus, dass Ihre Serviceinstanzen möglicherweise miteinander interagieren und dann möglicherweise Daten untereinander austauschen müssen. Und das ist eine sehr zentrale Anforderung in Bezug auf die Microservices-Plattform. Wir brauchen einfach mehrere Anwendungsinstanzen, die Daten untereinander austauschen. Ein Microservice sendet einige Daten und steht anderen Microservices-Instanzen zur Verfügung, wenn es sich um einen Zustandsbehafteten handelt oder Sie mehrere Anwendungen auf denselben Leitungen interagieren lassen könnten, aber innerhalb von zwei Microservices ist dies ein Muss und daher sind es viele Drittanbieter Bereitstellung von Datenfreigabe und Pub/Sub-Modell als Teil ihres Angebots, richtig?

Wenn es also in Microsoft Azure eine Anforderung gibt, bei der die Datenfreigabe gehandhabt werden muss, wenn eine Anwendung mit einem Geschäft kommuniziert und Daten enthält, die von einer anderen Anwendung oder einer anderen Microservice-Instanz benötigt werden, benötigen Sie eine Plattform, um dies zu handhaben und NCache bietet diese Plattform, auf der Daten zentral bereitgestellt werden. Es ist ein extrem schnelles Repository. Es ist extrem skalierbar, darüber hinaus können mehrere Microservice-Instanzen, verschiedene Dienste oder Instanzen derselben Dienste eine Verbindung zu diesem Cache herstellen und dann Datenfreigabefunktionen daraus nutzen. So stehen Daten schneller zentral zur Verfügung.

Dann haben wir ein themenbasiertes Pub/Sub-Modell. Wir haben eine Messaging-Plattform daraus. Eine Nachricht kann also gesendet werden, es könnten datengesteuerte Nachrichten sein, oder es könnten anwendungsgesteuerte Nachrichten oder themenbasierte Nachrichten sein, bei denen die Herstelleranwendung und das ist eine Instanz des Microservice, die Daten an den Cache sendet und diese Nachricht dann an alle Empfänger übermittelt wird auf dieser Teilnehmerseite. Und in ähnlicher Weise können die Abonnenten in einigen Fällen auch Produzenten sein. Sie könnten also Pub/Sub-Messaging zwischen mehreren Azure-Microservice-Instanzen verwenden. Es könnte sich auch um einen ereignisgesteuerten Datenaustausch zwischen mehreren Instanzen handeln. Und obendrein haben wir eine Ereignisbenachrichtigung und ein kontinuierliches Abfragesystem. Es könnte ein SQL-Befehl sein und darauf basierend können Sie wieder einen Datensatz definieren, gegen den Sie datengesteuerte Nachrichten erhalten können. Das ist also der Anwendungsfall, den Sie in Erwägung ziehen würden, den verteilten Microsoft Azure-Cache in Microsoft Azure-Microservices zu verwenden.

NCache Bereitstellungsszenarien in MS Azure

Dann werde ich auch über Azure-Webanwendungsdienste sprechen. Es ist einfacher, Webanwendungen in Microsoft Azure bereitzustellen.

Bereitstellungsszenarien

Gut. Also, jetzt haben wir zwei Arten von Szenarien richtig. Wir würden also alles in einer einzelnen Region an einem einzelnen Standort innerhalb derselben Ressourcengruppe oder vorzugsweise innerhalb desselben virtuellen Netzwerks bereitstellen, richtig? Also das habe ich schon besprochen NCache wird auf VMs in Microsoft Azure bereitgestellt, während Ihre Anwendungen entweder VMs sein können, die auf diese VMs zugreifen NCache oder dies könnten Azure-Dienste sein, und wir konzentrieren uns heute auf Azure-Dienste. VM-Fälle sind sehr typisch, wenn Sie eine VM erstellen, zum iAS gehen, Ihre Anwendung dort hosten und dann eine Verbindung mit Ihrer Anwendung herstellen NCache Verwendung von NCache APIs oder Sitzungsspeicheranbieter. Aber wenn es um Dienste geht, müssen Sie einige Netzwerkkonfigurationen vornehmen. Damit Ihr Service mit spricht NCache.

Wir haben also eine Bereitstellung an einem einzigen Standort, an dem Ihre Azure-Dienste und NCache werden in derselben Region am selben Standort bereitgestellt. Wenn Sie also Ihren Azure-Dienst bereitstellen, müssen Sie ihn an dieselbe Ressourcengruppe und auch an dasselbe virtuelle Netzwerk anfügen. Das ist also der empfohlene Ansatz. Sie würden keinen Vermittler benötigen. Es gäbe keine mehrfachen Sprünge, die die Dinge nicht verlangsamen würden. Das ist also das empfohlene Szenario für unsere Website.

Zweites Szenario, das ist auch ein sehr gültiges Szenario, dass Sie möglicherweise mehrere Standorte haben, richtig? Wir empfehlen dennoch, dass sich Ihr Cache und Ihre Anwendungen, Ihre Microservices-App-Dienste immer in derselben Region befinden, in der sie sich miteinander verbinden können sollten. Seit NCache ist ein TCP-IP-Protokoll. Es verwendet also IP-Adressen und Ports für die gesamte Kommunikation, und dies sind TCP-IP-Ports. Daher muss es so bereitgestellt werden, dass sich Ihre Anwendungen in der Nähe befinden. Sie werden in Kombination miteinander eingesetzt. Sie sind in der Nähe, es sind keine anderen Hopfen verfügbar. Daher empfehlen wir, dass Ihr Cache auf derselben Site bereitgestellt wird, auf der sich Ihre Anwendungen befinden, aber es könnte ein Szenario geben, in dem Sie Features für mehrere Sites verwenden. Wenn Ihre Anwendung möglicherweise mit dem Cache auf einer anderen Website kommunizieren muss oder Ihre Caches miteinander kommunizieren müssen. Wir brauchen also eine Standort-zu-Standort-Kommunikation, die zwischen ihnen stattfindet NCache .

Das ist also die Agenda, die ich über diese beiden Szenarien abdecken werde. Szenario 1 wird empfohlen, alles ist in den Singles näher an Ihrer Bewerbung. Szenario zwei ist, dass Sie möglicherweise mehrere Sites haben und Ihre Anwendung von Site eins mit den Caching-Servern auf Site zwei kommuniziert, oder es könnten Caching-Server sein. Beispielsweise könnten Sie für die WAN-Replikationsfunktion eine Brücke zwischen den Caches von Standort eins und Standort zwei einrichten.

Szenario 1: Einzelstandortbereitstellung für Azure-Dienste und NCache (Empfohlen)

Also, Einzelstandortbereitstellung für Azure-Dienste, ich werde einige detaillierte Schritte dazu behandeln. Ich werde über Anwendungsentwicklung sprechen, wie Sie vorstellen NCache Aufrufe innerhalb Ihrer Anwendung und wir verwenden dafür ein Serviceprojekt als Referenzbeispiel. In Ordnung. Dies ist also das Diagramm, das alle Details abdecken sollte, die ich in diesem Webinar behandeln möchte.

Single-Site-Bereitstellung-ncache-azurblau

Das habe ich bereits erwähnt NCache Server werden VMs in Microsoft Azure sein. Recht? Sie müssen sich also um das virtuelle Netzwerk kümmern, das diese VMs unterstützt, und dann NCache muss auf diesen installiert werden und dann Ihre Webanwendungen, die als App-Dienste bereitgestellt werden, es könnten API-Apps oder Microservice-Apps sein, richtig? Sie alle sind Dienstinstanzen. Ihnen liegen keine VMs zugrunde. Das bedeutet also auch, dass Sie nicht installieren können NCache Auf diesen Ressourcen müssen Sie dies als Teil der Anwendungsressourcen einschließen. Es gibt also NuGet-Pakete, die wir hervorheben werden. Gut! Wir haben also Web-Apps und dann haben wir API-Apps und es könnte auch Microservices und andere Apps geben.

Dies ist also eine typische Einzelstandortbereitstellung, bei der wir dasselbe virtuelle Azure-Netzwerk haben, das Ihre Anwendungen sowie das VMS von hostet NCache. Und was wir dabei wirklich tun, ist ein Point-to-Site-VPN zwischen Ihren Webanwendungen und Ihren Service-Apps und NCache Service. So sieht also die Gesamtvernetzung aus. Es ist Teil desselben virtuellen Netzwerks, in dem wir tatsächlich ein Dienstprojekt verwenden werden. Wir werden vorstellen NCache Ressourcen darin, erstellen wir serverseitige Ressourcen für NCache. Damit unsere VMs betriebsbereit sind, kehren wir einfach zur Anwendung zurück und hängen unsere Anwendung an dasselbe virtuelle Netzwerk an wie unsere NCache VMs sind vorhanden. Das würde es also nur zu einer einzigen Site machen und dasselbe virtuelle Netzwerk wie unser Caching-Service verwenden.

Schritte für die Bereitstellung an einem einzelnen Standort
Schritt 1 für die Bereitstellung an einem Standort: Erstellen Sie virtuelle Maschinen für NCache

Gehen wir also die Schritte mit diesen durch.

Singlesite-Schritt1

Gut! Der erste Schritt ist, dass Sie haben NCache Entweder serverseitig und warm eingerichtet, und das bedeutet eigentlich, virtuelle Azure-Maschinen einzurichten NCache und dieser Schritt ist für alle Arten von Bereitstellungen üblich, unabhängig davon, ob es sich um eine Bereitstellung an einem einzelnen Standort oder um eine Bereitstellung an mehreren Standorten handelt. Für die Bereitstellung an einem einzelnen Standort benötigen Sie lediglich Ihre NCache Server eingerichtet sind, sind sie VMs und dann NCache auf denen installiert ist. Ich leite Sie also schnell zu unserem Azure-Portal weiter, richtig? Und wenn ich einfach zu den Ressourcengruppen gehe, habe ich gerade eine Ressourcengruppe erstellt, lassen Sie mich sie einfach sortieren. Meine erste Ressourcengruppe ist die Demo-Ressourcengruppe eins, richtig? Und hier haben wir alle Arten von VMs, zum Beispiel haben wir Demo-VM eins und dann haben wir auch Demo-VM zwei, und tatsächlich habe ich dasselbe virtuelle Netzwerk verwendet, mein Fehler.. In Ordnung! Ich habe dasselbe virtuelle Netzwerk für diese beiden Demomaschinen verwendet.

Lassen Sie mich Ihnen kurz das zeigen. Lassen Sie es mich einfach hierher bringen. Gut! Also, wir haben Demo-VM eins, wenn Sie sich das ansehen, es wird in Westeuropa bereitgestellt, und dann haben wir Demo-VM zwei und dann gibt es noch eine Demo-VM v-net, richtig? Wenn ich darauf klicke, sehe ich Demo-VM 1 und Demo-VM 2 als Teil davon und das sind die IP-Adressen 10.4.0.4 und 10.4.0.5. Das repräsentiert also unsere beiden NCache VMs und wenn ich Sie hier schnell zu dieser Umgebung führe.

Also, was ich wirklich getan habe, ist, dass ich eine VM erstellt habe, ein leeres 2012- oder 2016-Image würde ausreichen, und dann bin ich zu unserer gegangen Alachisoft Website und alles, was Sie brauchen, es gibt kein spezielles Installationsprogramm für NCache. Sie müssen nur das vorhandene Installationsprogramm verwenden. Gehen Sie zur Download-Seite und laden Sie die 30-Tage-Testversion von herunter NCache von unserer Website und sobald Sie das getan haben, habe ich installiert NCache auf Demo-VM 1 und Demo-VM 2. Und dann habe ich auch einen Demo-V-Net-Cache erstellt. Die Schritte zur Cache-Erstellung sind sehr einfach. Sie müssen nur zum Demo-Cache gehen, die Caching-Topologie nehmen, asynchronisieren und Demo-VM 1 angeben, und dann sollte Demo-VM 2 die IP so wie sie ist auswählen. Ja tut es. Diese Server können also miteinander kommunizieren.

Ein zusätzlicher Schritt, den ich unternommen habe, wenn ich zur Präsentation zurückkomme, sind die Schritte, die zum Einrichten erforderlich sind NCache Dienst für Microsoft Azure. Sie erstellen ein virtuelles Azure-Netzwerk, richtig? Das ist etwas, das Sie möglicherweise bereits in Ihrer Umgebung haben. Und dann erstellen Sie VMs in diesen virtuellen Azure-Netzwerken. Sie könnten also einen dedizierten Satz von VMs haben NCache; Server eins Server zwei Server drei. Und dann stellen Sie sicher, dass Sie dieselben Subnetze beibehalten. Das ist etwas, das wir empfehlen, und dann installieren Sie es NCache auf all diesen VMs. Dann ist eine andere Sache, dass Sie öffnen NCache Ports für die Kommunikation. Es gibt zwei Arten von Ports, zwei Arten von Netzwerküberlegungen, die Sie berücksichtigen müssen. Einer ist, dass Sie die interne Firewall deaktivieren müssen, und dann sollten Sie in dem Netzwerk, in dem sich diese VMs befinden, eine Netzwerksicherheitsgruppe haben, richtig?

Also, zum Beispiel Demo-VM einer Netzwerksicherheitsgruppe, wir hätten diese Ports bereits geöffnet, richtig? Also, wenn ich euch das schnell zeige NCache Ports benötigen wir nur Port 9800 und 48250. Dies gilt sowohl für die eingehende als auch für die ausgehende Kommunikation. 9800 und 48250 Also, dies würde sicherstellen, dass jede Anwendung versucht, sie zu verwenden NCache, der Port 9800 verwendet, kann eine Verbindung zu diesen Caching-Servern und dann zu jeder Anwendung herstellen, die versucht, dies zu verwalten. Beispielsweise könnte es eine andere VM geben, die versucht, dies zu verwalten, und es könnte sich um ein übergreifendes virtuelles Netzwerk handeln, aber es ist Teil von derselben Ressourcengruppe, erlauben diese Netzwerksicherheitsgruppen, dass diese Kommunikation an diesen Ports stattfindet. Das war's. Das ist die Überlegung, die Sie haben müssen.

Ich habe die Firewall auf den Caching-Servern selbst ausgeschaltet. Und diese Ports sind offen und ich habe gerade einen Cache erstellt und kann die Statistiken sehen. Ich kann einfach eine Stresstest-Tool-Anwendung direkt auf diesen Computern ausführen, und ich kann schnell, es gibt ein bisschen Verzögerung, also haben Sie bitte etwas Geduld mit mir. Und ich kann auch einfach etwas Stress auf diese simulieren. Wir haben also einen Cache für Vnet, und wir führen einfach die Aktivität auf diesen beiden Caching-Servern aus und simulieren sie. So einfach ist die serverseitige Einrichtung also. Jetzt müssen Sie zu Ihrer Bewerbung zurückkehren und sich diese ansehen. Ja! da gehst du. Es kommen also Aktivitäten herein. Wir sind also gut. Ich werde das einfach schließen.

Schritt 2 für die Bereitstellung an einem Standort: Stellen Sie den Azure-Dienst in der Umgebung bereit

Als Nächstes habe ich jetzt, da wir virtuelle Maschinen konfiguriert haben, auch einen Cache-Cluster erstellt. Als Nächstes brauche ich eine Webanwendung, die mit diesem Cache-Cluster kommunizieren kann, richtig? Also komme ich gleich hier auf meine Präsentation zurück, richtig?

Singlesite-Schritt2

Was Sie also vom Standpunkt Ihrer Anwendungen aus wirklich brauchen, ist eine Point-to-Site-Netzwerkkonfiguration zwischen Ihrer Anwendung und Ihrem App-Dienst NCache. Also erstmal habe ich das schon gemacht, oder? nur um das hervorzuheben. Wenn Sie jetzt zur Ressourcengruppe zurückkehren, haben wir die Demo-Ressourcengruppe 1. Also haben wir das Demo-Gateway für virtuelle Netzwerke, richtig? Wir haben dafür ein Gateway geschaffen, richtig? Und dann haben wir einen Punkt vor Ort. Dies ist ein virtuelles Netzwerk-Gateway, das Demo-V-Net verwendet, das ist das Hauptnetzwerk für unseren Caching-Dienst. Also, wenn ich hierher zurückkomme, wenn Sie sich dieses Diagramm ansehen, wird hier tatsächlich ein virtuelles Netzwerk-Gateway verwendet, das Teil dieses virtuellen Netzwerks ist, und dann werden meine Anwendungen, die ich in Kürze bereitstellen werde, einen Point-to-Site haben Kommunikation zwischen diesen stattfindet, sodass diese mit demselben virtuellen Netzwerk verbunden sind. Das ist die Anforderung von Microsoft Azure. Damit Ihr App-Dienst mit Ressourcen kommunizieren kann, die sich in einem virtuellen Netzwerk befinden, z. B. VMs, müssen Sie eine Point-to-Site-Einrichtung haben.

Also, komm gleich hierher zurück. Wir haben also eine Demo-Ressourcengruppe. Auch wenn ich Ihnen die Punkt-zu-Site-Konfigurationen zeige, lassen Sie mich gleich hierher kommen, wenn ich Ihnen die Punkt-Site-to-Site-Konfigurationen zeige, haben wir diese IP, die eine allgemeine IP für unsere App-Dienste ist. Sobald also ein App-Dienst bereitgestellt wird, klicken Sie darauf und fügen ihn dann an das entsprechende virtuelle Netzwerk an.

Ich komme also auf mein Projekt zurück, ich glaube, ich habe es nicht früher gezeigt, aber dies ist eine Beispielanwendung, die eine Service-App ist. Ich werde Ihnen zeigen, was benötigt wird. Wenn Sie also mit der rechten Maustaste darauf klicken, stehen Ihnen NuGet-Pakete für Microsoft Azure zur Verfügung.

Demo-Step1-Singlesite

So haben wir zum Beispiel Alachisoft.NCache.SDK. Diese sind bei uns privat erhältlich, oder? Diese statten Ihre Anwendungen mit allem aus NCache zeigt auf Ressourcen, weil es keine Installation von gibt NCache auf der Client-Seite. Typisch NCache Bereitstellung ist, dass Sie einen Client installiert haben, Sie haben einen Server installiert. Also, deckt es ab, oder? Aber bei Diensten ist es eine Instanz. Sie haben also keinen Zugriff auf die zugrunde liegende VM. In diesem Fall benötigen Sie also die NuGet-Pakete. Damit alle Ressourcen Teil davon sind, die Sie innerhalb der Anwendung benötigen. Das ist also das Nougat-Paket, das ich bereits installiert habe. Was es wirklich alles hinzugefügt hat NCache Client-Site-Bibliotheken, richtig? Es wurden also auch einige Konfigurationen hinzugefügt. Wir haben also client.ncconf, das ist die Hauptdatei, die sich mit jedem Cache verbindet.

Zum Beispiel habe ich bereits Einstellungen, um eine Verbindung zu einem V-Net-Cache herzustellen, der den Namen hat, und habe dann auch die internen IP-Adressen, um eine Verbindung zu diesen herzustellen. Als nächstes veröffentliche ich diese Anwendung und diese Anwendung sollte dann auf 10.4.0.4 für VM eins und 10.4.0.5 für VM zwei zugreifen können. Ich muss also sicherstellen, dass es einen Punkt zur Standortkommunikation gibt, an dem diese öffentlichen IPs für meine Anwendung zugänglich sind, nur dann wäre sie in der Lage, eine Verbindung mit diesem Cache herzustellen.

Um also auf die Anwendung zurückzukommen, zeige ich einige Cache-Aufrufe. In diesem MVC-Projekt haben wir also unseren Hauptcontroller, wo wir diese Cache-Instanz haben, und dann verwende ich die Cache-Instanz. Cache initialisieren. Lassen Sie mich einfach zu dieser Methode hier gehen. Das ist also die initialisierte Methode, NCache.initializeCache und dann rufen wir auch cache.insert auf, um ein Element hinzuzufügen, Cache.delete, um dieses Element zu löschen, cache.get, um das Element zurückzubekommen, und wenn ich mir nicht sicher bin, ob ich einen Lasttest durchgeführt habe, ja! Es gibt also eine andere Methode Ladetest, die tatsächlich Artikel lädt, tausend Artikel werden in den Cache geladen und diese werden dann ebenfalls abgerufen. Dies sollte sich also sowohl um die Hauptlogik als auch um unsere Anwendung kümmern.

Es gibt einige Ansichten, die ich Ihnen zeigen werde. Wir haben also auch delete, get, index und load test und diese werden einfach durch unsere Anwendung aufgerufen. Also, was ich tun werde, ist, dass ich diese einfach sein werde NCache Anrufe. Als Nächstes stelle ich dies also einfach in Microsoft Azure bereit. Ich habe also bereits alle Ressourcengruppen und Netzwerkkomponenten hier eingerichtet. Aber was Sie wirklich brauchen, ist, wenn es sich um eine Microsoft Azure-App handelt, erstellen Sie einfach einen neuen, Ihren Web-App-Namen basierend auf Ihrem Abonnement. Warten wir etwas ab. Damit es das Abonnement auswählt. Los geht's. Es wurde also automatisch Visual Studio Enterprise und dann die Ressourcengruppe ausgewählt. Ich habe nur vor, die Demo-Ressourcengruppe zu verwenden. Also, dass ich die Single-Site-Bereitstellung verwende. Es ist also Teil derselben Ressourcengruppe, und dann wähle ich den Serviceplan aus und wähle dann einfach „Erstellen“. Du könntest hier auch einfach neu eintragen. Also, dass sogar der Standort Westeuropa ist, okay? Wählen Sie dazu Okay und dann Erstellen und es wird automatisch damit begonnen.

Seitdem habe ich dies bereits getan. Als Nächstes gehe ich also einfach zu meiner Webkonfiguration, stelle sicher, dass sie den V-Net-Cache XNUMX verwendet, und in client.ncconf haben wir den V-Net-One-Cache. Diese Anwendung wird also auf derselben Site bereitgestellt. Dasselbe Ressourcengruppenende und dann füge ich es dem virtuellen Netzwerk hinzu, das Teil meiner ist NCache Server-VMs.

Um auf Microsoft Azure zurückzukommen, wenn ich gleich zur Ressourcengruppe XNUMX gehe, sollten wir diese Anwendung irgendwo haben. Los geht's! Wenn Sie darauf und dann auf das Netzwerkteil dieser Anwendung klicken, sobald sie bereitgestellt ist, richtig? So richtig! Sie gehen also zum Netzwerk, klicken darauf und schon ist es mit dem Demo-V-Net One verbunden, richtig? Das habe ich schon gemacht, oder? Also, in Ihrem Fall, nachdem Sie eine Punkt-zu-Standort-Verbindung zu Ihrem Gateway für virtuelle Netzwerke hergestellt haben, haben Sie eine Demo-Ressourcengruppe, richtig? Bringen Sie das hier zurück. Nachdem Sie also ein virtuelles Netzwerk erstellt haben, erstellen Sie einen Point-to-Site und dann wird diese App-Dienst-IP offengelegt. Nach der Bereitstellung Ihres App-Diensts müssen Sie ihn an das virtuelle Netzwerk anhängen, richtig? Das ist also etwas, das ein zusätzlicher Schritt ist, der genau hier benötigt wird. Also, meine Bewerbung, ich hoffe, sie ist geladen. Ich warte darauf, ja!

Jetzt lösche ich auf der Serverseite einfach den Inhalt und füge einfach ein Element ein. Erfolgreich im Cache hinzugefügt. Und Sie können einen Artikel darin sehen, ich werde ihn nur schnell besorgen. Es tut mir leid, dass ich Ihnen die Zähler nicht wirklich zeigen kann, aber es hat sie tatsächlich abgerufen und dann kann ich sie löschen, richtig? Da es also Teil desselben virtuellen Netzwerks ist, ist es im Vergleich viel schneller.

Jetzt werde ich nur einige Belastungstests simulieren. Ich werde einfach tausend Elemente hinzufügen, und Sie sollten eine Aktivität sehen. Los geht's, oder? Also Anfragen pro Sekunde und diese Elemente werden hinzugefügt und dann könnten Sie etwa 600 Elemente hier sehen, etwa 400 Elemente hier und dann werden diese Elemente nicht abgerufen. Das ist also eine typische Bereitstellung Ihrer Dienste, seien es Mikrodienste, App-Dienste, API-Apps oder jede Anwendung, die in einem Dienstmodell bereitgestellt wird. Sie müssen nur NuGet-Pakete einführen, um eine Punkt-zu-Site-Verbindung herzustellen NCache VMs, über die Ihr Netzwerk-Gateway und dann Ihre Anwendungsinstanz an die VM angehängt werden können. Dies sind also alles Microsoft Azure-Netzwerkkonfigurationen und NCache Es müssen lediglich private IP-Adressen auf dem TCP-IP-Kanal offengelegt werden. Das ist alles, was wir brauchen.

Szenario 2: Bereitstellung an mehreren Standorten für Azure-Dienste und NCache

Da wir weniger Zeit zur Verfügung haben, denke ich, dass ich in den letzten 10 Minuten auch das Multi-Site-Szenario behandeln werde. Die Konfigurationen sind fast ähnlich.

Multi-Site-Bereitstellung-ncache-azurblau

Wir haben unsere Web-Apps oder Microsoft-Dienste oder App-Dienste in einem virtuellen Azure-Netzwerk oder an einem Standort bereitgestellt und dann NCache VMs oder einen anderen Standort und dafür brauchen wir wirklich ein lokales Netzwerk-Gateway hier und ein virtuelles Netzwerk-Gateway hier und dann brauchen wir eine Standort-zu-Standort-Verbindung zwischen diesen beiden. Auch dies sind wieder alles Microsoft Azure-Einstellungen, die zwei Seiten dazu ausstatten, sich über eine Site-to-Site-Verbindung miteinander zu verbinden und NCache verwendet diese und interne IPs werden auf jeder Seite abgebildet. Also dein NCache serverinterne IPs werden Ihrem virtuellen Netzwerk für Anwendungsdienste zugeordnet und wir umgekehrt.

Und dafür zeige ich euch schnell die Konfigurationen. Wenn ich Sie zurück zu den Ressourcengruppen bringe, haben wir die Demo-Ressourcengruppe zwei, richtig? Das ist also ein weiteres virtuelles Netzwerk. Und wir haben hier Demo-V-Netz zwei, und ich habe auch zwei Boxen in diesem virtuellen Netzwerk, Demo-VM 3 und Demo-VM 4. Diese Umgebung hier ist also 10. 4.0.4, das ist ein weiteres virtuelles Netzwerk. Es könnte auch standortübergreifend sein. Ich verwende nur die Analogie eines anderen virtuellen Netzwerks als einen anderen Standort. Es könnte sich jedoch um einen standortübergreifenden Standort handeln, es könnte sich um ein anderes Rechenzentrum in einer anderen Region in Microsoft Azure handeln.

Schritte für die Bereitstellung an mehreren Standorten: Bereitstellen des Azure-Diensts in der Umgebung

Was Sie also wirklich brauchen, ist, die gleichen Einstellungen dafür beizubehalten, wie ich bereits erklärt habe.

Schritte für die Multisite-Bereitstellung

Belassen Sie den VM-Teil im gleichen virtuellen Netzwerk und im gleichen Subnetz, erstellen Sie einen Cache, starten Sie diesen Cache und jetzt muss Ihre Anwendung eine Verbindung zu unserem standortübergreifenden Cache herstellen. Dafür benötigen Sie eine Standort-zu-Standort-Kommunikation. Und wenn ich hier auf diese Demo-Ressourcengruppe zurückkomme, da wir ein virtuelles Demo-Netzwerk und ein virtuelles Demo-Netzwerk-Gateway haben, ja, los geht's, virtuelles Netzwerk-Gateway 2, richtig? Das ist also ein Gateway auf der zweiten Seite. Wenn wir also zu den Verbindungen gehen, haben wir Demo 2 Site-to-Site-Verbindung. Wir haben also eine Standort-zu-Standort-Verbindung zum lokalen Netzwerk-Gateway Demo 2. Das ist also etwas, das ich konfiguriert habe, richtig? Dadurch kann sich mein virtuelles Netzwerk eins mit dem virtuellen Netzwerk zwei verbinden, das sich über den Standort hinweg befindet. Genau das haben wir also getan.

Ich zeige Ihnen nur schnell die NCache Anwendung, dass sich hier nichts ändert. Sie müssen nur den Namen des Caches ändern und dann sollten Sie die IP-Adressen haben, um sich mit den Caching-Servern zu verbinden, die ich als Teil des Stacks habe. Also, V-net zum Zwischenspeichern und ich werde dieselbe Anwendung verwenden, um jetzt eine Verbindung herzustellen, ich muss sie nur noch einmal veröffentlichen und feststellen, dass ich sie immer noch in der Demo-Ressourcengruppe 3 veröffentliche. Während sich unsere virtuellen Maschinen in der Demo-Ressourcengruppe zwei befinden. Und das ist die VM 1, genau hier, wo wir zwei Caching-Server haben. Also werde ich dies einfach noch einmal veröffentlichen und dabei eine bereits konfigurierte Site-to-Site-Verbindung beibehalten. Ich werde dies einfach veröffentlichen und dieselbe Anwendung würde nun über das Netzwerk, über den Standort vom virtuellen Netzwerk 2 zum virtuellen Netzwerk XNUMX gehen und eine Verbindung zu diesem herstellen können. Also werde ich einfach warten, bis es veröffentlicht wird, und dann komme ich genau hierher zurück und zeige Ihnen das Networking-Stück noch einmal.

Was Sie also wirklich brauchen, ist das gleiche Setup für virtuelle Maschinen, behalten Sie hier das gleiche virtuelle Netzwerk, das gleiche Subnetz, erzeugen Sie das VMS, installieren Sie es NCache Deaktivieren Sie auf ihnen die Firewall, richten Sie die Netzwerksicherheitsgruppe so ein NCache Ports offen sind und Sie dann eine Site-to-Site-Verbindung zwischen Ihren Anwendungen als Dienste benötigen, um eine Verbindung herzustellen NCache Service. Wenn Sie also bereits über ein virtuelles Netzwerk verfügen, an das Ihre App-Dienste angeschlossen sind, müssen Sie nur sicherstellen, dass das virtuelle Netzwerk 1 jetzt mit dem virtuellen Netzwerk 2 kommunizieren kann, und dann dort standortübergreifend, und genau das habe ich getan auch in Microsoft Azure. Die Veröffentlichung war also erfolgreich. Ich denke, das war es. Lassen Sie mich es einfach schließen und ein Element einfügen, okay? Und mal sehen, ob dort ein Artikel hinzugefügt wurde. So, jetzt wurde Artikel hinzugefügt. Also, jetzt spricht es über die Site, von einer Site zur anderen, und wenn ich dann diesen Artikel bekomme, wird er einfach abgerufen. Wenn ich es lösche, würde dieses Element von meiner Demo-VM 3 verschwinden, es sind keine Elemente vorhanden, und ähnlich simuliere ich nur einen Lasttest, bei dem ich anfange, dieselbe Umgebung zu verwenden, aber ich simuliere nur einige Aktivitäten es.

Also, jetzt sprechen meine Seite eins, App-Dienste mit dem Cache-Dienst von Seite 2. Sie gehen über das Gelände. Es ist kein empfohlenes Szenario, da es eine WAN-Replikation oder WAN-Latenz gibt, die Teil davon werden kann. Wir empfehlen daher, alles auf derselben Website zu belassen, aber es ist möglich, dass es ein Szenario gibt, in dem Ihre Sitzungsfunktion auf mehreren Websites basiert, z. B. auf der Grundlage der Banneranwendungsfunktion von NCache. Könnte sein, dass On-Premise-Anwendungen mit Azure kommunizieren oder Azure-Anwendungen umgekehrt mit einer Prämisse kommunizieren. Das sind also die Anforderungen und unser Belastungstest ist jetzt auch abgeschlossen, so dass er erfolgreich ausgeführt wurde.

Das deckt also unsere Azure-Bereitstellung ab.

Verteilte Caching-Optionen für .NET

Ein paar Dinge, die ich an dieser Stelle erwähnen möchte, ist und bleibt ein Redis Vergleich auch.

verteilte-caching-optionen

Wir sprechen von Azure. Also, wir werden auf jeden Fall darüber sprechen Redis. Es ist also auf unserer Website verfügbar. NCache ist zu 100 % .NET. Es ist in Cis entwickelt. Es wird vollständig für.NET und Java unterstützt. Im Vergleich, Redis Hinter den Kulissen ist auf Linux, Sie haben keine Kontrolle über das VMS. In NCache Sie haben die volle Kontrolle über das VMS. Sie können serverseitigen Code ausführen NCache sowie die Microsoft-Version einer Windows-Version von Redis ist nicht, dass Sie stabil wissen. Es ist die Linux-Version, die hinter den Kulissen verwendet und dann als Dienstmodell bereitgestellt wird. Und dann, NCache kann auch auf Dockers verwendet werden. Wenn Sie vorhaben zu verwenden NCache Auf den serverseitigen Dockers-Containern könnten Sie das verwenden.

Und dann werde ich auch über einige Details in Bezug auf Bereitstellungsoptionen sprechen. Sie installieren einfach NCache Server-Teil erhalten Sie eine Azure-Version von unserer Seite. Es ist ein reines Server-Release und dann benötigen Sie die NuGet-Pakete, um Ihre Anwendungen damit auszustatten NCache und das können Sie auch bei unserem Support- oder Vertriebsteam erfragen. Das ist also etwas, das nicht öffentlich verfügbar ist. Das ist beabsichtigt, aber Sie müssen uns nur anfordern, und dann stellen wir Ihnen die Version für Azure sowie die NuGet-Pakete zur Verfügung, und danach ist es nur das Netzwerkelement, das Sie für die Einrichtung einer einzelnen Site oder einer Einrichtung für mehrere Sites benötigen. In der Regel empfehlen wir einen einzelnen Standort, und in diesem Fall benötigen Sie eine Punkt-zu-Standort-Kommunikation, und bei mehreren Standorten benötigen Sie eine Standort-zu-Standort-Kommunikation.

Damit ist unsere Präsentation abgeschlossen.

Was macht man als nächstes?

 
© Copyright Alachisoft 2002 - Alle Rechte vorbehalten NCache ist eine eingetragene Marke der Diyatech Corp.