Erweiterte Traffic-Verwaltung für Load-Balancing-APIs

Dieses Dokument richtet sich an Mesh-Netzwerk- oder Plattformadministratoren und Dienstentwickler, die mit den Konzepten von Cloud Service Mesh und Service Mesh vertraut sind und festlegen und konfigurieren, wie Traffic in einer Cloud Service Mesh-Bereitstellung verwaltet wird. Dieses Dokument bezieht sich nur auf die Load Balancing-APIs, nicht für die Service Routing APIs. Wenn Ihre Cloud Service Mesh-Bereitstellung die Service Routing APIs verwendet, finden Sie weitere Informationen unter Erweiterte Traffic-Verwaltung – Übersicht.

Cloud Service Mesh bietet erweiterte Funktionen zur Trafficverwaltung, mit denen Sie genau steuern können, wie Traffic verarbeitet wird. Cloud Service Mesh unterstützt die folgenden Anwendungsfälle:

  • Detailliertes Traffic-Routing von Anfragen an einen oder mehrere Dienste
  • Gewichtete Trafficaufteilung, um Traffic auf mehrere Dienste zu verteilen
  • Trafficspiegelungsrichtlinien, die Anfragen an einen bestimmten Debugging-Dienst und Kopien an einen anderen Dienst senden
  • Detaillierte Trafficverteilung auf den Back-Ends eines Dienstes, um das Load-Balancing zu optimieren

Mit diesen erweiterten Trafficverwaltungsfunktionen können Sie Ihre Verfügbarkeits- und Leistungsziele erreichen. Einer der Vorteile der Verwendung von Cloud Service Mesh für diese Anwendungsfälle besteht darin, dass Sie die Verwaltung des Traffics aktualisieren können, ohne Ihren Anwendungscode ändern zu müssen.

  • Wenn Sie den HTTP-Zielproxy zum Konfigurieren der Envoy-Proxys zum Senden von HTTP-Anfragen verwenden, sind alle Funktionen in diesem Dokument verfügbar.

  • Wenn Sie proxylose gRPC-Dienste oder Anwendungen mit Cloud Service Mesh verwenden, sind einige der Funktionen nicht verfügbar.

  • Wenn Sie den TCP-Zielproxy zum Konfigurieren der Envoy-Proxys zum Senden von TCP-Anfragen verwenden, ist keine der Funktionen verfügbar, da in Konfigurationen mit einem TCP-Zielproxy keine URL-Zuordnung vorhanden ist.

Weitere Informationen finden Sie auf der Seite "Features".

Für die Konfiguration der erweiterten Trafficverwaltung verwenden Sie dieselbe Routingregelzuordnung und Back-End-Dienstressourcen, die Sie auch beim Einrichten von Cloud Service Mesh verwenden. Cloud Service Mesh konfiguriert wiederum Ihre Envoy-Proxys und proxylose gRPC-Anwendungen, um die von Ihnen eingerichteten Richtlinien zur erweiterten Trafficverwaltung zu erzwingen.

Auf übergeordneter Ebene führen Sie diese Schritte aus:

  1. Konfigurieren Sie die Routingregelzuordnung so, dass sie anhand der Eigenschaften der ausgehenden Anfrage Folgendes ausführt:

    1. Wählen Sie den Back-End-Dienst aus, an den Anfragen weitergeleitet werden sollen.

    2. Führen Sie ggf. weitere Aktionen aus.

  2. Konfigurieren Sie den Backend-Dienst, um zu steuern, wie Traffic nach der Auswahl eines Zieldienstes an Backends und Endpunkte verteilt wird.

Konfiguration filtern

Eine der Hauptaufgaben von Cloud Service Mesh besteht darin, Konfigurationsinformationen aus der Weiterleitungsregel, dem Zielproxy und der URL-Zuordnung zu generieren und dann an Cloud Service Mesh-Clients wie Envoy-Proxys und gRPC-Anwendungen zu senden. Cloud Service Mesh steuert Ihr Service Mesh, indem es Konfigurationsinformationen an seine Clients sendet. Diese geben an, wie sie sich verhalten und wie Traffic weitergeleitet werden soll. Cloud Service Mesh ist die Steuerungsebene.

Wenn Sie Konfigurationsinformationen in Cloud Service Mesh erstellen oder aktualisieren, übersetzt Cloud Service Mesh diese Konfiguration in eine Sprache, die seine Clients verstehen. Standardmäßig teilt Cloud Service Mesh diese Konfiguration mit allen Clients. In einigen Fällen möchten Sie möglicherweise anpassen, welche Cloud Service Mesh-Clients bestimmte Konfigurationsinformationen erhalten. Mit anderen Worten, Sie filtern die Konfiguration nach bestimmten Clients.

Hierbei handelt es sich zwar um eine erweiterte Funktion, die folgenden Beispiele veranschaulichen, wann die Filterkonfiguration hilfreich sein kann:

  • Ihre Organisation verwendet das freigegebene VPC-Netzwerkmodell und mehrere Teams verwenden Cloud Service Mesh in verschiedenen Dienstprojekten. Wenn Sie Ihre Konfiguration von anderen Dienstprojekten isolieren möchten, können Sie die Konfiguration so filtern, dass bestimmte Cloud Service Mesh-Clients nur einen Teil der Konfiguration erhalten.
  • Sie haben in Cloud Service Mesh eine sehr große Anzahl von Routingregeln und Diensten konfiguriert und möchten vermeiden, dass eine ungewöhnlich große Menge an Konfigurationen an jeden Cloud Service Mesh-Client gesendet wird. Ein Client, der eine ausgehende Anfrage mithilfe einer großen, komplexen Konfiguration auswerten muss, ist möglicherweise weniger leistungsfähig als ein Client, der lediglich eine Anfrage mit einer optimierten Konfiguration auswerten muss.

Die Konfigurationsfilterung basiert auf dem Konzept der Metadatenfilter:

  1. Wenn ein Cloud Service Mesh-Client eine Verbindung herstellt, stellt er Informationen aus seiner Bootstrap-Datei für Cloud Service Mesh bereit.
  2. Diese umfassen den Inhalt von Metadatenfeldern in Form von Schlüssel/Wert-Paaren, die Sie in der Bootstrap-Datei angeben, wenn Sie Ihre Envoy-Proxys und gRPC-Anwendungen bereitstellen.
  3. Sie können Metadatenfilter auf die Weiterleitungsregel anwenden. Die gesamte mit der Weiterleitungsregel verknüpfte Konfiguration wird gefiltert.
  4. Sie können Metadatenfilter auf die URL-Zuordnung anwenden. Der Metadatenfilter wird nach Pfadrouting angewendet.
  5. Cloud Service Mesh teilt die Konfiguration nur mit Clients, die Metadaten präsentieren, die den Metadatenfilterbedingungen entsprechen.

Informationen zum Konfigurieren von Metadatenfiltern für Envoy finden Sie unter Konfigurationsfilter anhand der MetadataFilter-Übereinstimmung einrichten.

Trafficrouting und -aktionen

In Cloud Service Mesh bezieht sich die Routingregelzuordnung auf die Kombination aus den Ressourcen der Weiterleitungsregel, des Zielproxys und der URL-Zuordnung. Alle erweiterten Trafficverwaltungsfunktionen in Verbindung mit Routing und Aktionen werden über die URL-Zuordnung konfiguriert.

In den folgenden Abschnitten werden die erweiterten Features zur Trafficverwaltung beschrieben, die Sie in der Routingregelzuordnung einrichten können.

Anfragen verarbeiten

Wenn ein Client eine Anfrage sendet, wird sie wie in den folgenden Schritten beschrieben verarbeitet:

  1. Die Anfrage wird folgendermaßen mit einer bestimmten Routingregelzuordnung abgeglichen:

    • Wenn Sie Envoy verwenden:

      • Die IP-Zieladresse und der Zielport der Anfrage werden mit der IP-Adresse und dem Port der Weiterleitungsregeln in allen Routingregelzuordnungen verglichen. Es werden nur Routingregelzuordnungen berücksichtigt, die Weiterleitungsregeln mit dem Load-Balancing-Schema INTERNAL_SELF_MANAGED haben.
      • Die Weiterleitungsregel, die mit der Anfrage übereinstimmt, verweist auf einen HTTP- oder gRPC-Proxy, der wiederum auf eine URL-Zuordnung verweist. Diese URL-Zuordnung enthält Informationen, die für Routing und Aktionen verwendet werden.

    • Wenn Sie proxylose gRPC-Dienste verwenden:

      • Ein gRPC-Client, der das Namensauflösungsschema xds verwendet, führt keinen DNS-Lookup durch, um den Hostnamen im Kanal-URI aufzulösen. Stattdessen löst ein solcher Client den hostname[:port] im Ziel-URI durch Senden einer LDS-Anfrage an Cloud Service Mesh auf.
      • Nur der Port einer Weiterleitungsregel mit dem Load-Balancing-Schema INTERNAL_SELF_MANAGED wird mit dem Port im Ziel-URI verglichen (z. B. xds:///example.hostname:8080). Die IP-Adresse der Weiterleitungsregel wird nicht verwendet. Der Standardwert des Ports ist 80, wenn im Ziel-URI kein Port angegeben ist.
      • Die Weiterleitungsregel, die mit der Anfrage übereinstimmt, verweist auf einen Ziel-gRPC-Proxy, der wiederum auf eine URL-Zuordnung verweist. Diese URL-Zuordnung enthält Informationen, die für Routing und Aktionen verwendet werden.
      • Wenn mehr als eine Weiterleitungsregel mit der Anfrage übereinstimmt, wird die URL-Map, die die Hostregel enthält, die mit dem hostname[:port] im Ziel-URI übereinstimmt, für das Routing und die Aktionen verwendet.

  2. Wenn die entsprechende URL-Zuordnung festgelegt ist, wird die URL-Zuordnung ausgewertet, um den Ziel-Back-End-Dienst zu bestimmen und optional Aktionen anzuwenden.

  3. Nachdem der Ziel-Back-End-Dienst ausgewählt wurde, wird der Traffic basierend auf der Konfiguration in der Back-End-Dienstressource auf die Back-Ends oder Endpunkte für diesen Ziel-Back-End-Dienst verteilt.

Der zweite Schritt wird im folgenden Abschnitt Einfaches Routing nach Host und Pfad beschrieben. Der dritte Schritt wird unter Erweitertes Routing und erweiterte Aktionen beschrieben.

Einfaches Routing nach Host und Pfad

Cloud Service Mesh unterstützt ein vereinfachtes Routingschema und ein komplexeres Schema. Im einfachen Schema geben Sie einen Host und optional einen Pfad an. Der Host und der Pfad der Anfrage werden ausgewertet, um den Dienst zu bestimmen, an den eine Anfrage weitergeleitet werden soll.

  • Der Host der Anfrage ist der Teil einer URL mit dem Domainnamen. Der Hostteil der URL http://example.com/video/ lautet beispielsweise example.com.
  • Der Pfad der Anfrage ist der Teil der URL, der auf den Hostnamen folgt. Der Pfadteil der URL http://example.com/video/ lautet beispielsweise /video.

Sie richten ein einfaches Routing basierend auf Host und Pfad in der Routingregelzuordnung ein, die aus Folgendem besteht:

  • Globale Weiterleitungsregel
  • Ziel-HTTP-Proxy, Ziel-HTTPS-Proxy oder Ziel-gRPC-Proxy
  • Eine URL-Zuordnung

Der Großteil der Konfiguration erfolgt in der URL-Zuordnung. Nachdem Sie die erste Routingregelzuordnung erstellt haben, müssen Sie nur den URL-Zuordnungsteil der Routingregelzuordnung ändern. Im folgenden Diagramm haben die Pfadregeln ähnliche Aktionen wie im nächsten Diagramm.

Routing basierend auf Host- und Pfadressourcen
Routing auf Basis von Host- und Pfadressourcen (zum Vergrößern klicken)

Am einfachsten ist eine Standardregel, in der Sie nur eine Platzhalter-Hostregel (*) und ein Tool zum Abgleich von Pfaden mit einem Standarddienst angeben. Nachdem Sie die Standardregel erstellt haben, können Sie zusätzliche Regeln hinzufügen, mit denen verschiedene Hosts und Pfade angegeben werden. Ausgehende Anfragen werden folgendermaßen ausgewertet:

  • Wenn der Host einer Anfrage (z. B. example.com) mit einer Hostregel übereinstimmt:

    1. Das Tool zum Abgleich von Pfaden wird als Nächstes ausgewertet.
    2. Jedes Tool zum Abgleich von Pfaden enthält eine oder mehrere Pfadregeln, die hinsichtlich des Anfragepfads ausgewertet werden.
    3. Wird eine Übereinstimmung gefunden, wird die Anfrage an den in der Pfadregel angegebenen Dienst weitergeleitet.
    4. Wenn die Hostregel übereinstimmt, aber keine Pfadregeln übereinstimmen, werden Anfragen an einen Standarddienst weitergeleitet, den jedes Tool zum Abgleich von Pfaden enthält.

  • Stimmt die Anfrage mit keiner der von Ihnen angegebenen Hostregeln überein, wird sie an den in der Standardregel angegebenen Dienst weitergeleitet.

Weitere Informationen zu den Ressourcenfeldern der URL-Zuordnung und zu ihrer Funktionsweise finden Sie auf der Seite urlMaps REST API.

Erweitertes Routing und erweiterte Aktionen

Wenn Sie nicht nur eine Anfrage weiterleiten möchten, die auf dem Host und dem Pfad der Anfrage basiert, können Sie auch erweiterte Regeln einrichten, um Anfragen weiterzuleiten und Aktionen auszuführen.

Erweitertes Routing
Erweitertes Routing (zum Vergrößern klicken)

Auf übergeordneter Ebene funktionieren erweitertes Routing und erweiterte Aktionen so:

  1. Wie bei einfachem Routing wird der Host der Anfrage mit den Hostregeln verglichen, die Sie in der URL-Zuordnung konfigurieren. Wenn der Host einer Anfrage mit einer Hostregel übereinstimmt, wird das Tool zum Abgleich von Pfaden der Hostregel ausgewertet.
  2. Dieses Tool enthält eine oder mehrere Routingregeln, die anhand der Anfrage ausgewertet werden. Diese Routingregeln werden in der Reihenfolge ihrer Priorität ausgewertet. Dazu werden die Anfrageattribute (Host-, Pfad-, Header- und Abfrageparameter) nach bestimmten Abgleichsbedingungen abgeglichen, z. B. nach der Präfix-Abgleichsregel.
  3. Nachdem eine Routingregel ausgewählt wurde, können Sie Aktionen anwenden. Die Standardaktion besteht darin, die Anfrage an einen Zieldienst weiterzuleiten. Sie können aber auch andere Aktionen festlegen.

Erweitertes Routing

Das erweiterte Routing ähnelt dem oben beschriebenen einfachen Routing, mit der Ausnahme, dass Sie die Priorität von Regeln und zusätzliche Abgleichsbedingungen festlegen können.

Beim erweiterten Routing müssen Sie für jede Regel eine eindeutige Priorität angeben. Diese bestimmt die Reihenfolge, in der Routingregeln ausgewertet werden. Dabei haben Werte mit niedrigerer Priorität Vorrang vor höheren. Wenn eine Anfrage mit einer Regel übereinstimmt, wird die Regel angewendet und andere Regeln werden ignoriert.

Das erweiterte Routing unterstützt auch zusätzliche Abgleichsbedingungen. Sie können beispielsweise festlegen, dass eine Regel mit dem Header einer Anfrage übereinstimmt, wenn der Name des Headers genau oder nur teilweise übereinstimmt, z. B. anhand eines Präfixes oder Suffixes. Dabei können der Name des Headers mit einem regulären Ausdruck verglichen oder andere Kriterien herangezogen werden. Beispielsweise kann geprüft werden, ob ein Header vorhanden ist.

Weitere Abgleichsbedingungen und Details zu headerMatches und queryParameterMatches finden Sie auf der Seite urlMaps REST API.

Durch die Kombination von Host-, Pfad-, Header- und Abfrageparametern mit Prioritäten und Abgleichsbedingungen können Sie besonders ausdrucksstarke Regeln erstellen, die genau den Anforderungen Ihrer Trafficverwaltung entsprechen. Weitere Informationen finden Sie in der folgenden Tabelle.

HTTP-basierte Anwendung gRPC-basierte Anwendung
HTTP-Hosts im Vergleich zu gRPC-Hosts

Der Host ist der Teil einer URL mit dem Domainnamen, die von der Anwendung aufgerufen wird.

Der Hostteil der URL http://example.com/video/ ist beispielsweise example.com.

Der Host ist der Name, den ein Client im Kanal-URI verwendet, um eine Verbindung zu einem bestimmten Dienst herzustellen.

Der Hostteil des Kanal-URI xds:///example.com ist beispielsweise example.com.
HTTP-Pfade im Vergleich zu gRPC-Pfaden

Der Pfad ist der Teil der URL, der dem Hostnamen folgt.

Der Pfadteil der URL http://example.com/video lautet beispielsweise /video.

Der Pfad befindet sich im Header :path der HTTP/2-Anfrage und sieht so aus: /SERVICE_NAME/METHOD_NAME.

Wenn Sie beispielsweise die Methode Download für den gRPC-Dienst Example aufrufen, sieht der Inhalt des Headers :path so aus: /Example/Download.
Andere gRPC-Header (Metadaten) gRPC unterstützt das Senden von Metadaten zwischen dem gRPC-Client und dem gRPC-Server, um zusätzliche Informationen zu einem RPC-Aufruf bereitzustellen. Diese Metadaten liegen in Form von Schlüssel/Wert-Paaren vor, die als Header in der HTTP/2-Anfrage bereitgestellt werden.

Aktionen

Mit Cloud Service Mesh können Sie Aktionen angeben, die Ihre Envoy-Proxys oder proxylose gRPC-Anwendungen bei der Verarbeitung einer Anfrage ausführen. Die folgenden Aktionen können mit Cloud Service Mesh konfiguriert werden.

Aktion API-Feldname Beschreibung
Weiterleitungen urlRedirect Gibt einen konfigurierbaren 3xx-Antwortcode zurück. Außerdem wird der Antwortheader Location mit dem entsprechenden URI festgelegt, wobei der Host und der Pfad wie in der Weiterleitungsaktion angegeben ersetzt werden.
URL-Umschreibungen urlRewrite Überschreibt den Hostnamen-Teil der URL, den Pfad-Teil der URL oder beide, bevor eine Anfrage an den ausgewählten Back-End-Dienst gesendet wird.
Headertransformationen headerAction Fügt Anfrageheader hinzu oder entfernt diese, bevor eine Anfrage an den Back-End-Dienst gesendet wird. Außerdem können Antwortheader nach Empfang einer Antwort vom Back-End-Dienst hinzugefügt oder entfernt werden.
Traffic-Spiegelung requestMirrorPolicy

Zusätzlich zur Weiterleitung der Anfrage an den ausgewählten Back-End-Dienst auf Fire-and-Forget-Basis wird hierbei eine identische Anfrage an den konfigurierten Spiegel-Back-End-Dienst gesendet. Der Load-Balancer wartet nicht auf eine Antwort vom Back-End, an die die gespiegelte Anfrage gesendet wird.

Die Spiegelung ist hilfreich zum Testen einer neuen Version eines Back-End-Dienstes. Sie können die Spiegelung auch verwenden, um Produktionsfehler in einer Debugversion Ihres Back-End-Dienstes anstatt in der Produktionsversion zu beheben.
Gewichtete Trafficaufteilung weightedBackendServices

Lässt zu, dass Traffic für eine übereinstimmende Regel an mehrere Back-End-Dienste verteilt wird, proportional zu einer benutzerdefinierten Gewichtung, die dem einzelnen Back-End-Dienst zugewiesen ist.

Diese Funktion eignet sich zur Konfiguration abgestufter Bereitstellungen oder von A/B-Tests. Die Routingaktion könnte beispielsweise so konfiguriert werden, dass 99 % des Traffics an einen Dienst gesendet werden, der eine stabile Version einer Anwendung ausführt, während 1 % des Traffics an einen separaten Dienst mit einer neueren Version dieser Anwendung gesendet wird.
Neuversuche retryPolicy Konfiguriert die Bedingungen, unter denen der Load-Balancer fehlgeschlagene Anfragen wiederholt, die Wartezeit des Load-Balancers bis zum erneuten Versuch sowie die maximal zulässige Anzahl von Wiederholungen.
Zeitlimit timeout Gibt das Zeitlimit für die ausgewählte Route an. Das Zeitlimit wird vom Zeitpunkt der vollständigen Verarbeitung der Anfrage bis zur vollständigen Verarbeitung der Antwort berechnet. Das Zeitlimit umfasst alle Wiederholungen.
Fault Injection faultInjectionPolicy Kann Fehler bei der Bearbeitung von Anfragen einbringen, um Störungen zu simulieren, einschließlich hoher Latenz, Dienstüberlastung, Dienstfehlern und Netzwerkpartitionierung. Dieses Feature ist hilfreich, um die Ausfallsicherheit eines Dienstes gegenüber simulierten Störungen zu testen.
Sicherheitsrichtlinien corsPolicy Richtlinien für Cross-Origin Resource Sharing (CORS) verarbeiten die Einstellungen für die Erzwingung von CORS-Anfragen.

Weitere Informationen zu Aktionen und deren Funktionsweise finden Sie auf der Seite urlMaps REST API.

In jeder Routingregel können Sie eine der folgenden Routingaktionen angeben, die in der Google Cloud Console als "primäre Aktionen" bezeichnet werden:

  • Traffic an einen einzelnen Dienst weiterleiten (service)
  • Traffic auf mehrere Dienste aufteilen (weightedBackendServices)
  • Weiterleitungs-URLs (urlRedirect)

Darüber hinaus können Sie eine der zuvor genannten Routingaktionen mit einer oder mehreren der folgenden Routingaktionen kombinieren. Diese werden in der Cloud Console als Add-on-Aktionen bezeichnet:

  • Anfrage-/Antwortheader bearbeiten (headerAction)
  • Trafficspiegelung (requestMirrorPolicy)
  • URL-Host, -Pfad oder beides umschreiben (urlRewrite)
  • Fehlgeschlagene Anfragen wiederholen (retryPolicy)
  • Zeitlimit festlegen (timeout)
  • Fehler in einem Prozentsatz des Traffics einführen (faultInjectionPolicy)
  • CORS-Richtlinie hinzufügen (corsPolicy)

Da Aktionen mit bestimmten Routingregeln verknüpft sind, kann der Envoy-Proxy oder die proxylose gRPC-Anwendung je nach Anfrage, die verarbeitet wird, verschiedene Aktionen ausführen.

Traffic auf die Back-Ends eines Dienstes verteilen

Wenn ein Client eine ausgehende Anfrage verarbeitet, wird wie unter Anfragen verarbeiten beschrieben zuerst ein Zieldienst ausgewählt. Nachdem ein Zieldienst ausgewählt wurde, muss er herausfinden, welches Back-End oder welcher Endpunkt die Anfrage erhalten soll.

Traffic auf Back-Ends verteilen.
Traffic auf Back-Ends verteilen (zum Vergrößern klicken)

Im obigen Diagramm wurde die Regel vereinfacht. Die Regel ist häufig eine Hostregel, ein Tool zum Abgleich von Pfaden und mindestens eine Pfad- oder Routingregel. Der Zieldienst ist der Back-End-Dienst. Die Anfrage wird von Back-End 1, ... und Back-End n empfangen und verarbeitet. Diese Back-Ends können beispielsweise Compute Engine-VM-Instanzen sein, die Ihren serverseitigen Anwendungscode hosten.

Standardmäßig sendet der Client, der die Anfrage verarbeitet, Anfragen an das nächstgelegene fehlerfreie Back-End mit Kapazität. Um eine Überlastung eines bestimmten Back-Ends zu vermeiden, wird der Load-Balancing-Algorithmus Round-Robin verwendet, um nachfolgende Anfragen auf andere Back-Ends des Zieldienstes zu verteilen. In bestimmten Fällen muss dieses Verhalten jedoch genauer gesteuert werden.

Load-Balancing, Sitzungsaffinität und Schützen von Back-Ends

Sie können für jeden Dienst die folgenden Richtlinien zur Trafficverteilung festlegen.

Richtlinie API-Feldname Beschreibung
Load-Balancing-Modus balancingMode Steuert, wie eine Netzwerk-Endpunktgruppe (NEG) oder eine verwaltete Instanzgruppe (Managed Instance Group, MIG) ausgewählt wird, nachdem ein Zieldienst ausgewählt wurde. Sie können den Balancing-Modus so konfigurieren, dass die Last auf der Grundlage von gleichzeitigen Verbindungen und der Anfragerate verteilt wird.
Load-Balancing-Richtlinie localityLbPolicy Legt den Load-Balancing-Algorithmus fest, der zur Verteilung des Traffics auf Back-Ends innerhalb einer NEG oder MIG verwendet wird. Zur Optimierung der Leistung können Sie aus verschiedenen Algorithmen auswählen (z. B. Round-Robin oder Least-Request).
Sitzungsaffinität sessionAffinity

Bietet einen Best-Effort-Versuch, Anfragen von einem bestimmten Client an dasselbe Back-End zu senden, solange das Back-End fehlerfrei ist und Kapazität hat.

Cloud Service Mesh unterstützt vier Optionen für die Sitzungsaffinität: Client-IP-Adresse, HTTP-Cookie-basiert, HTTP-Header-basiert und Cookie-Affinität (die Cloud Service Mesh selbst generiert).
Konsistenter Hash consistentHash Stellt Soft-Sitzungsaffinität basierend auf HTTP-Headern, Cookies oder anderen Attributen bereit.
Schutzschalter circuitBreakers Legt Obergrenzen für die Anzahl von Verbindungen und Anfragen pro Verbindung zu einem Back-End-Dienst fest.
Ausreißererkennung outlierDetection Gibt die Kriterien an, um (1) fehlerhafte Back-Ends oder Endpunkte aus MIGs oder NEGs zu entfernen und (2) ein Back-End oder einen Endpunkt wieder hinzuzufügen, wenn es als fehlerfrei genug gilt, um Traffic zu empfangen. Die mit dem Dienst verknüpfte Systemdiagnose bestimmt, ob ein Back-End oder ein Endpunkt als fehlerfrei gilt.

Weitere Informationen zu den verschiedenen Optionen für die Trafficverteilung und zu ihrer Funktionsweise finden Sie auf der Seite backendServices REST API.

Fallbeispiele

Die erweiterte Trafficverwaltung deckt viele Anwendungsfälle ab. Dieser Abschnitt enthält einige allgemeine Beispiele.

Weitere Beispiele einschließlich Beispielcode finden Sie in den Anleitungen Erweiterte Trafficverwaltung konfigurieren und Proxylose gRPC-Dienste mit erweiterter Trafficverwaltung einrichten.

Detailliertes Traffic-Routing für die Personalisierung

Sie können Traffic anhand der Parameter der Anfrage an einen Dienst weiterleiten. Beispielsweise können Sie mit diesem Dienst Android-Nutzern ein personalisiertes Erlebnis ermöglichen. Im folgenden Diagramm konfiguriert Cloud Service Mesh Ihr Service Mesh so, dass Anfragen mit dem Header user-agent:Android an Ihren Android-Dienst und nicht an Ihren generischen Dienst gesendet werden.

Routing basierend auf dem User-Agent-Header, der auf Android gesetzt ist
Routing anhand des Headers user-agent, der auf Android festgelegt ist (zum Vergrößern klicken)

Gewichtete Trafficaufteilung für sicherere Bereitstellungen

Die Bereitstellung einer neuen Version eines bestehenden Produktionsdienstes birgt in der Regel ein gewisses Risiko. Auch wenn die Tests in einer Testumgebung erfolgreich sind, möchten Sie unter Umständen nicht sofort alle Nutzer an die neue Version weiterleiten.

Mit Cloud Service Mesh können Sie gewichtete Trafficaufteilungen definieren, um den Traffic auf mehrere Dienste zu verteilen. Sie können beispielsweise 1% des Traffics an die neue Version Ihres Dienstes senden, dessen Leistung überwachen und dann den Anteil des Traffics an den neuen Dienst nach und nach erhöhen.

Gewichtete Trafficaufteilung in Cloud Service Mesh
Gewichtete Trafficaufteilung für Cloud Service Mesh (zum Vergrößern klicken)

Trafficspiegelung für das Debugging

Wenn Sie ein Problem beheben möchten, kann es hilfreich sein, Kopien des Produktionstraffics an einen Debugging-Dienst zu senden. Mit Cloud Service Mesh können Sie Richtlinien für Anfragespiegelungen einrichten, sodass Anfragen an einen Dienst und Kopien dieser Anfragen an einen anderen Dienst gesendet werden.

Cloud Service Mesh-Trafficspiegelung
Cloud Service Mesh-Trafficspiegelung (zum Vergrößern klicken)

Optimiertes Load-Balancing für bessere Leistung

Je nach den Eigenschaften Ihrer Anwendung stellen Sie möglicherweise fest, dass Sie die Leistung und Verfügbarkeit verbessern können, wenn Sie die Verteilung des Traffics auf die Back-Ends eines Dienstes optimieren. Mit Cloud Service Mesh können Sie erweiterte Load-Balancing-Algorithmen anwenden, um Traffic nach Ihren Anforderungen zu verteilen.

Das folgende Diagramm zeigt im Gegensatz zu vorherigen Diagrammen sowohl einen Ziel-Back-End-Dienst (Produktionsdienst) als auch die Back-Ends für diesen Back-End-Dienst (Virtuelle Maschine 1, Virtuelle Maschine 2, Virtuelle Maschine 3). Mit der erweiterten Trafficverwaltung können Sie konfigurieren, wie ein Ziel-Back-End-Dienst ausgewählt und der Traffic zwischen den Back-Ends für diesen Zieldienst verteilt wird.

Cloud Service Mesh-Load-Balancing
Cloud Service Mesh-Load-Balancing(zum Vergrößern klicken)

Nächste Schritte