Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Bewährte Methoden für die Verbindung von Amazon-ECS-Services in einer VPC
Mit Amazon-ECS-Aufgaben in einer VPC können Sie monolithische Anwendungen in separate Teile aufteilen, die unabhängig voneinander in einer sicheren Umgebung bereitgestellt und skaliert werden können. Diese Architektur wird als serviceorientierte Architektur (SOA) oder Microservices bezeichnet. Es kann jedoch schwierig sein, sicherzustellen, dass all diese Teile, sowohl innerhalb als auch außerhalb einer VPC, miteinander kommunizieren können. Es gibt verschiedene Ansätze zur Erleichterung der Kommunikation, die alle unterschiedliche Vor- und Nachteile haben.
Verwendung von Service Connect
Wir empfehlen Service Connect, das eine Amazon-ECS-Konfiguration für Serviceerkennung, Konnektivität und Verkehrsüberwachung bietet. Mit Service Connect können Ihre Anwendungen Kurznamen und Standardports verwenden, um eine Verbindung zu Diensten im selben Cluster oder in anderen Clustern herzustellen, auch mit anderen VPCs in derselben Region. Weitere Informationen finden Sie unter Amazon ECS Service Connect.
Wenn Sie Service Connect verwenden, verwaltet Amazon ECS alle Teile der Serviceerkennung: die Erstellung der Namen, die erkannt werden können, die dynamische Verwaltung von Einträgen für jede Aufgabe, wenn die Aufgaben gestartet und beendet werden, das Ausführen eines Agenten in jeder Aufgabe, der für die Erkennung der Namen konfiguriert ist. Ihre Anwendung kann die Namen mithilfe der Standardfunktionen für DNS-Namen und das Herstellen von Verbindungen nachschlagen. Wenn Ihre Anwendung dies bereits tut, müssen Sie Ihre Anwendung nicht ändern, um Service Connect zu verwenden.
Änderungen treten nur während der Bereitstellung auf.
Sie stellen die vollständige Konfiguration in jedem Service und jeder Aufgabendefinition bereit. Amazon ECS verwaltet Änderungen an dieser Konfiguration in jeder Servicebereitstellung, um sicherzustellen, dass sich alle Aufgaben in einer Bereitstellung auf die gleiche Weise verhalten. Ein häufiges Problem bei DNS als Serviceerkennung ist beispielsweise die Steuerung einer Migration. Wenn Sie einen DNS-Namen so ändern, dass er auf die neuen Ersatz-IP-Adressen verweist, kann es die maximale TTL-Zeit dauern, bis alle Clients den neuen Service verwenden. Mit Service Connect aktualisiert die Client-Bereitstellung die Konfiguration, indem sie die Client-Aufgaben ersetzt. Sie können den Bereitstellungs-Schutzschalter und andere Bereitstellungskonfigurationen so konfigurieren, dass sie Service-Connect-Änderungen genauso beeinflussen wie jede andere Bereitstellung.
Verwendung der Serviceerkennung
Ein weiterer service-to-service Kommunikationsansatz ist die direkte Kommunikation mithilfe von Service Discovery. Bei diesem Ansatz können Sie die AWS Cloud Map Service Discovery-Integration mit Amazon ECS verwenden. Mithilfe von Service Discovery synchronisiert Amazon ECS die Liste der gestarteten Aufgaben mit AWS Cloud Map, das einen DNS-Hostnamen verwaltet, der in die internen IP-Adressen einer oder mehrerer Aufgaben von diesem bestimmten Service aufgelöst wird. Andere Services in der Amazon VPC können diesen DNS-Hostnamen verwenden, um Datenverkehr unter Verwendung der internen IP-Adresse direkt an einen anderen Container zu senden. Weitere Informationen finden Sie unter Serviceerkennung.
Im obigen Diagramm gibt es drei Services. service-a-local hat einen Container und kommuniziert mit service-b-local, der zwei Container hat. service-b-local muss auch mit service-c-local kommunizieren, der einen Container hat. Jeder Container in allen drei Diensten kann die internen DNS-Namen von verwenden, AWS Cloud Map um die internen IP-Adressen eines Containers aus dem Downstream-Service zu finden, mit dem er kommunizieren muss.
Dieser service-to-service Kommunikationsansatz bietet eine geringe Latenz. Auf den ersten Blick ist es auch einfach, da sich zwischen den Containern keine zusätzlichen Komponenten befinden. Der Datenverkehr wird direkt von einem Container zum anderen Container geleitet.
Dieser Ansatz eignet sich für den awsvpc-Netzwerkmodus, in dem jede Aufgabe ihre eigene eindeutige IP-Adresse hat. Die meiste Software unterstützt nur die Verwendung von DNS-A-Einträgen, die direkt in IP-Adressen aufgelöst werden. Bei Verwendung des awsvpc-Netzwerkmodus handelt es sich bei den IP-Adressen für jede Aufgabe um einen A-Datensatz. Wenn Sie jedoch den bridge-Netzwerkmodus verwenden, können sich mehrere Container dieselbe IP-Adresse teilen. Darüber hinaus führen dynamische Port-Zuordnungen dazu, dass den Containern nach dem Zufallsprinzip Port-Nummern für diese einzelne IP-Adresse zugewiesen werden. Zu diesem Zeitpunkt reicht ein A-Datensatz für die Serviceerkennung nicht mehr aus. Sie müssen auch einen SRV-Datensatz verwenden. Dieser Datensatztyp kann sowohl IP-Adressen als auch Port-Nummern nachverfolgen, erfordert jedoch, dass Sie die Anwendungen entsprechend konfigurieren. Einige vorgefertigte Anwendungen, die Sie verwenden, unterstützen möglicherweise keine SRV-Datensätze.
Ein weiterer Vorteil des awsvpc-Netzwerkmodus besteht darin, dass Sie für jeden Service eine eigene Sicherheitsgruppe haben. Sie können diese Sicherheitsgruppe so konfigurieren, dass eingehende Verbindungen nur von den spezifischen vorgelagerten Services zugelassen werden, die mit diesem Service kommunizieren müssen.
Der Hauptnachteil der direkten service-to-service Kommunikation mithilfe der Diensterkennung besteht darin, dass Sie zusätzliche Logik implementieren müssen, um Wiederholungsversuche durchzuführen und Verbindungsfehler zu beheben. DNS-Einträge haben einen Zeitraum time-to-live (TTL), der bestimmt, wie lange sie zwischengespeichert werden. Es dauert einige Zeit, bis der DNS-Datensatz aktualisiert ist und der Cache abläuft, sodass Ihre Anwendungen die neueste Version des DNS-Datensatz abrufen können. Es kann also sein, dass Ihre Anwendung den DNS-Datensatz so auflöst, dass er auf einen anderen Container verweist, der nicht mehr vorhanden ist. Ihre Anwendung muss Wiederholungsversuche verarbeiten und über eine Logik verfügen, um fehlerhafte Backends zu ignorieren.
Verwenden eines internen Load Balancer
Ein anderer service-to-service Kommunikationsansatz ist die Verwendung eines internen Load Balancers. Ein interner Load Balancer befindet sich vollständig in Ihrer VPC und ist nur für Services innerhalb Ihrer VPC zugänglich.
Der Load Balancer sorgt für eine hohe Verfügbarkeit, indem er redundante Ressourcen in jedem Subnetz bereitstellt. Wenn ein Container von serviceA mit einem Container von serviceB kommunizieren muss, öffnet er eine Verbindung zum Load Balancer. Der Load Balancer öffnet dann eine Verbindung zu einem Container von service B. Der Load Balancer dient als zentraler Ort für die Verwaltung aller Verbindungen zwischen den einzelnen Services.
Wenn ein Container von serviceB stoppt, kann der Load Balancer diesen Container aus dem Pool entfernen. Der Load Balancer führt außerdem Zustandsprüfungen für jedes nachgelagerte Ziel in seinem Pool durch und kann fehlerhafte Ziele automatisch aus dem Pool entfernen, bis sie wieder fehlerfrei sind. Die Anwendungen müssen nicht mehr wissen, wie viele nachgelagerte Container es gibt. Sie öffnen einfach ihre Verbindungen zum Load Balancer.
Dieser Ansatz ist für alle Netzwerkmodi von Vorteil. Der Load Balancer kann im awsvpc-Netzwerkmodus die IP-Adressen der Aufgaben sowie im bridge-Netzwerkmodus erweiterte Kombinationen von IP-Adressen und Ports verfolgen. Es verteilt den Verkehr gleichmäßig auf alle Kombinationen von IP-Adressen und Ports, auch wenn mehrere Container tatsächlich auf derselben EC2 Amazon-Instance gehostet werden, nur auf verschiedenen Ports.
Der einzige Nachteil dieses Ansatzes sind die Kosten. Um hochverfügbar zu sein, muss der Load Balancer über Ressourcen in jeder Availability Zone verfügen. Dies führt zu zusätzlichen Kosten, da Betriebskosten für den Load Balancer und die Menge des Datenverkehrs, der über den Load Balancer fließt, verursacht werden.
Sie können jedoch die Gemeinkosten reduzieren, indem sich mehrere Services einen Load Balancer teilen. Dies ist besonders für REST-Services geeignet, die einen Application Load Balancer verwenden. Sie können pfadbasierte Routing-Regeln erstellen, die den Datenverkehr an verschiedene Services weiterleiten. Zum Beispiel kann /api/user/* an einen Container weiterleiten, der Teil des user-Services ist, wohingegen /api/order/* an den zugeordneten order-Service weiterleiten könnte. Bei diesem Ansatz zahlen Sie nur für einen Application Load Balancer und haben eine einheitliche URL für Ihre API. Sie können den Datenverkehr jedoch auf verschiedene Microservices im Backend aufteilen.
