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.
Vernetzung zwischen Amazon ECS-Services in einer VPC
Mithilfe von 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.
Service Connect verwenden
Wir empfehlen Amazon ECS 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 ECS-Diensten im selben Cluster oder in anderen Clustern herzustellen, auch zwischen VPCs im selben AWS-Region. Weitere Informationen finden Sie unter Amazon ECS Service Connect im Amazon Elastic Container Service Developer Guide.
Wenn Sie Service Connect verwenden, verwaltet 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, die Ausführung eines Agenten in jeder Aufgabe, die so konfiguriert ist, dass sie 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 ECS-Service- und Aufgabendefinition bereit. 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 as Service Discovery 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 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 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 Dienste in der 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 Amazon Elastic Container Service Developer Guide.
Im obigen Diagramm gibt es drei Dienste. serviceAhat einen Container und kommuniziert mitserviceB, der zwei Container hat. serviceBmuss auch mit kommunizierenserviceC, 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-Dienst zu 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 A DNS-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 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. DNS-Einträge haben einen Zeitraum time-to-live (TTL), der bestimmt, wie lange sie zwischengespeichert werden. Es dauert einige Zeit, bis der DNS-Eintrag aktualisiert ist und der Cache abläuft, sodass Ihre Anwendungen die neueste Version des DNS-Eintrags abrufen können. Daher löst Ihre Anwendung den DNS-Eintrag 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 Ihrer VPC und ist nur für Dienste 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 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 die IP-Adressen der Aufgaben im awsvpc Netzwerkmodus sowie erweiterte Kombinationen von IP-Adressen und Ports im bridge Netzwerkmodus verfolgen. Es verteilt den Verkehr gleichmäßig auf alle Kombinationen von IP-Adressen und Ports, auch wenn mehrere Container tatsächlich auf derselben Amazon EC2 EC2-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. 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.
