Erweiterte Trafficverwaltung mit proxylosen gRPC-Diensten konfigurieren

Hinweis: Dieser Leitfaden unterstützt nur Cloud Service Mesh mit Google Cloud APIs und keine Istio APIs. Weitere Informationen finden Sie unter Cloud Service Mesh – Übersicht.

Diese Konfiguration wird für Vorschaukunden unterstützt, wir empfehlen sie jedoch nicht für neue Cloud Service Mesh-Nutzer. Weitere Informationen finden Sie unter Cloud Service Mesh-Dienst-Routing – Übersicht.

Dieses Dokument enthält Anleitungen zum Konfigurieren von Cloud Service Mesh mit den folgenden Funktionen zur Trafficverwaltung:

• Routenzuordnung
• Traffic-Teilung
• Schutzschaltung
• Fault Injection
• Maximale Streamdauer
• Wiederholen
• Sitzungsaffinität
• Ausreißererkennung
• Ort-Load Balancing

In diesem Dokument geht es hauptsächlich um die Einrichtung einer erweiterten Trafficverwaltung mit proxylosem gRPC in Compute Engine. Für die Verwendung von proxylosem gRPC in Google Kubernetes Engine (GKE) wird die erweiterte Trafficverwaltung ebenfalls unterstützt.

Hinweise

Bevor Sie die erweiterte Trafficverwaltung konfigurieren, lesen Sie die Anforderungen unter Einrichten von Cloud Service Mesh mit proxylosen gRPC-Diensten vorbereiten. Sie können die erweiterte Trafficverwaltung nur konfigurieren, wenn alle Anforderungen erfüllt sind.

Konzeptionelle Informationen zu diesen Features finden Sie unter Erweiterte Trafficverwaltung.

gRPC-Wallet-Beispiel

Stellen Sie ein gRPC-Wallet-Beispiel zur Verfügung, um diese Features zu veranschaulichen. In diesem Beispiel gibt es drei gRPC-Dienste, grpc.examples.wallet.Wallet, grpc.examples.wallet.stats.Stats und grpc.examples.wallet.account.Account, die als drei separate Anwendungen bereitgestellt werden.

Wie im folgenden Diagramm dargestellt, erstellen Sie einen gRPC-Client, der den Wallet-Dienst aufruft, um das Guthaben eines Kontos abzurufen, und den Stats-Dienst aufruft, um den Preis einer Münze zu erhalten. Der Wallet-Dienst ruft die Stats- und Account-Dienste auf, um das Guthaben zu berechnen. Der Stats-Dienst ruft auch den Account-Dienst auf, um Nutzerinformationen abzurufen.

Beispielkonfiguration für das Traffic-Routing von gRPC-Wallet (zum Vergrößern anklicken)

In diesem Beispiel stellen Sie zwei Versionen der Implementierungen Wallet und Stats bereit, um das Anfragerouting anhand der von Ihnen konfigurierten Regeln zu veranschaulichen. Wenn Sie das Erstellen und Bereitstellen verschiedener Versionen eines Dienstes simulieren möchten, verwenden Sie Server-Flags, um das Verhalten von Binärdateien zu ändern, die Sie nur einmal erstellen.

• Das Flag --port gibt den Port an, den der Dienst auf einer VM-Instanz überwacht.
• Das Flag --hostname_suffix gibt einen Wert an, der an den Hostnamen der VM-Instanz angehängt wird, die auf eine Anfrage antwortet. Der resultierende Wert wird als hostname-Metadaten in der Antwort hinzugefügt. So können Sie leichter feststellen, welche Instanz in einer Instanzgruppe auf die Clientanfrage reagiert hat.
• Das Flag --premium_only mit dem Wert true gibt an, dass der Dienst eine Premium-Version des Dienstes stats ist.
• Das Flag --v1_behavior mit dem Wert true gibt an, dass sich die Wallet-Binärdatei als Version V1 verhält.

In der folgenden Tabelle sind die Werte dieser Flags für jede VM-Instanz aufgeführt, die einen der gRPC-Dienste ausführt, die Anzahl der Instanzen in einer Instanzgruppe und die Backend-Dienste, zu denen diese Instanzgruppen gehören.

Note: For brevity, the common prefix and suffix in the names of the backend services and instance groups are not shown. Beispiel: Der Backend-Dienst grpcwallet-wallet-v1-service wird als wallet-v1 angezeigt.

Backend-Dienst	Instanzgruppe	Instanzen	Server-Flags
account	account	2	--port=50053 --hostname_suffix="account"
stats	stats	2	--port=50052 --hostname_suffix="stats" --account_server="xds:///account.grpcwallet.io"
stats-premium	stats-premium	2	--port=50052 --hostname_suffix="stats_premium" --account_server="xds:///account.grpcwallet.io" --premium_only=true
wallet-v1 wallet-v1-affinity	wallet-v1	2	--port=50051 --hostname_suffix="wallet_v1" --v1_behavior=true --account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io"
wallet-v2	wallet-v2	1	--port=50051 --hostname_suffix "wallet_v2" --account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io"

Nachdem Sie diese Dienste bereitgestellt haben, konfigurieren Sie Cloud Service Mesh so, dass Anfragen an diese Backend-Dienste von einem Testclient basierend auf den Routingregeln in der folgenden Tabelle weitergeleitet werden. Der Client stellt eine Verbindung zum virtuellen Hostnamen eines Dienstes her, wie in der Spalte "Host" gezeigt.

Hinweis: Der HTTP/2-:path-Pseudoheader in einer gRPC-Anfrage hat das Format /ServiceName/MethodName, wobei ServiceName der Name des gRPC-Dienstes ist, der in der gRPC-Anfrage aufgerufen wird, und MethodName die Methode in diesem Dienst ist.

Host	Übereinstimmungsregeln	Routingaktion
wallet.grpcwallet.io	Pfadpräfix: "/" Header vorhanden: "session_id"	Route zu „wallet-v1-affinity“
	Pfadpräfix: "/" Header: {"route": "timeout"}	Zeitlimit von 5 Sekunden und Route zu wallet-v2 festlegen
	Pfadpräfix: "/" Header: {"route": "fault"}	50 % der Anfragen fehlschlagen und Rest an wallet-v2 weiterleiten
	Pfadpräfix: "/" Header: {"membership": "premium"}	Weiterleiten an wallet-v1 und bei einem Fehler bis zu dreimal wiederholen
	Vollständiger Pfad: /grpc.examples.wallet.Wallet/FetchBalance	Route zu „ “ wallet-v1: 70 % wallet-v2: 30 %
	Standard	Route zu „wallet-v1“
stats.grpcwallet.io	Pfadpräfix: "/" Header: {"membership": "premium"}	Route zu „stats-premium“
	Standard	Route zu „stats“
account.grpcwallet.io	Pfadpräfix: "/" Header: {"route": "account-fault"}	30 % der Anfragen fehlschlagen und Rest an account weiterleiten
	Standard	account

In diesem Beispiel wird eine Trafficaufteilung von 70/30 zwischen zwei vorhandenen Diensten verwendet. Wenn Sie Traffic auf einen neuen Dienst aufteilen, auf den zuvor noch nicht durch die URL-Zuordnung verwiesen wurde, fügen Sie den neuen Dienst zuerst zu weightedBackendServices hinzu und weisen ihm eine Gewichtung von 0 zu. Erhöhen Sie dann schrittweise die Gewichtung, die diesem Dienst zugewiesen ist.

Der Testclient bietet die folgenden Optionen, mit denen Sie geeignete Anfragen generieren können, um die Features zur Trafficverwaltung zu veranschaulichen.

Option	Beschreibung
--watch=true	Streaming-Methoden aufrufen, um Guthaben/Preis zu beobachten
--unary_watch=true	Unäre Methoden wiederholt aufrufen, um Guthaben/Preis zu beobachten
--user=Alice	Header {"membership": "premium"} einfügen
--user=Bob	Header {"membership": "normal"} einfügen
--route=value	Header {"route": "value"} einfügen
--affinity=true	Header {"session_id": "value"} einfügen

Lokale Umgebung vorbereiten

Führen Sie die folgenden Befehle aus, um die lokale Umgebung für diese Beispiele einzurichten:

1. Aktualisieren Sie die Binärdatei gcloud, um sicherzustellen, dass Sie die neueste Version haben:

   gcloud components update
   

2. Laden Sie das Beispiel-Repository herunter:

   sudo apt-get install git -y
   

3. Klonen Sie das richtige Repository für das Beispiel:

   export EXAMPLES_VERSION=v1.1.x
   git clone -b $EXAMPLES_VERSION --single-branch --depth=1 \
     https://github.com/GoogleCloudPlatform/traffic-director-grpc-examples.git
   

Cloud Router-Instanzen erstellen und konfigurieren

In diesem Abschnitt erstellen Sie in jeder Region Cloud Router-Instanzen und konfigurieren sie für Cloud NAT. Die in diesem Beispiel erstellten VMs haben keine externen IP-Adressen, sie benötigen jedoch Zugriff auf das Internet. Die Konfiguration von Cloud Router mit Cloud NAT bietet den erforderlichen Zugriff.

gcloud

1. Erstellen Sie die Cloud Router-Instanzen:

   gcloud compute routers create nat-router-us-central1 \
       --network=default \
       --region=us-central1
   

2. Konfigurieren Sie die Router für Cloud NAT:

   gcloud compute routers nats create nat-config \
       --router-region=us-central1 \
       --router=nat-router-us-central1 \
       --nat-all-subnet-ip-ranges \
       --auto-allocate-nat-external-ips
   

gRPC-Systemdiagnose und Firewallregel erstellen

In diesem Abschnitt erstellen Sie eine gRPC-Systemdiagnose und eine Firewallregel, damit Anfragen zu gRPC-Systemdiagnosen Ihr Netzwerk erreichen. Später wird die gRPC-Systemdiagnose mit Backend-Diensten verknüpft, um die Integrität der Backend-Instanzen dieser Backend-Dienste zu prüfen.

gcloud

1. Erstellen Sie die Systemdiagnose:

   gcloud compute health-checks create grpc grpcwallet-health-check \
       --use-serving-port
   

2. Erstellen Sie die Firewallregel für die Systemdiagnose:

   gcloud compute firewall-rules create grpcwallet-allow-health-checks \
       --network default --action allow --direction INGRESS \
       --source-ranges 35.191.0.0/16,130.211.0.0/22 \
       --target-tags allow-health-checks \
       --rules tcp:50051-50053
   

Instanzvorlage erstellen

In diesem Abschnitt erstellen Sie eine Instanzvorlage, um den gRPC-Dienst account bereitzustellen, der über Port 50053 verfügbar gemacht wird.

gcloud

• Erstellen Sie die Instanzvorlage:

  gcloud compute instance-templates create grpcwallet-account-template \
     --scopes=https://www.googleapis.com/auth/cloud-platform \
     --tags=allow-health-checks \
     --network-interface=no-address \
     --image-family=debian-10 \
     --image-project=debian-cloud \
     --metadata-from-file=startup-script=<(echo "#! /bin/bash
  set -ex
  cd /root
  export HOME=/root
  sudo apt-get update -y
  pushd \$(mktemp -d)
  sudo apt-get install -y wget git
  wget https://dl.google.com/go/go1.16.5.linux-amd64.tar.gz
  sudo tar -C /usr/local -xvf go1.16.5.linux-amd64.tar.gz
  sudo cp /usr/local/go/bin/go /usr/bin/go
  popd
  git clone -b $EXAMPLES_VERSION --single-branch --depth=1 https://github.com/GoogleCloudPlatform/traffic-director-grpc-examples.git
  cd traffic-director-grpc-examples/go/account_server/
  go build .
  sudo systemd-run ./account_server --port 50053 --hostname_suffix account")
  

Verwaltete Instanzgruppe erstellen

Verwaltete Instanzgruppen (Managed Instance Groups, MIGs) verwenden Autoscaling, um bei Bedarf neue VM-Instanzen zu erstellen. In diesem Abschnitt erstellen Sie eine MIG mit der Instanzvorlage, die Sie im vorherigen Abschnitt erstellt haben.

gcloud

• Erstellen Sie die Instanzgruppe:

  gcloud compute instance-groups managed create grpcwallet-account-mig-us-central1 \
     --zone=us-central1-a \
     --size=2 \
     --template=grpcwallet-account-template
  

Benannten Port konfigurieren

In diesem Abschnitt konfigurieren Sie den benannten Port für den gRPC-Dienst. Der benannte Port ist der Port, den der gRPC-Dienst auf Anfragen überwacht. In diesem Beispiel lautet der benannte Port Port 50053.

gcloud

• Erstellen Sie den benannten Port:

  gcloud compute instance-groups set-named-ports grpcwallet-account-mig-us-central1 \
     --named-ports=grpcwallet-account-port:50053 \
     --zone=us-central1-a
  

Back-End-Dienst erstellen

In diesem Abschnitt erstellen Sie einen globalen Back-End-Dienst mit dem Load-Balancing-Schema INTERNAL_SELF_MANAGED und dem Protokoll GRPC. Anschließend verknüpfen Sie die Systemdiagnose und die Instanzgruppe mit dem Back-End-Dienst. In diesem Beispiel verwenden Sie die MIG, die Sie unter Verwaltete Instanzgruppe erstellen erstellt haben. Diese MIG führt den gRPC-Dienst account aus. Der Port im Flag --port-name ist der benannte Port, den Sie unter Benannten Port konfigurieren erstellt haben.

gcloud

1. Erstellen Sie den Back-End-Dienst und verknüpfen Sie die Systemdiagnose mit dem neuen Back-End-Dienst.

   gcloud compute backend-services create grpcwallet-account-service \
       --global \
       --load-balancing-scheme=INTERNAL_SELF_MANAGED \
       --protocol=GRPC \
       --port-name=grpcwallet-account-port \
       --health-checks=grpcwallet-health-check
   

2. Fügen Sie die verwaltete Instanzgruppe als Back-End hinzu:

   gcloud compute backend-services add-backend grpcwallet-account-service \
       --instance-group=grpcwallet-account-mig-us-central1 \
       --instance-group-zone=us-central1-a \
       --global
   

Die Schritte zum Erstellen der im gRPC-Wallet-Beispiel verwendeten verbleibenden Back-End-Dienste sind den obigen Schritten ähnlich. Sie erstellen die verbleibenden Dienste mit einem Shell-Skript. Das Skript stellt die folgenden Back-End-Dienste bereit:

• stats
• stats-premium
• wallet-v1
• wallet-v1-affinity
• wallet-v2

Führen Sie das Shell-Skript aus, mit dem die zusätzlichen Back-End-Dienste erstellt werden:

traffic-director-grpc-examples/scripts/create_service.sh go stats 50052 stats '--account_server="xds:///account.grpcwallet.io"'

traffic-director-grpc-examples/scripts/create_service.sh go stats 50052 stats-premium '--account_server="xds:///account.grpcwallet.io" --premium_only=true'

# This command creates wallet-v1 and wallet-v1-affinity backend services.
traffic-director-grpc-examples/scripts/create_service.sh java wallet 50051 wallet-v1 '--account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io" --v1_behavior=true'

traffic-director-grpc-examples/scripts/create_service.sh java wallet 50051 wallet-v2 '--account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io"'

Routingregeln erstellen

In diesem Abschnitt erstellen Sie eine URL-Zuordnung, mit der verschiedene Features zur Trafficverwaltung veranschaulicht werden. Die URL-Zuordnung gibt die virtuellen Hostnamen der Dienste in diesem Beispiel und die zugehörigen Routingregeln an. Weitere Informationen finden Sie unter Routingregelzuordnungen.

In der URL-Zuordnung geben die hostRules die virtuellen Hostnamen der Dienste im Beispiel an. Das sind die Namen, die ein Client im Kanal-URI verwendet, um eine Verbindung zu einem bestimmten Dienst herzustellen. Um beispielsweise eine Anfrage an den Dienst account zu senden, verwendet ein Client xds:///account.grpcwallet.io im Kanal-URI. Konfigurieren Sie in den hostRules einen hosts-Eintrag mit dem Wert account.grpcwallet.io.

Der mit einem hosts-Eintrag verknüpfte pathMatcher gibt den Namen eines pathMatcher an, der alle Routingregeln für diesen virtuellen Host enthält. Eine pathMatcher-Konfiguration besteht aus übereinstimmenden Regeln und entsprechenden Aktionsregeln, wie unter gRPC-Wallet-Beispiel beschrieben.

gcloud

Erstellen Sie die URL-Zuordnung:

export PROJECT_ID=$(gcloud config list --format 'value(core.project)')
export BS_PREFIX=projects/$PROJECT_ID/global/backendServices/grpcwallet

gcloud compute url-maps import grpcwallet-url-map << EOF
name: grpcwallet-url-map
defaultService: $BS_PREFIX-account-service

hostRules:
- hosts:
  - account.grpcwallet.io
  pathMatcher: grpcwallet-account-path-matcher
- hosts:
  - stats.grpcwallet.io
  pathMatcher: grpcwallet-stats-path-matcher
- hosts:
  - wallet.grpcwallet.io
  pathMatcher: grpcwallet-wallet-path-matcher

pathMatchers:
- name: grpcwallet-account-path-matcher
  defaultService: $BS_PREFIX-account-service
  routeRules:
  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: route
        exactMatch: account-fault
    priority: 0
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-account-service
        weight: 100
      faultInjectionPolicy:
        abort:
          httpStatus: 503
          percentage: 30

- name: grpcwallet-stats-path-matcher
  defaultService: $BS_PREFIX-stats-service
  routeRules:
  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: membership
        exactMatch: premium
    priority: 0
    service: $BS_PREFIX-stats-premium-service

- name: grpcwallet-wallet-path-matcher
  defaultService: $BS_PREFIX-wallet-v1-service
  routeRules:
  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: session_id
        presentMatch: true
    priority: 0
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v1-affinity-service
        weight: 100

  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: route
        exactMatch: timeout
    priority: 1
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 100
      maxStreamDuration:
        seconds: 5

  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: route
        exactMatch: fault
    priority: 2
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 100
      faultInjectionPolicy:
        abort:
          httpStatus: 503
          percentage: 50

  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: membership
        exactMatch: premium
    priority: 3
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v1-service
        weight: 100
      retryPolicy:
        retryConditions:
          - unavailable
        numRetries: 3

  - matchRules:
    - fullPathMatch: /grpc.examples.wallet.Wallet/FetchBalance
    priority: 4
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v1-service
        weight: 70
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 30

  - matchRules:
    - prefixMatch: /grpc.examples.wallet.Wallet/
    priority: 5
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 100
EOF

Zielproxy und Weiterleitungsregel erstellen

In diesem Abschnitt erstellen Sie den gRPC-Zielproxy und eine Weiterleitungsregel.

Der gRPC-Zielproxy verweist auf die URL-Zuordnung, die Sie im vorherigen Schritt erstellt haben. Das Flag --validate-for-proxyless aktiviert die Konfigurationsprüfungen, damit Sie nicht versehentlich ein Feature aktivieren, das nicht mit proxylosen gRPC-Bereitstellungen kompatibel ist.

gcloud

• Erstellen Sie den gRPC-Zielproxy:

  gcloud compute target-grpc-proxies create grpcwallet-proxy \
     --url-map=grpcwallet-url-map \
     --validate-for-proxyless
  

Die Weiterleitungsregel verweist auf den von Ihnen erstellten gRPC-Zielproxy. Das Load Balancing-Schema ist auf INTERNAL_SELF_MANAGED gesetzt, um anzugeben, dass diese Weiterleitungsregel von Cloud Service Mesh verwendet wird. Es muss eine globale Weiterleitungsregel sein. Die IP-Adresse wird auf 0.0.0.0 gesetzt, da ein proxyloser gRPC-Client den hostname:port im Ziel-URI auflöst. Dazu sendet er eine LDS an Cloud Service Mesh, anstatt eine DNS-Suche auszuführen. Weitere Informationen finden Sie unter Schema zur Namensauflösung.

Wenn im Ziel-URI kein Port angegeben ist, ist der Standardwert 80. Beispiel: Ein Ziel-URI xds:///foo.myservice:8080 stimmt mit einer Weiterleitungsregel überein, die mit Port 8080 konfiguriert ist. In diesem Beispiel wird die Weiterleitungsregel mit Port 80 konfiguriert.

gcloud

• Erstellen Sie die Weiterleitungsregel:

  gcloud compute forwarding-rules create grpcwallet-forwarding-rule \
     --global \
     --load-balancing-scheme=INTERNAL_SELF_MANAGED \
     --address=0.0.0.0 \
     --address-region=us-central1 \
     --target-grpc-proxy=grpcwallet-proxy \
     --ports=80 \
     --network=default
  

Konfiguration prüfen

Wenn der Konfigurationsvorgang abgeschlossen ist, prüfen Sie, ob die von Ihnen konfigurierten Backend-Dienste auf der Seite „Cloud Service Mesh“ in der Google Cloud Console verfügbar sind. Prüfen Sie, ob die Backend-Dienste und die zugehörigen Backends als fehlerfrei gemeldet werden. Dieser Vorgang kann einige Minuten dauern.

Routingkonfiguration prüfen

In diesem Abschnitt prüfen Sie, ob die Routingkonfiguration richtig funktioniert. Testen Sie die Konfiguration mit dem grpcurl-Tool.

gcloud

1. Erstellen Sie eine Client-VM, auf der Sie die Clients ausführen, um den Dienst zu testen. Sie können optional das Flag --network-interface=no-address einfügen.

   gcloud compute instances create grpc-wallet-client \
       --zone=us-central1-a \
       --scopes=https://www.googleapis.com/auth/cloud-platform \
       --image-family=debian-10 \
       --image-project=debian-cloud \
       --metadata-from-file=startup-script=<(echo '#! /bin/bash
   set -e
   export GRPC_XDS_BOOTSTRAP=/run/td-grpc-bootstrap.json
   # Expose bootstrap variable to SSH connections
   echo export GRPC_XDS_BOOTSTRAP=$GRPC_XDS_BOOTSTRAP | sudo tee /etc/profile.d/grpc-xds-bootstrap.sh
   # Create the bootstrap file
   curl -L https://storage.googleapis.com/traffic-director/td-grpc-bootstrap-0.16.0.tar.gz | tar -xz
   ./td-grpc-bootstrap-0.16.0/td-grpc-bootstrap | sudo tee $GRPC_XDS_BOOTSTRAP')
   

2. Greifen Sie mit SSH auf die VM zu und führen Sie die folgenden Befehle aus, um die VM vorzubereiten:

   export EXAMPLES_VERSION=v1.1.x
   sudo apt-get update
   sudo apt-get install git -y
   

3. Führen Sie folgende Befehle aus:

   git clone -b $EXAMPLES_VERSION --single-branch --depth=1 \
      https://github.com/GoogleCloudPlatform/traffic-director-grpc-examples.git
   curl -L https://github.com/fullstorydev/grpcurl/releases/download/v1.6.1/grpcurl_1.6.1_linux_x86_64.tar.gz | tar -xz
   chmod +x grpcurl
   

Für den Zugriff auf die Dienste ohne Sidecar-Proxy muss der gRPC-Client das Namensauflösungsschema xds verwenden. Dieses Schema teilt der im Client verwendeten gRPC-Bibliothekmit, einen xDS-Server zur Auflösung des Hostnamens zu verwenden. Dazu ist eine Bootstrap-Konfiguration erforderlich.

Das Startskript im vorherigen Abschnitt legt die Umgebungsvariable GRPC_XDS_BOOTSTRAP fest und verwendet ein Hilfsskript, um die Bootstrap-Datei zu erstellen. Die Werte für TRAFFICDIRECTOR_GCP_PROJECT_NUMBER, TRAFFICDIRECTOR_NETWORK_NAME und die Zone in der erstellten Bootstrap-Datei werden vom Metadatenserver abgerufen, der diese Details zu Ihren Compute Engine-VM-Instanzen kennt. Sie können diese Werte mithilfe der Optionen -gcp-project-number und -vpc-network-name manuell im Hilfsskript angeben.

Hinweis :Gemäß unseren Richtlinien sollten Nutzer jährlich nach Updates für den gRPC-Bootstrap-Generator von Traffic Director suchen.

Konfiguration mit dem grpcurl-Tool prüfen

Führen Sie die folgenden Befehle in der SSH-Shell aus, um zu prüfen, ob die Dienste wallet-service, stats-service und account-service ausgeführt werden:

./grpcurl -plaintext xds:///account.grpcwallet.io list
./grpcurl -plaintext -d '{"token": "2bd806c9"}' xds:///account.grpcwallet.io grpc.examples.wallet.account.Account/GetUserInfo
./grpcurl -plaintext -H 'authorization:2bd806c9' -H 'membership:premium' xds:///stats.grpcwallet.io grpc.examples.wallet.stats.Stats/FetchPrice
./grpcurl -plaintext -H 'authorization:2bd806c9' -H 'membership:premium' -d '{"include_balance_per_address": true}' xds:///wallet.grpcwallet.io grpc.examples.wallet.Wallet/FetchBalance

Sie sehen die folgenden Ergebnisse:

grpc.examples.wallet.account.Account
grpc.health.v1.Health
grpc.reflection.v1alpha.ServerReflection

{
  "name": "Alice",
  "membership": "PREMIUM"
}

{
  "price": "10295"
}

{
  "balance": "5089953"
}

Mit grpc-wallet-Clients prüfen

Prüfen Sie die Konfiguration anhand der folgenden sprachspezifischen Anleitungen. Die Befehle senden mehrere RPCs, teilweise mit zusätzlichen Metadaten, um zu zeigen, dass Anfragen anhand der Zuordnungsregeln aus der URL-Zuordnung an Backend-Dienste weitergeleitet werden. Der Befehl gibt auch für jede Antwort den Hostnamen der VM-Instanz aus. Damit wird angezeigt, an welche VM-Instanz die Anfrage weitergeleitet wurde.

Java

1. Führen Sie folgenden Befehl aus, um den Dienst mit einem gRPC-Java-Client zu prüfen:

   sudo apt-get install -y openjdk-11-jdk-headless
   

2. Führen Sie folgende Befehle aus:

   cd ~/traffic-director-grpc-examples/java
   ./gradlew installDist
   
   # This command calls 'FetchBalance' from 'wallet-service' in a loop,
   # to demonstrate that 'FetchBalance' gets responses from 'wallet-v1' (70%)
   # and 'wallet-v2' (30%).
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob
   
   # This command calls the streaming RPC 'WatchBalance' from 'wallet-service'.
   # The RPC path matches the service prefix, so all requests are
   # sent to 'wallet-v2'.
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   
   # This command calls 'WatchPrice' from 'stats-service'. It sends the
   # user's membership (premium or not) in metadata. Premium requests are
   # all sent to 'stats-premium' and get faster responses. Alice's requests
   # always go to premium and Bob's go to regular.
   ./build/install/wallet/bin/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Bob
   ./build/install/wallet/bin/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Alice
   

Go

1. Installieren Sie Golang oder folgen Sie der offiziellen Anleitung, um den Dienst mit einem gRPC-Go-Client zu prüfen:

   sudo apt-get install -y wget
   wget https://dl.google.com/go/go1.16.5.linux-amd64.tar.gz
   sudo tar -C /usr/local -xvf go1.16.5.linux-amd64.tar.gz
   sudo ln -s /usr/local/go/bin/go /usr/bin/go
   

2. Führen Sie folgende Befehle aus:

   cd ~/traffic-director-grpc-examples/go/wallet_client
   go build
   
   # This command calls 'FetchBalance' from 'wallet-service' in a loop,
   # to demonstrate that 'FetchBalance' gets responses from 'wallet-v1' (70%)
   # and 'wallet-v2' (30%).
   ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch --user=Bob
   
   # This command calls the streaming RPC 'WatchBalance' from 'wallet-service'.
   # The RPC path matches the service prefix, so all requests
   # are sent to 'wallet-v2'.
   ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob
   
   # This command calls 'WatchPrice' from 'stats-service'. It sends the
   # user's membership (premium or not) in metadata. Premium requests are
   # all sent to 'stats-premium' and get faster responses. Alice's requests
   # always go to premium and Bob's go to regular.
   ./wallet_client price --stats_server="xds:///stats.grpcwallet.io" --watch --user=Bob
   ./wallet_client price --stats_server="xds:///stats.grpcwallet.io" --watch --user=Alice
   

C++

1. Führen Sie folgenden Befehl aus, um den Dienst mit einem gRPC-C++-Client zu prüfen:

   sudo apt-get install -y build-essential
   

2. Führen Sie folgende Befehle aus:

   cd ~/traffic-director-grpc-examples/cpp
   ../tools/bazel build :client
   
   # This command calls 'FetchBalance' from 'wallet-service' in a loop,
   # to demonstrate that 'FetchBalance' gets responses from 'wallet-v1' (70%)
   # and 'wallet-v2' (30%).
   ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob
   
   # This command calls the streaming RPC 'WatchBalance'  from 'wallet-service'.
   # The RPC path matches the service prefix, so all requests are sent to 'wallet-v2'.
   ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   
   # This command calls 'WatchPrice' from 'stats-service'. It sends the
   # user's membership (premium or not) in metadata. Premium requests are
   # all sent to 'stats-premium' and get faster responses. Alice's requests
   # always go to premium, and Bob's go to regular.
   ../bazel-bin/cpp/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Bob
   ../bazel-bin/cpp/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Alice
   

Zusätzliche erweiterte Optionen konfigurieren

In den folgenden Abschnitten können Sie zusätzliche erweiterte Optionen für das Routing von Traffic konfigurieren.

Schutzschaltung

Mit einer Schutzschaltung können Sie Fehlerschwellenwerte festlegen, damit Clientanfragen Ihre Back-Ends nicht überlasten. Wenn die Anzahl der ausstehenden Anfragen ein von Ihnen festgelegtes Limit erreicht, sendet der Client keine weiteren Anfragen mehr und gibt Ihren Backend-Diensten Zeit zur Wiederherstellung.

Schutzschaltungen verhindern Fehlerkaskaden. Anstatt einen Backend-Dienst zu überlasten, werden Fehler an den Client zurückgegeben. Dadurch kann ein Teil des Traffics verarbeitet werden, während parallel Zeit zum Lösen von Überlastungsproblemen bleibt. Beispielsweise können Zugriffsspitzen durch Erhöhen der Kapazität mithilfe von Autoscaling bewältigt werden.

Wenn Sie den Backend-Dienst für stats-service erstellen, enthält das Skript create_service.sh die folgenden Zeilen in seiner Konfiguration:

circuitBreakers:
  maxRequests: 1

Diese Einstellung beschränkt Clients auf jeweils eine ausstehende Anfrage an stats-service. Da es nur einen wallet-v2-Dienst gibt, werden bei Ausführung von zwei gleichzeitigen WatchBalance-Vorgängen des Wallet-Clients Fehler bei der zweiten Instanz festgestellt.

Java

1. Führen Sie folgende Befehle aus:

   cd ~/traffic-director-grpc-examples/java
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob  2>/dev/null 1>/dev/null &
   
   sleep 10 # Wait a few seconds to allow the watch to begin.
   
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   

2. Die Ausgabe sieht so aus:

   io.grpc.examples.wallet.Client run
   INFO: Will try to run balance
   io.grpc.examples.wallet.Client run
   WARNING: RPC failed: Status{code=INTERNAL, description=RPC to stats server failed: UNAVAILABLE: Cluster max concurrent requests limit exceeded, cause=null}
   

3. Führen Sie den Befehl kill aus:

   kill %%
   

Go

1. Führen Sie folgende Befehle aus:

   cd ~/traffic-director-grpc-examples/go/wallet_client
   ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob 2> /dev/null 1> /dev/null &
   
   sleep 10 # Wait a few seconds to allow the watch to begin.
   
   ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob
   

2. Die Ausgabe sieht so aus:

   server host: error: no hostname
   failed to fetch balance: rpc error: code = Internal desc = RPC to stats server failed:
   UNAVAILABLE: Cluster max concurrent requests limit exceeded
   

3. Führen Sie den Befehl kill aus:

   kill %%
   

C++

1. Führen Sie folgende Befehle aus:

   cd ~/traffic-director-grpc-examples/cpp
   ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob 2>/dev/null 1>/dev/null &
   
   sleep 10 # Wait a few seconds to allow the watch to begin.
   
   ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   

2. Die Ausgabe sieht so aus:

   Client arguments: command: balance, wallet_server: xds:///wallet.grpcwallet.io, stats_server:
   localhost:18882, user: Bob, watch: 1 ,unary_watch: 0, observability_project: , route:
   13: RPC to stats server failed: UNAVAILABLE: Cluster max concurrent requests limit exceeded
   

3. Führen Sie den Befehl kill aus:

   kill %%
   

Fault Injection

Fault Injection kann Fehler bei der Bearbeitung von Anfragen einbringen, um Störungen zu simulieren, einschließlich hoher Latenz, Dienstüberlastung, Dienstfehlern und Netzwerkpartitionierung. Diese Funktion ist hilfreich, um die Ausfallsicherheit eines Dienstes gegenüber simulierten Störungen zu testen.

Beim Erstellen der URL-Zuordnung haben Sie die Fehlerinjektionsrichtlinie so festgelegt, dass 50 % der an wallet.grpcwallet.io gesendeten RPCs mit dem Header route=fault fehlschlagen.

Verwenden Sie den Code in den folgenden Sprachen, um die Fault Injection zu demonstrieren.

Java

1. Führen Sie folgende Befehle aus:

   cd ~/traffic-director-grpc-examples/java
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=fault
   

2. Die Ausgabe sieht so aus:

   server host: grpcwallet-wallet-v2-mig-us-central1-zznc
   total balance: 10340491
   - address: 148de9c5, balance: 2549839
   - address: 2e7d2c03, balance: 7790652
   io.grpc.examples.wallet.Client run
   WARNING: RPC failed: Status{code=UNAVAILABLE, description=RPC terminated due to fault injection: HTTP status code 503, cause=null}
   

Go

1. Führen Sie folgende Befehle aus:

   cd ~/traffic-director-grpc-examples/go/wallet_client
   ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch --user=Bob --route=fault
   

2. Die Ausgabe sieht so aus:

    server host: grpcwallet-wallet-v1-mig-us-central1-bm1t_wallet-v1
    user: Bob, total grpc-coin balance: 10452589.
     - address: 2e7d2c03, balance: 7875108.
     - address: 148de9c5, balance: 2577481.
    failed to fetch balance: rpc error: code = Unavailable desc = RPC terminated due to fault injection
   

C++

1. Führen Sie folgende Befehle aus:

   cd ~/traffic-director-grpc-examples/cpp
   ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=fault
   

2. Die Ausgabe sieht so aus:

   Client arguments: command: balance, wallet_server: xds:///wallet.grpcwallet.io,
   stats_server: localhost:18882, user: Bob, watch: 0 ,unary_watch: 1, observability_project: ,
   route: fault server host: grpcwallet-wallet-v2-mig-us-central1-1lm6
   user: Bob total grpc-coin balance: 10211908
    - address: 148de9c5, balance: 2518132
    - address: 2e7d2c03, balance: 7693776
   14: Fault injected
   

Maximale Streamdauer

Mit der maximalen Streamdauer kann ein maximales Zeitlimit auf alle RPCs angewendet werden. Dadurch wird verhindert, dass Clients, die vergessen haben, eine Frist festzulegen, oder eine übermäßige Frist festlegen, keine Serverressourcen verschwenden.

Wenn Sie die URL-Zuordnung zuvor erstellt haben, legen Sie eine maximale Streamdauer von 5 Sekunden für an wallet.grpcwallet.io gesendete RPCs mit dem Header route=timeout fest.

Zur Veranschaulichung von Zeitüberschreitungen beenden wir zuerst den wallet-v2-Dienst.

gcloud

gcloud compute instance-groups managed resize \
    --size=0 grpcwallet-wallet-v2-mig-us-central1 \
    --zone=us-central1-a

Der folgende Befehl würde endlos hängen, da es keinen Back-End-Dienst zur Verarbeitung gibt und die Anwendung keine Frist festlegt.

Java

1. Führen Sie folgende Befehle aus:

   cd ~/traffic-director-grpc-examples/java
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   

2. Der Befehl reagiert nicht mehr. Drücken Sie ^C, um den Befehl zu unterbrechen.

Go

1. Führen Sie folgende Befehle aus:

   cd ~/traffic-director-grpc-examples/go/wallet_client
   ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob
   

2. Der Befehl reagiert nicht mehr. Drücken Sie ^C, um den Befehl zu unterbrechen.

C++

1. Führen Sie folgende Befehle aus:

   cd ~/traffic-director-grpc-examples/cpp
   ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   

2. Der Befehl reagiert nicht mehr. Drücken Sie ^C, um den Befehl zu unterbrechen.

Der folgende Befehl, der die timeout-Route nutzt, schlägt jedoch aufgrund der Einstellung maxStreamDuration nach fünf Sekunden fehl.

Java

1. Führen Sie dazu diesen Befehl aus:

   cd ~/traffic-director-grpc-examples/java
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob --route=timeout
   

2. Die Ausgabe sieht so aus:

   io.grpc.examples.wallet.Client run
   WARNING: RPC failed: Status{code=DEADLINE_EXCEEDED, description=deadline exceeded after 4.999594070s.         [wait_for_ready, buffered_nanos=5000553401, waiting_for_connection], cause=null}
   

Go

1. Führen Sie dazu diesen Befehl aus:

   cd ~/traffic-director-grpc-examples/go/wallet_client
   ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob --route=timeout
   

2. Die Ausgabe sieht so aus:

   failed to create stream: rpc error: code = DeadlineExceeded desc = context deadline exceeded.
   

C++

1. Führen Sie dazu diesen Befehl aus:

   cd ~/traffic-director-grpc-examples/cpp
   ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob --route=timeout
   

2. Die Ausgabe sieht so aus:

   Client arguments: command: balance, wallet_server: xds:///wallet.grpcwallet.io, stats_server:
   localhost:18882, user: Bob, watch: 1 ,unary_watch: 0, observability_project: , route: timeout
   4: Deadline Exceeded
   

Starten Sie den Dienst wallet-v2 neu.

gcloud

gcloud compute instance-groups managed resize \
    --size=1 grpcwallet-wallet-v2-mig-us-central1 \
    --zone=us-central1-a

Wiederholen

Mit Wiederholungsversuchen können Sie die Dienstverfügbarkeit verbessern. Dazu aktivieren Sie gRPC-Anwendungen, um ausgehende Anfragen entsprechend einer Wiederholungsrichtlinie zu wiederholen. In einer Wiederholungsrichtlinie können Sie die Bedingungen konfigurieren, unter denen eine fehlgeschlagene Anfrage wiederholt werden soll. Sie können auch die maximale Anzahl der Wiederholungsversuche konfigurieren, z. B. wenn eine Anfrage mit einem bestimmten Antwortcode fehlschlägt.

Wenn Sie die URL-Zuordnung zuvor erstellt haben, legen Sie eine Wiederholungsrichtlinie für RPCs auf die Methode FetchBalance mit dem Header membership=premium fest. Diese Richtlinie wiederholt RPCs, die mit dem Statuscode unavailable fehlschlagen, bis zu dreimal. Außerdem legen Sie eine Fehlerinjektionsrichtlinie für RPCs auf account.grpcwallet.io mit dem Header route=account-fault fest, bei der 30 % der RPCs vom Dienst Wallet an Account fehlschlagen. Daher schlagen 30 % der RPCs vom Testclient mit dem Header membership=normal fehl. Die Fehlerquote für die RPCs mit dem Header membership=premium liegt hingegen unter 1 %.

Verwenden Sie den Code in den folgenden Sprachen, um Wiederholungsversuche zu veranschaulichen.

Java

Führen Sie folgende Befehle aus:

cd ~/traffic-director-grpc-examples/java
# 30% of the requests fail because Bob is a normal user.
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=account-fault
# Less than 1% of the requests fail because Alice is a premium user.
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --route=account-fault

Go

Führen Sie folgende Befehle aus:

cd ~/traffic-director-grpc-examples/go/wallet_client
# 30% of the requests fail because Bob is a normal user.
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=account-fault
# Less than 1% of the requests fail because Alice is a premium user.
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --route=account-fault

C++

Führen Sie folgende Befehle aus:

cd ~/traffic-director-grpc-examples/cpp
# 30% of the requests fail because Bob is a normal user.
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=account-fault
# Less than 1% of the requests fail because Alice is a premium user.
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --route=account-fault

Sitzungsaffinität

Mit Sitzungsaffinität wird ein Best-Effort-Versuch unternommen, um Anfragen mit bestimmten Merkmalen (HTTP-Header) an dieselbe Instanz zu senden, solange die Instanz fehlerfrei ist und Kapazität hat. Dies ist nützlich für zustandsorientierte Anwendungsserver, die von einer verbesserten Leistung und Effizienz profitieren, wenn Anfragen von einem bestimmten Client an dieselbe Instanz gesendet werden, z. B. bei der Round-Robin-Verteilung an verschiedene Instanzen.

Hinweis: Ein gRPC-Client, der die Load Balancing-Richtlinie RING_HASH nicht unterstützt, lehnt die Konfiguration von Cloud Service Mesh ab, wenn eine URL-Zuordnung auf einen Backend-Dienst mit localityLbPolicy=RING_HASH verweist. Dies führt dazu, dass der Client-Kanal vorübergehend in einen Fehlerzustand versetzt wird, bis die Konfiguration korrigiert wurde. Weitere Informationen finden Sie unter Einschränkungen für Back-End-Dienste.

Als Sie den Backend-Dienst grpcwallet-wallet-v1-affinity-service erstellten, wurde im create_service.sh-Skript der localityLbPolicy auf ROUND_ROBIN gesetzt. In diesem Beispiel wenden Sie folgende Konfiguration an, um localityLbPolicy in RING_HASH zu ändern.

sessionAffinity: HEADER_FIELD
localityLbPolicy: RING_HASH
consistentHash:
  httpHeaderName: "session_id"

gcloud

1. Speichern Sie die Konfiguration des Backend-Dienstes grpcwallet-wallet-v1-affinity-service:

   gcloud compute backend-services export grpcwallet-wallet-v1-affinity-service \
    --destination=bs_config.yaml \
    --global
   

2. Aktualisieren Sie den Backend-Dienst grpcwallet-wallet-v1-affinity-service:

   project_id="$(gcloud config list --format 'value(core.project)')"
   backend_config="
   backends:
   - balancingMode: UTILIZATION
     capacityScaler: 1.0
     group: projects/${project_id}/zones/us-central1-a/instanceGroups/grpcwallet-wallet-v1-mig-us-central1
   connectionDraining:
     drainingTimeoutSec: 0
   healthChecks:
   - projects/${project_id}/global/healthChecks/grpcwallet-health-check
   loadBalancingScheme: INTERNAL_SELF_MANAGED
   name: grpcwallet-wallet-v1-affinity-service
   portName: grpcwallet-wallet-port
   protocol: GRPC
   sessionAffinity: HEADER_FIELD
   localityLbPolicy: RING_HASH
   consistentHash:
     httpHeaderName: session_id"
   gcloud compute backend-services import grpcwallet-wallet-v1-affinity-service --global <<< "${backend_config}"
   

Hinweis: Es kann einige Minuten dauern, bis die Aktualisierung des Backend-Dienstes auf die Clients übertragen wird.

Verwenden Sie den Code in den folgenden Sprachen, um die Sitzungsaffinität zu veranschaulichen. Mit dem Flag --affinity=true fügt der Client eine Header-session-id mit einem eindeutigen Wert für jeden Nutzer ein. Ein Hash dieses Werts wird verwendet, um die Anfrage an eine bestimmte Instanz in der Instanzgruppe des Backend-Dienstes grpcwallet-wallet-v1-affinity-service zu senden.

Java

Führen Sie folgende Befehle aus:

cd ~/traffic-director-grpc-examples/java
# Without affinity, requests are sent to both instances.
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice
# With affinity, requests are sent to only one instance.
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --affinity=true

Go

Führen Sie folgende Befehle aus:

cd ~/traffic-director-grpc-examples/go/wallet_client
# Without affinity, requests are sent to both instances.
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice
# With affinity, requests are sent to only one instance.
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --affinity=true

C++

Führen Sie folgende Befehle aus:

cd ~/traffic-director-grpc-examples/cpp
# Without affinity, requests are sent to both instances.
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice
# With affinity, requests are sent to only one instance.
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --affinity=true

Stellen Sie die Konfiguration des Backend-Dienstes grpcwallet-wallet-v1-affinity-service wieder her.

gcloud

gcloud compute backend-services import grpcwallet-wallet-v1-affinity-service \
  --source=bs_config.yaml \
  --global

Ausreißererkennung

Um die Dienstverfügbarkeit zu verbessern, konfigurieren Sie die Ausreißererkennung. Mit diesem Feature können Sie fehlerhafte Hosts aus dem Load-Balancing-Pool identifizieren und vorübergehend ausschließen. Diese fehlerhaften Hosts werden als Ausreißer bezeichnet.

gRPC wertet Hosts anhand der Erfolgsquote aus – der Häufigkeit, mit der ein Host Anfragen erfolgreich verarbeitet. Die Rate wird durch Fehler wie gRPC-Fehler, HTTP-Fehler, Zeitüberschreitungen und andere Probleme beeinflusst.

Wenn Sie die Ausreißererkennung über Cloud Service Mesh konfigurieren, können Sie optimieren, wie gRPC Hosts bewertet und Ausreißer behandelt. Sie können beispielsweise folgende Kriterien angeben:

• Die Anzahl der Anfragen, die ein Host erhalten muss, bevor gRPC ihn auf einen möglichen Ausreißerstatus analysiert.

• Der Umfang, in dem ein Host von der mittleren Erfolgsquote abweichen kann, bevor er als Ausreißer betrachtet wird.

• Der maximale Prozentsatz der Hosts, die jederzeit aus dem Load-Balancing-Pool ausgeschlossen werden können.

• Der Zeitraum, für den ein Ausreißer aus dem Load-Balancing-Pool ausgeschlossen wird.

Weitere Informationen zu den verfügbaren Parametern finden Sie in der Referenz zu REST Resource: backendServices. Für gRPC gelten jedoch einige Einschränkungen, die im folgenden Abschnitt beschrieben werden.

Beschränkungen

Die folgenden Felder werden für gRPC-Clients nicht unterstützt:

• outlierDetection.consecutiveErrors

• outlierDetection.enforcingConsecutiveErrors

• outlierDetection.consecutiveGatewayFailure

• outlierDetection.enforcingConsecutiveGatewayFailure

Ausreißererkennung einrichten

Im Folgenden wird gezeigt, wie Sie die Ausreißererkennung für einen Dienst konfigurieren, der eine Instanzgruppe als Backend verwendet. Mit diesem Verfahren wird die folgende Konfiguration eingerichtet:

• Die Ausreißererkennungsanalyse wird jede Sekunde ausgeführt. Sie können dieses Verhalten mithilfe des Felds interval konfigurieren.
• Ausreißer werden folgendermaßen in 30-Sekunden-Schritten aus dem Load-Balancing-Pool ausgeschlossen:
  • Wenn ein Host noch nie ausgeschlossen wurde, wird er nur 30 Sekunden lang ausgeschlossen.
  • Wenn ein Host zuvor ausgeschlossen wurde, erhöht sich die Dauer für jeden vorherigen Ausschluss um 30 Sekunden. Wenn ein Host beispielsweise zum dritten Mal ausgeschlossen wird, dauert der Ausschluss 90 Sekunden. Sie konfigurieren dieses Verhalten mit dem Feld baseEjectionTime.
• Ein Host gilt als fehlerhaft, wenn seine Erfolgsquote während des ausgewählten Zeitintervalls (in diesem Fall 1 Sekunde) um eine Standardabweichung unter dem Durchschnitt liegt. Die maximale Standardabweichung wird über das Feld successRateStdevFactor konfiguriert.

Wenn Sie die Ausreißererkennung auf diese Weise konfigurieren möchten, führen Sie die folgenden Schritte aus.

gcloud

1. Exportieren Sie die Konfigurationsdatei des Backend-Dienstes grpcwallet-wallet-v2-service mit dem Befehl gcloud compute backend-services export:

   gcloud compute backend-services export grpcwallet-wallet-v2-service \
    --destination=bs_config.yaml \
    --global
   

2. Aktualisieren Sie in der Datei bs_config.yaml die Konfiguration grpcwallet-wallet-v2-service, damit sie die Ausreißererkennungsfelder enthält:

   outlierDetection:
    interval:
      seconds: 1
      nanos: 0
    baseEjectionTime:
      seconds: 30
      nanos: 0
    successRateStdevFactor: 1000
   

3. Importieren Sie die aktualisierte Datei mit dem Befehl gcloud compute backend-services import:

   gcloud compute backend-services import grpcwallet-wallet-v2-service \
    --source=bs_config.yaml \
    --global

Hinweis: Das Wallet-Beispiel ist nicht für die Verwendung von fehlerhaften Hosts konzipiert. Aus diesem Grund werden grpcwallet-wallet-v2-service-Hosts normalerweise nicht entfernt, auch wenn Sie die Ausreißererkennung korrekt konfiguriert haben.

Ort-Load Balancing

Konfigurieren Sie das Load Balancing nach Standort, um Ihre Ressourcen möglichst effizient zu nutzen. Mit dieser Funktion können Sie Ressourcen sparen, da Clientanfragen gleichmäßig auf Ihre Back-Ends verteilt werden.

Wenn Sie das Load Balancing nach Standort konfigurieren, können Sie die in der folgenden Tabelle beschriebenen Optionen verwenden. Für alle Optionen müssen Sie die Ressource backendServices konfigurieren.

Option	Verfügbar für	Relevantes Konfigurationsfeld
Integrierte Richtlinie verwenden	Alle gRPC-Clients	localityLbPolicy
Benutzerdefinierte Richtlinie verwenden	Java-Clients, die gRPC-Version 1.47 oder höher in einem Mesh verwenden, das nur gRPC-Clients enthält	localityLbPolicies
Liste der bevorzugten Richtlinien definieren	Java-Clients, die gRPC-Version 1.47 oder höher in einem Mesh verwenden, das nur gRPC-Clients enthält	localityLbPolicies

Sie können eine beliebige Kombination der Optionen verwenden. Wenn Sie jedoch sowohl localityLbPolicy als auch localityLbPolicies konfigurieren, versucht gRPC zuerst, die localityLbPolicies-Konfiguration zu verwenden.

Wenn Sie das Load Balancing für den Ort nicht konfigurieren, verwendet Cloud Service Mesh die Richtlinie ROUND_ROBIN.

Informationen zu ROUND_ROBIN und anderen integrierten Richtlinien finden Sie in der Beschreibung von localityLbPolicy auf der Seite backendServices.

Vordefinierte Richtlinie verwenden

Wenn Sie möchten, dass alle Ihre Kunden dieselbe integrierte Richtlinie verwenden, können Sie sie auswählen, indem Sie das Feld localityLbPolicy konfigurieren.

Beim Konfigurieren dieses Felds können Sie eine der folgenden Richtlinien auswählen:

• LEAST_REQUEST (nur Java-Clients)
• RING_HASH
• ROUND_ROBIN

Wenn nicht alle Ihre Kunden dieselbe Richtlinie verwenden können, lesen Sie den Hilfeartikel Liste der bevorzugten Richtlinien definieren.

gcloud

1. Exportieren Sie die Konfigurationsdatei des Backend-Dienstes grpcwallet-wallet-v2-service mit dem Befehl gcloud compute backend-services export:

   gcloud compute backend-services export grpcwallet-wallet-v2-service \
   --destination=bs_config.yaml \
   --global
   

2. Aktualisieren Sie die exportierte bs_config.yaml-Datei, um die folgenden Zeilen einzufügen:

   localityLbPolicy:
    -- policy
       name: RING_HASH
   

3. Importieren Sie die aktualisierte Datei mit dem Befehl gcloud compute backend-services import:

   gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
   

Benutzerdefinierte Richtlinie verwenden

Gegebenenfalls können Sie eine benutzerdefinierte Load Balancing-Richtlinie verwenden, die Sie mit gRPC erstellt und bereitgestellt haben. Diese Funktion ist für Java-Clients verfügbar, die gRPC-Version 1.47 oder höher verwenden. Verwenden Sie es nur in einem Mesh, das alle gRPC-Clients umfasst.

Beim Erstellen einer benutzerdefinierten Richtlinie können die folgenden Dokumente hilfreich sein:

• Mit den ORCA-APIs (Open Request Cost Aggregation) können Sie Ihre benutzerdefinierte Richtlinie optimieren. Mit diesen APIs können Sie Messwerte zu Abfragekosten und Serverauslastung erfassen. Für die Verwendung dieser APIs ist gRPC Version 1.48.1 oder höher erforderlich. Weitere Informationen finden Sie im Beispiel für gRPC ORCA.

• Informationen dazu, wie benutzerdefinierte Load Balancing-Konfigurationen von xDS an gRPC gesendet werden, finden Sie unter Benutzerdefinierte Load Balancer-Konfiguration für gRPC xDS.

Wenn Sie Cloud Service Mesh für die Verwendung Ihrer benutzerdefinierten Richtlinie konfigurieren möchten, geben Sie die Richtlinie im Feld localityLbPolicies an.

Die folgenden Schritte veranschaulichen diesen Vorgang. Dabei aktualisieren Sie die Konfiguration des grpcwallet-wallet-v2-service-Back-End-Dienstes so, dass Clients, die eine Verbindung dazu herstellen, eine benutzerdefinierte Richtlinie namens example.ExampleLoadBalancer verwenden.

Achtung :Diese Funktion ist nur für die Verwendung in einem Service Mesh vorgesehen, das nur gRPC-Clients enthält. Envoy-Proxys können keine Back-End-Dienste mit dieser Konfiguration verwenden.

gcloud

1. Exportieren Sie die Konfigurationsdatei des Backend-Dienstes grpcwallet-wallet-v2-service mit dem Befehl gcloud compute backend-services export:

   gcloud compute backend-services export grpcwallet-wallet-v2-service \
   --destination=bs_config.yaml \
   --global
   

2. Aktualisieren Sie die exportierte bs_config.yaml-Datei, damit sie auf die example.ExampleLoadBalancer-Richtlinie verweist. Fügen Sie die folgenden Zeilen hinzu:

   localityLbPolicies:
     - customPolicy:
         name: example.ExampleLoadBalancer
         data: '{ "message": "Hello load-balancing world!" }'
   

3. Importieren Sie die aktualisierte Datei mit dem Befehl gcloud compute backend-services import:

   gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
   

4. Optional: Konfiguration des Load Balancing testen:

   Java

   cd ~/traffic-director-grpc-examples/java
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   

   Wenn Sie die benutzerdefinierte Load Balancing-Richtlinie richtig konfiguriert haben, wird die in der Konfiguration enthaltene Meldung („Hallo Welt des Load Balancings!“) angezeigt.

Liste der bevorzugten Richtlinien definieren

Wenn Sie mehrere Clients haben, die nicht alle dieselbe Load Balancing-Richtlinie unterstützen, erstellen Sie eine Liste der Richtlinien, die Ihre Clients verwenden können. Wenn bei dieser Option die erste bevorzugte Richtlinie von einem bestimmten Client nicht verwendet werden kann, greift gRPC auf die nächste Richtlinie in der Liste zurück.

Wenn Sie eine Liste der bevorzugten Richtlinien erstellen, sind benutzerdefinierte Richtlinien, ROUND_ROBIN und für Java-Clients LEAST_REQUEST zulässige Optionen. Sie können bis zu zehn Richtlinien angeben.

Diese Funktion ist nur für Java-Clients verfügbar, die gRPC-Version 1.47 oder höher verwenden. Verwenden Sie es nur in einem Mesh, das alle gRPC-Clients umfasst.

Achtung :Diese Funktion ist nur für die Verwendung in einem Service Mesh vorgesehen, das nur gRPC-Clients enthält. Envoy-Proxys können keine Back-End-Dienste mit dieser Konfiguration verwenden.

gcloud

1. Exportieren Sie die Konfigurationsdatei des Backend-Dienstes grpcwallet-wallet-v2-service mit dem Befehl gcloud compute backend-services export:

gcloud compute backend-services export grpcwallet-wallet-v2-service \
  --destination=bs_config.yaml \
  --global

1. Aktualisieren Sie die exportierte bs_config.yaml-Datei, um das Feld localityLbPolicies aufzunehmen. Fügen Sie Einträge für die folgenden Richtlinien hinzu:

   • Eine ungültige benutzerdefinierte Richtlinie (example.InvalidLoadBalancer)
   • Eine gültige benutzerdefinierte Richtlinie (example.ExampleLoadBalancer)
   • Eine unterstützte integrierte Richtlinie (LEAST_REQUEST)

   localityLbPolicies:
     - customPolicy:
         name: example.InvalidLoadBalancer
         data: '{ "message": "This load-balancing policy doesn't work!" }'
     - customPolicy:
         name: example.ExampleLoadBalancer
         data: '{ "message": "Hello load-balancing world!" }'
     - policy:
         name: LEAST_REQUEST
   

2. Importieren Sie die aktualisierte Datei mit dem Befehl gcloud compute backend-services import:

   gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
   

3. Optional: Konfiguration des Load Balancing testen:

   Java

   cd ~/traffic-director-grpc-examples/java
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   

   Daraufhin versucht gRPC, example.InvalidLoadBalancer zu finden, was aber fehlschlägt. Danach wird wieder example.ExampleLoadBalancer verwendet und Sie sehen die Meldung, die Sie in der Konfiguration angegeben haben („Hallo Welt des Load Balancings!“). Die gRPC-Protokollierung auf dem Client enthält die Meldung, dass example.InvalidLoadBalancer nicht gefunden wurde.

Ressourcen bereinigen

Führen Sie zum Bereinigen der Ressourcen den folgenden Befehl in Ihrem lokalen System aus:

traffic-director-grpc-examples/scripts/cleanup.sh

Traffic zwischen Diensten blockieren

Wenn Sie Traffic zwischen Dienst A und Dienst B blockieren möchten und Ihre Bereitstellung in GKE erfolgt, richten Sie die Dienstsicherheit ein und verwenden eine Autorisierungsrichtlinie, um Traffic zwischen Diensten zu blockieren. Eine vollständige Anleitung finden Sie unter Cloud Service Mesh-Dienstsicherheit und in der Einrichtungsanleitung für Envoy und proxyloses gRPC.

Nächste Schritte

• Informationen zur Behebung von Konfigurationsproblemen in Cloud Service Mesh finden Sie unter Fehlerbehebung bei Bereitstellungen, die proxyloses gRPC verwenden.