Cloudcache

Der Windows Azure AppFabric Caching-Dienst

Karandeep Anand

In einer Welt, in der Geschwindigkeit und Skalierbarkeit die wesentlichen Erfolgsmetriken jeder Lösung sind, können diese Metriken nicht im Nachhinein einer Anwendungsarchitektur hinzugefügt werden. Geschwindigkeit und Skalierbarkeit müssen bereits beim Entwurf der Lösungsarchitektur auf dem Whiteboard die wesentlichen Entwurfsprinzipien sein.

Der Windows Azure AppFabric Caching-Dienst stellt die notwendigen Komponenten für die Vereinfachung dieser Aufgaben bereit, ohne dass Sie sich über Bereitstellung und Verwaltung einer weiteren Schicht in Ihrer Anwendungsinfrastruktur Gedanken machen müssten. Der Cachingdienst ist, kurz gesagt, der elastische Speicher, den Ihre Anwendung zur Steigerung der Leistung und des Durchsatzes benötigt, indem die Belastung durch die Datenschicht und den verteilten Status beseitigt wird. Ihre Anwendung kann infolgedessen die Computingschicht leicht nach oben oder unten anpassen.

Der Cachingdienst wurde auf der Microsoft Professional Developers Conference 2010 als Community Technology Preview (CTP) veröffentlicht und wurde im Februar 2011 aktualisiert.

Der Cachingdienst ist ein wichtiger Bestandteil der Windows Azure-Plattform und baut auf den Platform-as-a-Service (PaaS)-Lösungen auf, die die Lösung bereits bereitstellt. Der Cachingdienst basiert auf der gleichen Codebasis wie Windows Server AppFabric Caching und stellt dem Entwickler daher eine Umgebung bereit, die symmetrisch zum lokalen Cache ist.

Der Cachingdienst bietet Entwicklern die folgenden Funktionen:

• Vorab entwickelte ASP.NET-Anbieter für das Zwischenspeichern von Sitzungsstatus und Seitenausgabe. Dies aktiviert die Beschleunigung von Webanwendungen, ohne dass der Anwendungscode modifiziert werden muss.
• Speichert alle verwalteten Objekte zwischen – keine Begrenzungen für die Objektgröße, kein Serialisierungsaufwand für das lokale Zwischenspeichern
• Kann leicht in vorhandene Anwendungen integriert werden.
• Konsistentes Entwicklungsmodell sowohl für Windows Azure AppFabric und Windows Server AppFabric.
• Sicherer Zugriff und sichere Autorisierung mithilfe des Zugriffssteuerungsdiensts.

Sie können zwar andere Cachingtechnologien (z. B. memcached) als Cloudinstanzen einrichten, müssten in diesem Fall die Cachecluster und Cacheinstanzen jedoch selbst installieren, konfigurieren und verwalten. Dies widerspricht einem der Hauptziele der Cloudtechnologie und insbesondere von PaaS: diese Details nicht mehr verwalten zu müssen. Der Windows Server AppFabric Caching-Dienst beseitigt diesen Aufwand für Sie und beschleunigt gleichzeitig die Leistung von ASP.NET-Webanwendungen, die in Windows Azure ausgeführt werden. Dabei sind nur wenige oder gar keine Konfigurationsänderungen erforderlich. Im Rest dieses Artikels zeigen wir Ihnen, wie dies durchgeführt wird.

Einblick in die Hintergründe

Da Sie nun wissen, dass das Caching eine strategische Entscheidung für das Design Ihrer Anwendung sein kann, betrachten wir den Cachingdienst etwas genauer. Lassen Sie uns ein Beispiel für eine typische Shopwebsite untersuchen: eine E-Commerce-Website, auf der Xbox- und PC-Spiele verkauft werden. Anhand dieser Website demonstrieren wir die verschiedenen Komponenten des Cachingdiensts.

Auf der Makroebene sind drei Teile in diesem Puzzle wichtig:

• Cacheclient
• Cachingdienst
• Verbindung zwischen dem Client und dem Dienst

Der Cacheclient ist der Proxy in der Anwendung, in diesem Fall in der Shopwebsite. Es ist der Teil des Codes, der mit dem Cachingdienst in einer Sprache kommuniziert, die von beiden Komponenten verstanden wird. Sie müssen diese Clientassembly in die Anwendung einschließen und mit der entsprechenden Konfiguration zusammen mit der Webanwendung bereitstellen, um den Cachingdienst finden und mit diesem kommunizieren zu können. (Wir behandeln dieses Prozess zu einem späteren Zeitpunkt in diesem Artikel.)

Da es einige häufige Anwendungsmuster gibt, wie z. B. den ASP.NET-Sitzungsstatus, für die das Zwischenspeichern direkt verwendet werden kann, gibt es zwei Möglichkeiten für die Verwendung des Clients.

Für die explizite Programmierung anhand der Cache-APIs integrieren Sie die Cacheclient-Assembly aus dem SDK in die Anwendung und beginnen mit der Durchführung von GET/PUT-Aufrufen, um Daten zwischenzuspeichern und aus dem Zwischenspeicher abzurufen. Dies ist eine gute Lösung, den Spielekatalog oder andere Referenzdaten für die Website zu speichern.

Für anspruchsvollere Szenarien, die den Zwischenspeicher verwenden, müssen Sie den ASP.NET-Sitzungsstatusanbieter für den Cachingdienst integrieren und mit den Sitzungsstatus-APIs und nicht mit den Caching-APIs interagieren. Der Sitzungsstatusanbieter übernimmt die Aufrufe der entsprechenden Caching-APIs, sodass der Sitzungsstatus weiterhin in der Cacheschicht verbleibt. Dies ist eine gute Lösung für das Speichern von Informationen im Sitzungsstatus wie Benutzereinstellungen, Warenkörben, Suchverläufe usw., ohne dass Sie eine einzige Codezeile schreiben müssen.

Sie können praktisch jedes Objekt im Zwischenspeicher halten: Texte, Daten, Blobs, CLR-Objekte usw. Es gibt auch keine Beschränkungen hinsichtlich der Größe der Objekte. Daher spielt die Objektgröße keine Rolle bei der Entscheidung, ob Sie den Cachingdienst in der Anwendung verwenden können, unabhängig davon, ob Sie explizite Objekte oder den Sitzungsstatus im Zwischenspeicher speichern.

Sie sollten beachten, dass es sich um einen expliziten Zwischenspeicher handelt, in den Sie schreiben und den Sie vollständig kontrollieren. Es handelt sich nicht um eine transparente Cacheschicht auf der Datenbank oder auf dem Speicher. Dies hat den Vorteil, dass Sie vollständig kontrollieren können, welche Daten im Zwischenspeicher gespeichert und verwaltet werden. Es bedeutet jedoch auch, dass Sie den Zwischenspeicher mittels der Cache-APIs als einen eigenen Datenspeicher programmieren müssen.

Dieses Muster wird in der Regel als „Cache-Aside“ (Zusatzchache) bezeichnet. Sie laden die Daten zunächst in den Cache, überprüfen anschließend, ob die gewünschten Daten für den Abruf verfügbar sind, und in den Fällen, in denen die gewünschten Daten nicht verfügbar sind, lesen Sie die Daten explizit in der Datenschicht. Als Entwickler müssen Sie daher das Programmiermodell für den Zwischenspeicher, die APIs sowie die allgemein bekannten Tipps und Tricks kennen, um die effiziente Nutzung des Zwischenspeichers zu ermöglichen.

Eine weitere Sache, die Sie in Bezug auf den Cacheclient wissen müssen, ist dessen Fähigkeit, direkt auf dem Client eine Teilmenge der Daten zwischenzuspeichern, die sich auf den verteilten Cacheservern befinden – in unserem Beispiel dem Webserver, auf dem die Shopwebsite ausgeführt wird. Dieses Feature wird häufig als lokaler Cache bezeichnet. Es wird mittels einer einfachen Konfigurationseinstellung aktiviert, mittels der Sie die Anzahl der Objekte angeben können, die gespeichert werden sollen, sowie die Timeouteinstellungen, um den Zwischenspeicher ungültig zu machen.

Das zweite wesentliche Teil in diesem Puzzle ist der Cachingdienst selbst. Stellen Sie sich den Cachingdienst so vor, dass Microsoft eine große Zahl von Cacheclustern für Sie ausführt, die in hohem Maß für Leistung, Betriebsbereitschaft, Stabilität und Skalierbarkeit optimiert sind und Ihnen als einfacher Netzwerkdienst mit einem Endpunkt bereitgestellt werden, den Sie aufrufen können. Der Cachingdienst ist ein hoch verfügbarer Multitenantdienst ohne Verwaltungsaufwand für die Benutzer.

Als Benutzer erhalten Sie einen sicheren Windows Communication Foundation (WCF)-Endpunkt, mit dem Sie kommunizieren, die nutzbare Speichermenge, die Sie für Ihre Anwendung benötigen, sowie APIs für den Cacheclient, den Sie für das Speichern und Abrufen von Daten verwenden. Der Schlüssel hier ist der nutzbare Speicher. Wenn Sie 1 GB Cachespeicher anfordern, erhalten Sie 1 GB nutzbaren Speicher, Ihre Objekte zu speichern, anders als im Fall der Speichermenge, die auf einer Windows Azure-Instanz verfügbar ist und die Sie kaufen. Der Cachingdienst übernimmt die Aufgabe, Speicher aus dem verteilten Computercluster zu poolen und Ihnen die nutzbare Speichermenge bereitzustellen, die Sie benötigen. Daher stellt der Dienst Ihnen auch die Flexibilität bereit, entsprechend Ihren Anforderungen an den Cache nach oben oder unten zu skalieren. Dies erfolgt mittels einer einfachen Änderung in der Konfiguration. Stellen Sie sich den Cachingdienst als einen virtuellen Pool von partitioniertem und freigegebenen Speicher vor, den Sie flexibel nutzen können.

Der andere Aspekt im Hinblick auf das interne Design besteht darin, dass der Cachingdienst Ihren Cache automatisch partitioniert, sodass Sie im Fall eines Ausfalls eines Computers keine Daten verlieren, auch wenn Sie die kostspieligere Hochverfügbarkeitsoption für den Cache nicht erworben haben. (Die Hochverfügbarkeitsoption ist zurzeit nicht in Windows Azure AppFabric Caching verfügbar und nur in Windows Server AppFabric Caching verfügbar.) Dieses Partitionierungsschema steigert die Leistung und reduziert automatisch die Wahrscheinlichkeit von Datenverlust, ohne dass Sie Informationen zum Back-End-Dienst benötigen.

Das dritte und letzte Teil des Puzzles ist die Verbindung zwischen dem Cacheclient und dem Cachingdienst. Die Kommunikation zwischen dem Cacheclient und dem Cachingdienst verwendet WCF, und das WCF-Programmiermodell ist vom Entwickler abstrahiert, da der Cacheclient GET/PUT-Aufrufe in ein WCF-Protokoll überträgt, die der Dienst versteht. Im Hinblick auf diesen Kommunikationskanal müssen Sie wissen, dass er sicher ist. Dies ist von äußerster Wichtigkeit, insbesondere in der Cloud. Der Cache wird mittels eines Access Control-Diensttokens geschützt. (Sie erhalten es, wenn Sie den benannten Cache erstellen.) Der Cachingdienst verwendet dieses Token, um den Zugriff auf die zwischengespeicherten Daten durch den Client zu beschränken.

Architekturanleitungen

Wir haben eine Menge Zeit mit Kunden verbracht, die über verschieden komplexe Anwendungen verfügen. Bevor wir die Designentscheidungen und die Architektur entwerfen, zeichnen wir in der Regel das einfache, in Abbildung 1 gezeigte Programm. In den meisten Fällen erfasst dieses Diagramm die Interaktionen zwischen den grundlegenden Elementen, die am Speichern und Bearbeiten von Daten beteiligt sind. (Eine Speicherexperten haben uns gesagt, dass sie die Anforderungen des Netzwerks erfüllen können, bevor sie den Festplattendurchsatz maximieren, daher verwenden wir den Ausdruck „in den meisten Fällen“.)

Abbildung 1 Speicher, Netzwerk und Festplattennutzung in Datenbearbeitungsszenarien

Das Grundprinzip ist, dass der Speicher auf dem lokalen Computer den schnellsten Datenzugriff und die niedrigste Latenz bereitstellt, jedoch auf die nutzbare Speichermenge auf dem lokalen Computer beschränkt ist. Wenn Sie mehr Speicher benötigen, als der lokale Computer bereitstellen kann, oder wenn Sie die Daten auf der lokalen Computerschicht externalisieren müssen (entweder für die Freigabe oder mehr Dauerhaftigkeit), müssen Sie zumindest den Netzwerksprung in Kauf nehmen. Die langsamste Lösung hier ist die Speicherung der Daten auf einer Festplatte (Solid-State-Festplatten helfen etwas, sind jedoch immer noch vergleichsweise teuer).

Die Festplatte ist der günstigste und größte Speicher, während der Arbeitsspeicher der teuerste Speicher ist. Daher unterliegt dieser im Hinblick auf die Kapazität den größten Beschränkungen. Der Cachingdienst gleicht die verschiedenen Elemente aus, indem der Dienst als Netzwerkdienst bereitgestellt wird. Dieser greift auf einen großen Vorrat an verteiltem und freigegebenem Speicher über mehrere Computingschichten hinweg zu. Gleichzeitig stellt er mittels des Features des lokalen Caches eine Optimierung bereit, sodass ein Teil der Daten zusätzlich auf dem lokalen Computer gespeichert wird und die komplexe Anforderung an die Bewahrung der Konsistenz zwischen dem lokalen Cache und der Cacheschicht im Dienst beseitigt wird.

Vor diesem Hintergrund betrachten wir nun einige Überlegungen zur Architektur in der Anwendung auf Makroebene.

Welche Daten sollten im Cache gespeichert werden? Die Antwort ist im erheblichen Maß vom allgemeinen Design der Anwendung abhängig. Wenn wir über Daten für Cachingszenarien sprechen, unterteilen wir diese in der Regel in die Datentypen und Zugriffsmuster, die in Abbildung 2 gezeigt werden (auf msdn.microsoft.com/library/ee790832 finden Sie eine detailliertere Erklärung dieser Datenzugriffsmuster).

Abbildung 2 Daten in Cachingszenarien

Datentyp	Zugriffsmuster
Referenz	Zum Lesen freigegeben
Aktivität	Nur schreiben
Ressource	Freigegeben, gleichzeitiger Lese- und Schreibzugriff, Zugriff durch eine große Zahl von Transaktionen

Wenn Sie dieses Modell für Überlegungen hinsichtlich Ihrer Daten verwenden, können Sie Kapazität und Zugriffsmuster planen (für die Verwaltung der Konsistenz, die Entfernung, Aktualisierungen usw.) und die Daten auf die am häufigsten verwendeten, die zeitkritischsten oder die von der Anwendung generierten Daten zu beschränken.

Beispielsweise sollten Referenzdaten in Daten, auf die häufig zugegriffen, und in Daten, auf die selten zugegriffen wird, unterteilt werden, um diese auf den Cache und den Festplattenspeicher aufzuteilen. Ressourcendaten sind ein klassisches Beispiel für Daten, die Sie weitestgehend im Cache speichern sollten, um maximale Skalierbarkeit und Leistung zu erzielen. Zusätzlich zur Cacheschicht orientiert sich sogar die Verwendung des lokalen Caches auf dem Client am Datentyp. Referenzdaten sind gute Kandidaten für die Speicherung im lokalen Cache oder die Kolozierung mit dem Client. In den meisten Fällen nehmen Ressourcendaten den Cache aufgrund häufiger Updates sehr in Anspruch und sollten daher am besten in der Cacheschicht gespeichert werden.

Die Netzwerkverkehrsmuster stellen die nach dem Arbeitsspeicher kostspieligste Komponente dar und bilden in der Regel den Engpass in den ineffizientesten Implementierungen. Daher sollten Sie diesen besondere Aufmerksamkeit widmen. Wenn Sie eine große Zahl kleiner Objekte haben, und Sie optimieren nicht für die Häufigkeit und die Anzahl der abgerufenen Objekte, wird die Anwendung schnell netzwerkabhängig. Die Verwendung von Tags für den Abruf von Daten oder die Verwendung des lokalen Caches, um eine große Zahl kleiner Objekte zu speichern, auf die häufig zugegriffen wird, sind eine gute Lösung.

Die Hochverfügbarkeitsoption für benannte Caches ist im Cachingdienst zwar noch nicht verfügbar, sollte jedoch ebenfalls beim Anwendungsentwurf berücksichtigt werden. Einige Entwickler und Architekten verwenden den Cache nur als vorübergehenden Speicher. Andere Entwickler und Architekten haben jedoch den Sprung gewagt und speichern einen Teil der Daten (in der Regel Aktivitätsdaten) ausschließlich im Cache, indem sie die Hochverfügbarkeitsoption aktivieren. Die Hochverfügbarkeitsoption hat keinen Kostenoverhead, stellt jedoch ein Entwurfsmodell bereit, das den Cache als den einzigen Datenspeicher behandelt. Damit wird die Notwendigkeit beseitigt, mehrere Datenspeicher zu verwalten.

Der Cache ist jedoch keine Datenbank! Diesen Punkt können wir nicht genug betonen. Die Hochverfügbarkeitsoption kann den Anschein erwecken, als ob der Cache die Datenschicht ersetzen könnte. Dies ist weit von der Wahrheit entfernt. Eine SQL-Datenbank ist für einen anderen Mustersatz als die Cacheschicht optimiert. In den meisten Fällen werden beide Elemente benötigt und können kombiniert werden, um die bestmögliche Leistung und die optimalen Zugriffsmuster bereitzustellen, während gleichzeitig die Kosten niedrig gehalten werden.

Kann der Cache für die Datenaggregation verwendet werden? Dies ist ein leistungsfähiges, jedoch häufig übersehenes Szenario. In der Cloud verarbeiten die Anwendungen häufig Daten aus verschiedenen Quellen, und die Daten müssen nicht nur gebündelt, sondern auch normalisiert werden. Der Cache bietet eine effiziente, hoch leistungsfähige Alternative für das Speichern und Verwalten dieser aggregierten Daten mit einer hohen Durchsatznormalisierung (im Arbeitsspeicher anstelle des Lesens und Schreibens auf der Festplatte), und die normalisierte Datenstruktur des Caches, der Schlüsselwertpaare verwendet, stellt eine gute Möglichkeit dar, wie Sie diese aggregierten Daten speichern und bereitstellen können.

Ein häufiges Problem, dem sich Entwickler und Architekten gegenüber sehen, besteht im Fehlen der Garantie, dass ein Client stets zu dem Server geleitet wird, der auch die vorherige Anforderung verarbeitet hat. Wenn diese Sitzungen nicht dauerhaft sein können, müssen Sie entscheiden, welche Daten im Sitzungsstatus gespeichert werden und wie die Anforderungen zwischen den Servern hin- und hergeleitet werden sollen, um das Fehlen dauerhafter Sitzungen auszugleichen. Der Cache stellt eine überzeugende Alternative zum Speichern eines freigegebenen Status über mehrere Computingknoten hinweg dar. (Diese Knoten wären in diesem Beispiel Webserver; die gleichen Probleme gelten jedoch für alle Szenarien mit freigegebenen Computingschichten.) Der freigegebene Status wird konsistent automatisch durch die Cacheschicht beibehalten, um den Zugriff für alle Clients zu ermöglichen. Gleichzeitig gibt es keinen Overhead und keine Latenz, die durch das Schreiben auf eine Festplatte entstehen würden (Datenbank oder Dateien).

Wenn Sie einen Zugriff auf den freigegebenen Status mit extrem niedriger Latenz benötigen (z. B. im Fall eines Sitzungsstatus auf einer Onlinegaming-Website, die Punktestände in Echtzeit aufzeichnet), müssen Sie daran denken, dass eine externe Cacheschicht möglicherweise nicht die beste Option ist. In den meisten anderen Szenarien stellt die Verwendung der Cacheschicht jedoch eine schnelle und leistungsfähige Lösung für die Behandlung dieses Entwurfsmusters dar. Dies beseitigt automatisch das Problem der Veraltung Ihrer Daten.

Stellen Sie sicher, dass Sie genügend Zeit mit der Planung der Kapazität Ihres Caches verbringen. Die Anzahl der Objekte, die Größe der einzelnen Objekte, die Häufigkeit des Zugriffs auf die einzelnen Objekte und die Zugriffsmuster sind alle nicht nur für die Entscheidung wichtig, wie viel Cache Sie für die Anwendung benötigen, sondern auch für die Entscheidung, für welche Schichten Sie optimieren müssen (lokaler Cache, Netzwerk, Cacheschicht, Verwendung von Regionen und Tags usw.). Denken Sie daran, dass Sie mit einem einfachen Konfigurationswechsel in der web.config-Datei beginnen können, um den Cache zu verwenden, ohne dass Sie eine einzige Codezeile schreiben müssen, und dass Sie Jahre damit verbringen können, eine Lösung zu entwerfen, die die Zwischenspeicherung auf effiziente Weise verwendet.

Einrichten von AppFabric Caching

Informationen zu den ersten Schritten mit dem Windows Azure AppFabric Caching-Dienst finden Sie auf portal.appfabriclabs.com. Dies ist das CTP-Portal, das Sie verwenden können, um sich mit dem Cachingdienst vertraut zu machen. Sie müssen keine Gebühren bezahlen, es gibt jedoch für diesen Dienst keine Service Level Agreements.

Wählen Sie im Portal die Cache-Option aus, und erstellen Sie anschließend durch Klicken auf „New Namespace“ (Neuer Namespace) einen neuen Zwischenspeicher. Das Dialogfeld für die Konfigurierung des Namespace für den Cachingdienst wird in Abbildung 3 gezeigt.

Abbildung 3 Konfigurieren eines neuen Namespace für den Cachingdienst

Die einzigen beiden Optionen, die Sie festlegen müssen, sind ein eindeutiger Namespace für den Dienst und die Größe des Caches (im CTP können Sie zwischen 128 MB und 256 MB wählen). Bei Auswahl von „OK“ stellt Ihnen der Dienst den Cache im Hintergrund bereit. Dies dauert in der Regel 10 bis 15 Sekunden. Nach Abschluss steht Ihnen ein voll funktionaler, verteilter Cache für Ihre Anwendungen zur Verfügung.

Nach der Erstellung können Sie die Eigenschaften des Cache betrachten, wie in Abbildung 4 gezeigt. (Beachten Sie, dass wir einige kontospezifische Informationen verdeckt haben.)

Abbildung 4 Eigenschaften des Cachingdiensts

Sie können sehen, dass wir einen Cache unter Verwendung des Namespace „CachingDemo“ erstellt haben. Es gibt einige wichtige Informationen, die Sie beachten sollten, da wir diese später in unserem Code verwenden werden: die Dienst-URL und das Authentifizierungstoken. Die Dienst-URL ist der TCP-Endpunkt, mit dem die Anwendung eine Verbindung herstellt, wenn sie mit dem Cachingdienst kommuniziert. Das Authentifizierungstoken ist ein verschlüsseltes Token, das Sie an Access Control übergeben, wenn Sie den Dienst authentifizieren.

Zwischenspeichern in der Anwendung

Bevor Sie mit dem Kodieren beginnen, müssen Sie den Windows Azure AppFabric SDK herunterladen. Diesen finden Sie unter go.microsoft.com/fwlink/?LinkID=184288, oder klicken Sie auf den Link im Portal.

Stellen Sie sicher, dass Windows Server AppFabric Cache noch nicht auf dem Computer installiert ist. Obwohl die API symmetrisch ist, sind die aktuellen Assemblys nicht kompatibel. Windows Server AppFabric Cache registriert die Cachingassemblys in Global Assembly Cache (GAC), sodass die Anwendung die falschen Assemblys lädt. Dies wird gelöst sein, wenn der Dienst verfügbar wird. Zurzeit jedoch verursacht dies einige Probleme.

Erstellen wir zunächst eine einfache Konsolenanwendung mittels C#. Stellen Sie im Anschluss an die Erstellung sicher, dass Sie das Projekt aktualisieren, sodass es das gesamte Microsoft .NET Framework und nicht nur das Clientprofil berücksichtigt. Sie müssen außerdem die Cachingassemblys hinzufügen. Diese finden Sie in der Regel unter C:\Program Files\Windows Azure AppFabric SDK\V2.0\Assemblies\Cache. Fügen Sie zu diesem Zeitpunkt diese beiden Assemblys hinzu:

• Microsoft.ApplicationServer.Caching.Client
• Microsoft.ApplicationServer.Caching.Core

Ein Unterschied zwischen der Oktoberversion des CTP und der Aktualisierung im Februar besteht darin, dass Sie nun System.Security.SecureString für das Authentifizierungstoken verwenden müssen. Der Zweck von SecureString besteht darin, zu verhindern, dass Sie das Kennwort oder das Token im Anwendungsspeicher speichern. Dies sorgt für einen besseren Schutz. Damit dies jedoch in einer einfachen Konsolenanwendung funktioniert, müssen Sie die folgende Methode erstellen:

static private SecureString Secure(string token) {
  SecureString secureString = new SecureString();
  foreach (char c in token) {
    secureString.AppendChar(c);
  }
  secureString.MakeReadOnly();
  return secureString;
}

Dies zwingt SecureString zwar, das Token in den Speicher zu laden, wird hier jedoch nur für dieses einfache Szenario verwendet.

Als Nächstes müssen Sie den Code schreiben, der die Interaktion mit dem Cachingdienst ermöglicht. Die API verwendet ein Factorymuster. Daher müssen wir die Factory definieren, einige Konfigurationseinstellungen festlegen und anschließend den voreingestellten Cache laden, wie in  Abbildung 5 gezeigt.

Abbildung 5Laden des voreingestellten Caches

private static DataCache configureDataCache(
  SecureString authorizationToken, string serviceUrl) {

  // Declare an array for the cache host 
  List<DataCacheServerEndpoint> server = 
    new List<DataCacheServerEndpoint>();
  server.Add(new DataCacheServerEndpoint(serviceUrl, 22233));

  // Set up the DataCacheFactory configuration
  DataCacheFactoryConfiguration conf = 
    new DataCacheFactoryConfiguration();
  conf.SecurityProperties = 
    new DataCacheSecurity(authorizationToken);
  conf.Servers = server;

  // Create the DataCacheFactory based on config settings 
  DataCacheFactory dataCacheFactory = 
    new DataCacheFactory(conf);

  // Get the default cache client 
  DataCache dataCache = dataCacheFactory.GetDefaultCache();

  // Return the default cache
  return dataCache;
}

Sie können sehen, dass wir einen neuen DataCacheServerEndpoint basierend auf einer Dienst-URL definiert haben (die wir bereitstellen werden), die auf den Port 22233 zeigt. Anschließend erstellen wir DataCacheFactoryConfiguration, übergeben das Authentifizierungstoken (dies ist ein SecureString) und legen dieses auf die Sicherheitseigenschaften fest. Damit können wir uns für den Dienst authentifizieren. An diesem Punkt ist es nur eine Frage der Konstruierung von DataCacheFactory, des Abrufs von DataCache basierend auf dem voreingestellten Cache und der Rückgabe des voreingestellten Caches.

Obwohl es nicht erforderlich ist, diese Logik in der eigenen Methode einzukapseln, hat dies für einige spätere Codeabschnitte Vorteile.

An diesem Punkt ist es vergleichsweise einfach, dies in der Main-Methode der Anwendung durchzuführen (siehe Abbildung 6).

Abbildung 6 Main-Methode der Konsolenanwendung

static void Main(string[] args) {
  // Hardcode your token and service url
  SecureString authorizationToken = 
    createSecureString("YOURTOKEN");
  string serviceUrl = "YOURCACHE.cache.appfabriclabs.com";

  // Create and return the data cache
  DataCache dataCache = 
    configureDataCache(authorizationToken, serviceUrl);

  // Enter a value to store in the cache
  Console.Write("Enter a value: ");
  string value = Console.ReadLine();

  // Put your value in the cache
  dataCache.Put("key", value);

  // Get your value out of the cache
  string response = (string)dataCache.Get("key");

  // Write the value
  Console.WriteLine("Your value: " + response);
}

Wir stellen der Anwendung das Authentifizierungstoken und die Dienst-URL zur Verfügung und übergeben diese an die configureDataCache-Methode, die die DataCache-Variable als den voreingestellten Cache festlegt. Von hier aus können wir Input von der Konsole abrufen, diesen im Cache speichern und anschließend Get für den Schlüssel aufrufen, sodass der Wert zurückgegeben wird. Dies ist ein einfacher, jedoch aussagekräftiger, Test für den Cache.

Die Einbeziehung des Tokens und der Dienst-URL in den Code ist keine ideale Lösung. Glücklicherweise stellt Ihnen das Portal XML bereit, das Sie in die app.config (oder web.config)-Datei einfügen können, und die APIs übernehmen alles Weitere.

Wählen Sie im Portal den Cache aus, und klicken Sie anschließend auf die Schaltfläche für die Anzeige der Clientkonfiguration. Anschließend wird ein Dialogfeld geöffnet, in dem die Konfigurations-XML bereitgestellt wird. Kopieren Sie den XML-Ausschnitt, und fügen Sie diesen in die Konfigurationsdatei ein. Das Endergebnis sieht wie Abbildung 7 gezeigt aus.

Abbildung 7 Clientkonfiguration

<?xml version="1.0"?>
<configuration>
  <configSections>
    <section 
      name="dataCacheClient" 
      type="Microsoft.ApplicationServer.Caching.DataCacheClientSection, Microsoft.ApplicationServer.Caching.Core" 
      allowLocation="true" 
      allowDefinition="Everywhere"/>
  </configSections>
  <dataCacheClient deployment="Simple">
    <hosts>
      <host 
        name="YOURCACHE.cache.appfabriclabs.com" 
        cachePort="22233" />
    </hosts>
    <securityProperties mode="Message">
      <messageSecurity
          authorizationInfo="YOURTOKEN">
      </messageSecurity>
    </securityProperties>
  </dataCacheClient>
</configuration>

Nun können wir den Code erheblich optimieren und die createSecureString- und configureDataCache-Methoden entfernen. Der Code sieht anschließend wie folgt aus:

static void Main(string[] args) {
  DataCacheFactory dataCacheFactory = 
    new DataCacheFactory();
  DataCache dataCache = dataCacheFactory.GetDefaultCache();
  Console.Write("Enter a value: ");
  string value = Console.ReadLine();
  dataCache.Put("key", value);
  string response = (string)dataCache.Get("key");
  Console.WriteLine("Your value: " + response);
}

Sie sehen, dass wir nur eine neue Instanz von DataCacheFactory erstellen müssen, und sämtliche Konfigurationseinstellungen in der app.config-Datei werden standardmäßig gelesen.

Wie Sie gesehen haben, können Sie die APIs direkt verwenden oder DataCacheFactory in Ihrer Konfiguration verwalten. Wir haben zwar nur PUT- und GET-Prozesse für einfache Daten verwendet, wir könnten jedoch auch Daten speichern, die aus SQL Azure, Windows Azure oder anderen Datenanbietern abgerufen wurden. Eine detailliertere Betrachtung der Verwendung des Caches für Referenzdaten, die in SQL Azure gespeichert sind, finden Sie in den praktischen Übungen für den Cachingdienst in der Schulung für die Windows Azure-Plattform msdn.microsoft.com/gg457894.

Speichern von Sitzungsdaten

Als Nächstes betrachten wir die Verwendung des Cachingdiensts für das Speichern von Sitzungsdaten für unsere ASP.NET-Webanwendung. Dies ist eine leistungsfähige Technik, da sie uns die Trennung des Sitzungsstatus vom Verarbeitungsspeicher der einzelnen Webclients ermöglicht. So wird es einfach, die Anwendungen über eine einzelne Instanz in Windows Azure hinaus zu skalieren.

Dies ist für Dienste wichtig, die keine Dauersitzungen unterstützen, wie Windows Azure. Es gibt keine Garantie dafür, dass einem Benutzer bei jeder Anforderung die gleiche Instanz bereitgestellt wird. Tatsächlich verwendet der Windows Azure-Auslastungsausgleich explizit das Prinzip des freien Platzes, sodass dem Benutzer wahrscheinlich eine neue Instanz bereitgestellt wird. Durch die Verwendung des Cachingdiensts für den Sitzungsstatus spielt es keine Rolle, welche Instanz dem Benutzer bereitgestellt wird, da alle Instanzen durch den gleichen Sitzungsstatusanbieter unterstützt werden.

Zunächst erstellen wir ein neues Windows Azure-Projekt und fügen eine ASP.NET-Webrolle hinzu. Fügen Sie in der Webrolle alle Assemblys hinzu, die vom Windows Azure AppFabric SDK bereitgestellt werden, wie:

• Microsoft.ApplicationService.Caching.Client
• Microsoft.ApplicationService.Caching.Core
• Microsoft.Web.DistributedCache
• Microsoft.WindowsFabric.Common
• Microsoft.WindowsFabric.Data.Common

Aktualisieren Sie als Nächstes die web.config file-Datei, sodass die ersten Elemente nach dem <configuration>-Element die <configSections>- und <dataCacheClient>-Elemente sind (Sie erhalten eine Fehlermeldung, wenn dies nicht die ersten Elemente sind).

Nun ist der Schlüssel zur Verwendung des Cachingdiensts für den Sitzungsstatus die Microsoft.Web.DistributedCache-Assembly. Diese enthält den angepassten Sitzungsstatusanbieter, der den Cachingdienst verwendet. Kehren Sie zum LABS-Portal zurück, in dem Sie den XML-Code für die Konfigurationsdateien erhalten haben, und suchen Sie das <sessionState>-Element. Dieses können Sie direkt im <system.web>-Element der web.config-Datei platzieren. Es wird die Anwendung umgehend anweisen, den Cachingdienst für den Sitzungsstatus zu verwenden:

<system.web>
  <sessionState mode="Custom" 
    customProvider="AppFabricCacheSessionStoreProvider">
    <providers>
      <add name="AppFabricCacheSessionStoreProvider"
        type="Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, Microsoft.Web.DistributedCache"
        cacheName="default"
        useBlobMode="false" />
    </providers>
  </sessionState>
  ...
</system.web>

Um zu überprüfen, dass dies funktioniert, öffnen Sie die Datei Global.asax.cs und fügen der Session_Start-Methode den folgenden Code hinzu:

void Session_Start(object sender, EventArgs e) {
  int i = 0;
  while (i < 10) {
    Session.Add(Guid.NewGuid().ToString(), DateTime.Now.ToString());
    i++;
  }
}

Dadurch werden dem Sitzungskontext 10 zufällig ausgewählte Elemente hinzugefügt. Als Nächstes öffnen Sie die Seite Default.aspx.cs und aktualisieren die Page_Load-Methode:

protected void Page_Load(object sender, EventArgs e) {
  foreach (var key in Session.Contents) {
    Response.Write("key: " + key + ", guid: " + 
      Session[key.ToString()].ToString()  + "<br/>");
  }
}

Damit werden alle Werte, die dem Sitzungskontext hinzugefügt wurden, herausgeschrieben. Öffnen Sie schließlich die Datei ServiceConfiguration.cscfg, und erhöhen Sie die Instanzenzahl von 1 auf 2:

<Instances count="2" />

Wenn Sie nun F5 drücken, erhalten Sie zwei Instanzen der Anwendung, die auf dem Computingemulator ausgeführt werden. Beachten Sie, dass es keine Rolle spielt, wie häufig Sie die Seite aktualisieren. Sie erhalten stets die gleichen 10 Werte im Sitzungszustand. Dies liegt daran, dass es sich um eine freigegebene Sitzung handelt, und der Sitzungsstart nur einmal ausgeführt wird. Wenn Sie umgekehrt den Cachingdienst nicht als Sitzungsstartanbieter verwenden, sondern sich für die voreingestellte Auswahl entscheiden, erhalten Sie für jede der Instanzen verschiedene Werte.

Ausblick

Windows Azure AppFabric Caching soll in der ersten Hälfte des Jahres für die geschäftliche Nutzung veröffentlicht werden. In der ersten veröffentlichten Version werden einige der Versionen, die in Windows Server AppFabric verfügbar sind, noch nicht verfügbar sein. Einige dieser Ausschlüsse sind beabsichtigt, da sie nicht auf die Cloud anwendbar sind. Features wie Benachrichtigungen sind jedoch auch für Windows Azure wichtig und spielen eine entscheidende Rolle für Szenarien mit lokalen Caches. Daher sind diese Bestandteil der kurzfristigen Roadmap von Microsoft. Auch die Hochverfügbarkeitsoption für benannte Caches stellt eine Premiumfunktionalität dar und befindet sich ganz oben auf der Prioritätenliste.

Die wachsende Verbreitung von Windows Server AppFabric Caching führte zu einer Reihe von Anforderungen für neue Funktionen, die Caching für eine noch größere Bandbreite von Szenarien ermöglicht. Zu den diskutierten Funktionen gehören die Fähigkeit, detaillierte Abfragen für den Cache durchzuführen und die Ermöglichung eines einfacheren Abrufs von Massendaten aus einem benannten Cache.

Außerdem führte der Erfolg der Szenarien mit Caching-Sitzungsstatusanbietern für ASP.NET zu Anforderungen hinsichtlich der Verknüpfbarkeit von Write-Behind- und Read-Through-Abfragen mit dem Cache, sodass der Cache die primäre Plattform für die Bearbeitung von Daten wird, während die verknüpften Abfragen die Datenschicht im Back-End aktualisieren.

Wir werden diese und weitere Features hinsichtlich ihrer möglichen Berücksichtigung für zukünftige Versionen von Windows Azure AppFabric Caching evaluieren. In der Zwischenzeit empfehlen wir Ihnen, mit der aktuellen Cachingdienst-Implementierung zu experimentieren und uns Ihre Erfahrungen mitzuteilen.

Karandeep Anand ist ein leitender Group Program Manager der AppFabric-Produktgruppe bei Microsoft. Sein Team ist für die Entwicklung der Anwendungsplattform der nächsten Generation sowie von Diensten für die Windows Azure-Plattform und für Windows Server verantwortlich. Sie erreichen ihn unter Karandeep.Anand@microsoft.com.

Wade Wegner ist technischer Evangelist bei Microsoft und für die Entwicklung und Förderung der technischen Strategie von Microsoft für die Windows Azure-Plattform mit verantwortlich. Sie erreichen ihn über seinen Blog unter  wadewegner.com oder auf Twitter unter twitter.com/WadeWegner.