Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Le migliori pratiche per connettere ECS i servizi Amazon in un VPC
Utilizzando Amazon ECS Tasks in aVPC, puoi suddividere applicazioni monolitiche in parti separate che possono essere distribuite e scalate indipendentemente in un ambiente sicuro. Questa architettura si chiama architettura orientata ai servizi () o microservizi. SOA Tuttavia, può essere difficile assicurarsi che tutte queste parti, sia all'interno che all'esterno di unVPC, possano comunicare tra loro. Esistono diversi approcci per facilitare la comunicazione, tutti con vantaggi e svantaggi diversi.
Utilizzo di Service Connect
Consigliamo Service Connect, che fornisce la ECS configurazione Amazon per l'individuazione dei servizi, la connettività e il monitoraggio del traffico. Con Service Connect, le applicazioni possono utilizzare nomi brevi e porte standard per connettersi ai servizi nello stesso cluster, VPCs in altri cluster, anche all'interno della stessa regione. Per ulteriori informazioni, consulta Amazon ECS Service Connect.
Quando usi Service Connect, Amazon ECS gestisce tutte le parti del service discovery: crea i nomi che possono essere scoperti, gestisce dinamicamente le voci per ogni attività all'inizio e all'interruzione delle attività, esegue un agente in ogni attività configurato per scoprire i nomi. L'applicazione può cercare i nomi utilizzando la funzionalità standard per DNS i nomi e stabilendo connessioni. Se l'applicazione lo fa già, non è necessario modificarla per utilizzare Service Connect.
Le modifiche avvengono solo durante le distribuzioni
Fornisci la configurazione completa all'interno di ogni definizione di servizio e attività. Amazon ECS gestisce le modifiche a questa configurazione in ogni distribuzione del servizio, per garantire che tutte le attività di una distribuzione si comportino nello stesso modo. Ad esempio, un problema comune di DNS as service discovery è il controllo di una migrazione. Se si modifica un DNS nome in modo che punti ai nuovi indirizzi IP sostitutivi, potrebbe essere necessario il TTL tempo massimo prima che tutti i client inizino a utilizzare il nuovo servizio. Con Service Connect, la distribuzione del client aggiorna la configurazione sostituendo le attività del client. È possibile configurare l'interruttore automatico di distribuzione e altre configurazioni di distribuzione per influire sulle modifiche di Service Connect allo stesso modo di qualsiasi altra distribuzione.
Utilizzo del rilevamento dei servizi
Un altro approccio alla service-to-service comunicazione è la comunicazione diretta tramite il service discovery. In questo approccio, puoi utilizzare l'integrazione del AWS Cloud Map service discovery con AmazonECS. Utilizzando service discovery, Amazon ECS sincronizza l'elenco delle attività avviate con AWS Cloud Map, che mantiene un DNS nome host che si risolve negli indirizzi IP interni di una o più attività di quel particolare servizio. Altri servizi di Amazon VPC possono utilizzare questo DNS nome host per inviare traffico direttamente a un altro contenitore utilizzando il suo indirizzo IP interno. Per ulteriori informazioni, consulta Individuazione dei servizi.
Nel diagramma precedente, sono presenti tre servizi. service-a-localha un contenitore e comunica conservice-b-local, che ha due contenitori. service-b-localdeve comunicare anche conservice-c-local, che ha un contenitore. Ogni contenitore di tutti e tre questi servizi può utilizzare i DNS nomi interni di AWS Cloud Map per trovare gli indirizzi IP interni di un contenitore dal servizio a valle con cui deve comunicare.
Questo approccio alla service-to-service comunicazione offre una bassa latenza. A prima vista, è anche semplice in quanto non ci sono componenti aggiuntivi tra i contenitori. Il traffico viaggia direttamente da un container all'altro.
Questo approccio è adatto quando si utilizza la modalità awsvpc di rete, in cui ogni attività ha il proprio indirizzo IP univoco. La maggior parte dei software supporta solo l'uso di DNS A record, che si risolvono direttamente in indirizzi IP. Quando si utilizza la modalità di awsvpc rete, l'indirizzo IP per ogni operazione è un A record. Tuttavia, se utilizzi la modalità di bridge rete, è possibile che più contenitori condividano lo stesso indirizzo IP. Inoltre, le mappature dinamiche delle porte fanno sì che ai contenitori vengano assegnati in modo casuale i numeri di porta su quel singolo indirizzo IP. A questo punto, un A record non è più sufficiente per l'individuazione del servizio. È inoltre necessario utilizzare un SRV record. Questo tipo di record può tenere traccia sia degli indirizzi IP che dei numeri di porta, ma richiede la configurazione appropriata delle applicazioni. Alcune applicazioni predefinite utilizzate potrebbero non supportare SRV i record.
Un altro vantaggio della modalità di awsvpc rete è che si dispone di un gruppo di sicurezza unico per ogni servizio. È possibile configurare questo gruppo di sicurezza per consentire le connessioni in entrata solo dai servizi upstream specifici che devono comunicare con quel servizio.
Lo svantaggio principale della service-to-service comunicazione diretta tramite Service Discovery è che è necessario implementare una logica aggiuntiva per ripetere i tentativi e gestire gli errori di connessione. DNSi record hanno un periodo time-to-live (TTL) che controlla per quanto tempo vengono memorizzati nella cache. L'aggiornamento del DNS record e la scadenza della cache richiedono del tempo per consentire alle applicazioni di recuperare la versione più recente del DNS record. Pertanto, l'applicazione potrebbe finire per risolvere il DNS record in modo che punti a un altro contenitore che non è più presente. L'applicazione deve gestire i nuovi tentativi e disporre di una logica per ignorare i backend non validi.
Utilizzo di un sistema di bilanciamento del carico interno
Un altro approccio alla service-to-service comunicazione consiste nell'utilizzare un sistema di bilanciamento del carico interno. Un sistema di bilanciamento del carico interno esiste interamente all'interno dell'VPCazienda ed è accessibile solo ai servizi interni. VPC
Il load balancer mantiene un'elevata disponibilità distribuendo risorse ridondanti in ogni sottorete. Quando un container from serviceA deve comunicare con un container daserviceB, apre una connessione al load balancer. Il load balancer apre quindi una connessione a un container da. service B Il load balancer funge da luogo centralizzato per la gestione di tutte le connessioni tra ciascun servizio.
Se un container si serviceB ferma, il load balancer può rimuoverlo dal pool. Il load balancer esegue inoltre controlli di integrità su ogni target a valle del relativo pool e può rimuovere automaticamente gli obiettivi danneggiati dal pool fino a quando non tornano a funzionare di nuovo. Non è più necessario che le applicazioni siano consapevoli del numero di container a valle presenti. Si limitano ad aprire le proprie connessioni al sistema di bilanciamento del carico.
Questo approccio è vantaggioso per tutte le modalità di rete. Il load balancer può tenere traccia degli indirizzi IP delle attività quando si utilizza la modalità di awsvpc rete, nonché delle combinazioni più avanzate di indirizzi IP e porte quando si utilizza la bridge modalità di rete. Distribuisce in modo uniforme il traffico su tutte le combinazioni di indirizzi IP e porte, anche se diversi container sono effettivamente ospitati sulla stessa EC2 istanza Amazon, solo su porte diverse.
L'unico svantaggio di questo approccio è il costo. Per garantire un'elevata disponibilità, il sistema di bilanciamento del carico deve disporre di risorse in ogni zona di disponibilità. Ciò comporta costi aggiuntivi a causa del sovraccarico dovuto al pagamento del load balancer e alla quantità di traffico che attraversa il load balancer.
Tuttavia, è possibile ridurre i costi generali facendo in modo che più servizi condividano un sistema di bilanciamento del carico. Ciò è particolarmente adatto per REST i servizi che utilizzano un Application Load Balancer. È possibile creare regole di routing basate sui percorsi che indirizzano il traffico verso servizi diversi. Ad esempio, /api/user/* potrebbe indirizzare verso un contenitore che fa parte del user servizio, mentre /api/order/* potrebbe indirizzare verso il servizio associatoorder. Con questo approccio, pagherai solo per un Application Load Balancer e ne avrai uno coerente URL per te. API Tuttavia, puoi suddividere il traffico verso vari microservizi sul backend.
