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 Amazon ECS Amazon-Diensten in einem VPC
Mithilfe von ECS Amazon-Aufgaben in a 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ßerhalbVPC, miteinander kommunizieren können. Es gibt verschiedene Ansätze zur Erleichterung der Kommunikation, die alle unterschiedliche Vor- und Nachteile haben.
Service Connect verwenden
Wir empfehlen Service Connect, das eine ECS Amazon-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, ECS verwaltet Amazon 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, die Ausführung eines Agenten in jeder Aufgabe, der so konfiguriert ist, dass er die Namen erkennt. 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 verwenden zu können.
Änderungen treten nur während der Bereitstellung auf
Sie stellen die vollständige Konfiguration in jeder Dienst- und 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 der 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 maximal TTL lange dauern, bis alle Clients den neuen Dienst verwenden. Mit Service Connect aktualisiert die Client-Bereitstellung die Konfiguration, indem sie die Client-Tasks ersetzt. Sie können den Deployment Circuit Breaker und andere Bereitstellungskonfigurationen so konfigurieren, dass sie Service Connect-Änderungen genauso beeinflussen wie jede andere Bereitstellung.
Verwenden von Service Discovery
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 verwendenECS. Mithilfe von Service Discovery ECS synchronisiert Amazon 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 Dienste im Amazon VPC können diesen DNS Hostnamen verwenden, um Traffic mithilfe seiner internen IP-Adresse direkt an einen anderen Container zu senden. Weitere Informationen finden Sie unter Service Discovery.
Im obigen Diagramm gibt es drei Dienste. service-a-local
hat einen Container und kommuniziert mitservice-b-local
, der zwei Container hat. service-b-local
muss auch mit kommunizierenservice-c-local
, der einen Container hat. Jeder Container in allen drei Diensten kann anhand der internen DNS Namen von AWS Cloud Map die internen IP-Adressen eines Containers aus dem nachgeschalteten Dienst ermitteln, 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 Verkehr 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
Datensätzen, 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 Portzuordnungen dazu, dass den Containern nach dem Zufallsprinzip Portnummern für diese einzelne IP-Adresse zugewiesen werden. Zu diesem Zeitpunkt reicht ein A
Datensatz für die Diensterkennung nicht mehr aus. Sie müssen auch einen SRV
Datensatz verwenden. Dieser Datensatztyp kann sowohl IP-Adressen als auch Portnummern 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 Dienst eine eigene Sicherheitsgruppe haben. Sie können diese Sicherheitsgruppe so konfigurieren, dass eingehende Verbindungen nur von den spezifischen Upstream-Diensten zugelassen werden, die mit diesem Dienst kommunizieren müssen.
Der Hauptnachteil der direkten service-to-service Kommunikation mithilfe von Service Discovery besteht darin, dass Sie zusätzliche Logik implementieren müssen, um Wiederholungsversuche durchzuführen und Verbindungsfehler zu beheben. DNSDatensätze haben einen Zeitraum time-to-live (TTL), der steuert, 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 Datensatzes abrufen können. Daher löst Ihre Anwendung den DNS Datensatz möglicherweise so auf, 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 Sie einen 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 Ihrem System VPC und ist nur für Dienste innerhalb Ihres Computers zugänglich. VPC
Der Load Balancer sorgt für eine hohe Verfügbarkeit, indem er redundante Ressourcen in jedem Subnetz bereitstellt. Wenn ein Container von mit einem Container von kommunizieren serviceA
mussserviceB
, ö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 Diensten.
Wenn ein Container von serviceB
stoppt, kann der Load Balancer diesen Container aus dem Pool entfernen. Der Load Balancer führt außerdem Integritätsprüfungen für jedes Downstream-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 Downstream-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 der Aufwand für die Bezahlung des Load Balancers und die Menge des Datenverkehrs, der über den Load Balancer fließt, verursacht werden.
Sie können jedoch die Gemeinkosten reduzieren, indem sich mehrere Dienste einen Load Balancer teilen. Dies ist besonders für REST Dienste geeignet, die einen Application Load Balancer verwenden. Sie können pfadbasierte Routing-Regeln erstellen, die den Datenverkehr an verschiedene Dienste weiterleiten. Kann beispielsweise an einen /api/user/*
Container weiterleiten, der Teil des user
Dienstes ist, wohingegen /api/order/*
die Weiterleitung an den zugehörigen order
Dienst möglich ist. Mit diesem Ansatz zahlen Sie nur für einen Application Load Balancer und haben einen einheitlichen URL für IhrenAPI. Sie können den Datenverkehr jedoch auf verschiedene Microservices im Backend aufteilen.