Diese Seite gilt für Apigee und Apigee Hybrid.
Apigee Edge-Dokumentation aufrufen
Dieses Thema bietet einen Überblick über die Apigee-Systemarchitektur. Es soll Ihnen helfen zu verstehen, welche Komponenten während der Bereitstellung erstellt werden und welchen Zweck sie im Gesamtsystem erfüllen.
Apigee bietet zwei Optionen für die Bereitstellung: mit VPC-Peering und ohne VPC-Peering. Beide Optionen werden in den folgenden Abschnitten beschrieben.
- Architektur mit aktiviertem VPC-Peering
- Architektur mit deaktiviertem VPC-Peering
- Eine Clientanwendung ruft einen Apigee API-Proxy auf.
- Die Anfrage wird an einen globalen externen L7-HTTPS-Load-Balancer (XLB) weitergeleitet. Der XLB ist mit einer externen/öffentlichen IP-Adresse und einem TLS-Zertifikat konfiguriert.
- Der XLB sendet die Anfrage an eine virtuelle Maschine (VM). Die VM dient als Brücke zwischen Ihrer VPC und der VPC von Google (von Apigee verwaltet).
- Die VM sendet die Anfrage an Apigee, das die API-Proxy-Anfrage verarbeitet.
- Apigee sendet die Anfrage an den Backend-Dienst und die Antwort wird an den Client zurückgesendet.
Architektur mit aktiviertem VPC-Peering
In diesem Abschnitt wird die Apigee-Systemarchitektur beschrieben, wenn Apigee mit der VPC-Peering-Option bereitgestellt wird.
Bereitstellungsübersicht
Während der Bereitstellung werden Komponenten konfiguriert und erstellt, die die bidirektionale Kommunikation zwischen einem von Ihnen verwalteten Virtual Private Cloud-Netzwerk (VPC) und einem von Apigee verwalteten VPC-Netzwerk ermöglichen. Nach Abschluss der ersten Schritte zur Bereitstellung sind die beiden VPCs vorhanden. Sie können aber nicht miteinander kommunizieren. Weitere Konfigurationen sind für die bidirektionale Kommunikation erforderlich. Siehe Abbildung 1.
Für eine Kommunikation zwischen VPCs verwenden wir VPC-Netzwerk-Peering. Netzwerk-Peering ermöglicht interne IP-Adressen-Konnektivität zwischen zwei VPC-Netzwerken (Virtual Private Cloud), unabhängig davon, ob sie zum selben Projekt oder zur selben Google Cloud-Organisation gehören. Nachdem der Netzwerk-Peering-Schritt abgeschlossen ist, ist eine Kommunikation zwischen den beiden VPCs möglich. Siehe Abbildung 2.
Um Traffic von Clientanwendungen im Internet an Apigee weiterzuleiten, verwenden wir einen globalen externen HTTPS-Load-Balancer (XLB). Ein XLB kann mithilfe von projektübergreifenden Dienstreferenzen über verschiedene Google Cloud-Projekte hinweg kommunizieren, beispielsweise zwischen dem Google Cloud-Projekt des Kunden und dem Apigee-Google Cloud-Projekt.
Sie können auch eine verwaltete Instanzgruppe (Managed Instance Group, MIG) von virtuellen Maschinen (VM) bereitstellen, die als Netzwerk-Bridge dienen. Die MIG-VMs können bidirektional über die Peering-Netzwerke kommunizieren. Nach Abschluss der Bereitstellung kommunizieren Anwendungen im Internet mit dem XLB, der XLB mit der Bridge-VM und die Bridge-VM mit dem Apigee-Netzwerk. Siehe Abbildung 3 und Abbildung 4.
In dieser Konfiguration wird der Traffic von Apigee (z. B. aus der MessageLogging-Richtlinie) zu einer Arbeitslast weitergeleitet, die in Ihrer internen VPC ausgeführt wird. In diesem Fall erfolgt die Kommunikation mit der internen VPC nicht über eine NAT-IP-Adresse des ausgehenden Traffics. Stattdessen können Sie den Traffic über eine der IP-Adressen der Apigee-Instanz weiterleiten.
Lebenszyklus eines API-Proxyaufrufs
Die folgende Abbildung zeigt den Lebenszyklus eines API-Proxyaufrufs, während er durch die bereitgestellten Apigee-Systemkomponenten geleitet wird (Abbildung 5):
Architektur mit deaktiviertem VPC-Peering
In diesem Abschnitt wird die Apigee-Systemarchitektur beschrieben, wenn Apigee nicht mit der VPC-Peering-Option bereitgestellt wird.
Während der Bereitstellung werden Komponenten konfiguriert und erstellt, die die bidirektionale Kommunikation zwischen einem von Ihnen verwalteten Virtual Private Cloud-Netzwerk (VPC) und einem von Apigee verwalteten VPC-Netzwerk ermöglichen. Nach Abschluss der ersten Schritte zur Bereitstellung sind die beiden VPCs vorhanden. Sie können aber nicht miteinander kommunizieren. Weitere Konfigurationen sind für die bidirektionale Kommunikation erforderlich. Siehe Abbildung 6.
Um die Kommunikation zwischen VPCs zu ermöglichen, verwenden wir Private Service Connect (PSC), um Northbound-Traffic an Apigee und Southbound-Traffic an Zieldienste weiterzuleiten, die in Ihren Google Cloud-Projekten ausgeführt werden.
PSC ermöglicht eine private Verbindung zwischen einem Dienstersteller (Apigee) und einem Dienstnutzer (einem oder mehreren anderen Cloud-Projekten, über die Sie die Kontrolle haben). Bei dieser Methode (Abbildung 7) werden Anfragen entweder über einen globalen externen Load Balancer oder einen regionalen externen Load Balancer an einen einzelnen Zugriffspunkt namens Dienstanhang weitergeleitet.
Um Apigee privat mit einem Backend-Ziel zu verbinden, müssen Sie zwei Entitäten erstellen: einen Dienstanhang in dem VPC-Netzwerk, in dem das Ziel bereitgestellt wird, und einen Endpunktanhang in der Apigee-VPC. Mit diesen beiden Entitäten kann Apigee eine Verbindung zum Zieldienst herstellen. Weitere Informationen finden Sie unter Southbound-Netzwerkmuster.
Die Schritte zur Bereitstellung von Apigee mit PSC (ohne VPC-Peering) werden unter Bereitstellung über die Befehlszeile ohne VPC-Peering beschrieben.
