Wenn Ihre Microservices anfangen zu „stottern“, liegt das Problem möglicherweise an einem unsichtbaren Ort.

Stellen Sie sich Folgendes vor: Sie haben ein ziemlich gutes System mit klarer Arbeitsteilung zwischen Mikrodiensten aufgebaut, und es sollte so reibungslos funktionieren wie eine gut orchestrierte Symphonie. Aber ich weiß nicht, wann die Reaktionsgeschwindigkeit langsamer wurde, das Laden der Seite immer wieder im Kreis ging und gelegentlich mehrere Zeitüberschreitungsfehler auftraten. Sie haben den Code überprüft und die Containerspezifikationen erweitert, aber das Problem war wie ein Nebel, der sich für eine Weile auflöste und sich dann wieder sammelte.

Haben Sie zu diesem Zeitpunkt jemals darüber nachgedacht, dass der Engpass möglicherweise nicht in der Berechnung liegt, sondern darin, dass die Daten hin und her laufen?

Caching: Keine optionale Dekoration, sondern der verborgene Leistungsmotor

In der Welt der Microservices kommunizieren Dienste häufig miteinander. Bei einer Benutzeranfrage müssen möglicherweise fünf oder sechs Dienste einander bitten, die Antwort zu buchstabieren. Jede Anfrage ist eine Netzwerktour, eine Datenbankabfrage. Wenn der Verkehr zunimmt, wird die Straße verstopft.

Die Aufgabe des Caches ist eigentlich ganz einfach: Er speichert häufig gestellte Antworten vorübergehend an einem Ort, der näher am Anfragenden liegt. Wenn jemand das nächste Mal die gleiche Frage stellt, muss das System nicht mehr weite Strecken zurücklegen, um es zu überprüfen, sondern kann einfach die vorherige Antwort geben. Es ist, als hätte man in einem geschäftigen Büro einen öffentlichen Notizblock. Wer eine häufig verwendete Nummer nachschlagen muss, kann einfach einen Blick auf den Notizblock werfen, ohne jedes Mal ins Archiv rennen zu müssen.

Aber Caching in Microservices ist weit mehr als nur „einen Notizblock abzulegen“. Es muss entscheiden, was aufgezeichnet werden soll, wie lange es gespeichert und wann aktualisiert werden soll, und außerdem sicherstellen, dass die von mehreren Diensten angezeigten Daten konsistent sind. Gut gemacht, es ist ein Beschleuniger; Wenn es schlampig gemacht wird, wird es zu einer Quelle des Datenchaos.

Warum funktioniert Ihre Caching-Lösung möglicherweise nicht so gut, wie sie sollte?

Viele Leute dachten zunächst, dass es für das Caching nicht ausreichen würde, Redis oder Memcached hinzuzufügen? Aber als ich es tatsächlich benutzte, wurde mir klar, dass die Dinge nicht so einfach waren.

Zum Beispiel „Cache-Penetration“ – jemand fragt ständig Daten ab, die überhaupt nicht existieren und sich nicht im Cache befinden. Die Anfrage trifft jedes Mal auf die zugrunde liegende Datenbank und überlastet diese. Ein weiteres Beispiel ist die „Cache-Lawine“ – eine große Anzahl von Caches fällt gleichzeitig aus, alle Anfragen strömen sofort in die Datenbank und das System kann sofort lahmgelegt werden. Es gibt auch ein subtileres Problem der „Datenkonsistenz“: Dienst A aktualisiert die Daten, aber der Cache von Dienst B ist immer noch eine alte Version und die vom Benutzer angezeigten Informationen sind inkonsistent.

Der Grund für diese Probleme liegt häufig darin, dass die Caching-Strategie als nachträglich hinzugefügter Patch und nicht als Kernkomponente behandelt wird, die von Anfang an entwickelt wurde.

Eine Designidee, die stärker in die Textur integriert ist

Anstatt Caching als separates Plug-in zu behandeln, sollte es Teil der Art und Weise sein, wie Dienste miteinander kommunizieren. Bei einigen Anfragen ändert sich das Ergebnis kurzfristig nicht. Sie können es also ruhig zwischenspeichern. Für einige Daten ist eine kleine Verzögerung akzeptabel. Anschließend werden sie asynchron aktualisiert. Der Schlüssel besteht darin, während des Architekturentwurfs klar zu machen, welche Daten mit welcher Granularität für die Zwischenspeicherung geeignet sind und wie sie ordnungsgemäß ungültig gemacht und synchronisiert werden können.

Dafür bedarf es der Unterstützung durch Tools, aber auch eines Umdenkens. Tools sollen Ihnen bei der Umsetzung dieser Idee helfen und nicht zu neuer Komplexität führen.

Wie funktioniert es in einem realen Szenario?

Schauen wir uns ein häufiges Szenario an: Auf einer Produktdetailseite müssen Benutzerdienste, Inventardienste, Preisdienste, Bewertungsdienste usw. aufgerufen werden. Wenn keine Verarbeitung erfolgt, muss diese Anrufkette bei jedem Öffnen der Seite durchlaufen werden.

Was wäre, wenn eine vernünftige Caching-Schicht eingeführt würde? Benutzerinformationen können 12 Stunden lang, der Inventarstatus 30 Sekunden lang und Preise und Bewertungen 5 Minuten lang zwischengespeichert werden. Unterschiedliche Ablaufzeiten entsprechen unterschiedlichen Änderungshäufigkeiten von Daten. Die Ladezeit der Seite kann von Hunderten von Millisekunden auf mehrere zehn Millisekunden reduziert werden. Hinter dieser Änderung steht eine deutliche Reduzierung des Datenbankdrucks und eine Verbesserung der Gesamtsystemflexibilität.

Dies erfordert natürlich eine Feinabstimmung – welche Daten sind es wert, zwischengespeichert zu werden? Wie lange wird zwischengespeichert? Wie wird der Update-Mechanismus ausgelöst? Diese Entscheidungen basieren auf einem tiefen Verständnis der Geschäftslogik und nicht nur auf der technischen Konfiguration.

Wohin sollten Ihre Augen bei der Auswahl blicken?

Es muss leicht genug sein, damit der Einfügungsprozess nicht zu einer neuen technischen Katastrophe werden kann. Es ist besser, sich auf natürliche Weise in bestehende Entwicklungsprozesse einzufügen, als das Team neue komplexe Konzepte von Grund auf erlernen zu lassen.

Es beeinträchtigt den Geschäftscode weniger. Ingenieure sollten sich auf die Geschäftslogik selbst konzentrieren, anstatt viel Energie in die manuelle Verwaltung jeder Cache-Regel zu investieren. Dabei sind automatisierte und intelligente Invalidierungs- und Aktualisierungsmechanismen besonders wichtig.

Darüber hinaus ist die Beobachtbarkeit unerlässlich. Sie müssen klar erkennen können, wie hoch die Cache-Trefferquote ist, wie viele Anfragen gespeichert werden und welche Caching-Strategien am effektivsten sind. Transparenz kann echte Kontrolle bringen.

Es muss dem Test im realen Verkehr standhalten. Die Lösung selbst kann nicht zu einem neuen Single Point of Failure werden. Es muss hochverfügbar ausgelegt sein und unter Druck stabil bleiben können.

einen Schritt nach vorne machen

Wenn das System langsamer wird, möchten Benutzer instinktiv Hardware und Code aktualisieren. Das ist sicherlich wahr. Doch manchmal verbirgt sich der wirksamste Hebel im Kommunikationsmodell der Architektur. Durch die Einsparung von Daten unnötiger Fahrten und die Reduzierung von Doppelarbeit zwischen Diensten kann das Potenzial des Systems über Ihre Erwartungen hinaus freigesetzt werden.

Es geht nicht darum, eine coole Technologiekomponente hinzuzufügen, sondern darum, die Effizienz des Datenflusses noch einmal zu überprüfen. Wenn Sie beginnen, Caching nicht nur als Technologiewahl, sondern als Designphilosophie zu betrachten, werden sich die Antworten auf viele Engpässe möglicherweise ganz natürlich ergeben.

In der Welt der Microservices hängt die Geschwindigkeit oft nicht davon ab, wie schnell ein einzelner Dienst läuft, sondern davon, wie intelligent sie zusammenarbeiten. Die richtige Caching-Strategie ist der Teil, der diese Zusammenarbeit intelligenter und weniger arbeitsintensiv macht. Es ist nicht laut, aber wichtig.

Gegründet im Jahr 2005,kpowerist einem professionellen Hersteller kompakter Bewegungseinheiten mit Hauptsitz in Dongguan, Provinz Guangdong, China, gewidmet. Nutzung von Innovationen in der modularen Antriebstechnik,kpowerintegriert Hochleistungsmotoren, Präzisionsgetriebe und Multiprotokoll-Steuerungssysteme, um effiziente und maßgeschneiderte intelligente Antriebssystemlösungen bereitzustellen.kpowerhat weltweit über 500 Unternehmenskunden professionelle Antriebssystemlösungen mit Produkten geliefert, die verschiedene Bereiche abdecken, darunter Smart-Home-Systeme, automatische Elektronik, Robotik, Präzisionslandwirtschaft, Drohnen und industrielle Automatisierung.