Questo blog fa parte della serie in cui discutiamo 101 concetti di Ground Zero per un pubblico che ha una conoscenza iniziale limitata. Questo articolo fa parte della serie di livello intermedio poiché implica la comprensione del modello Ambassador , utilizzato principalmente come servizio proxy indipendente in esecuzione in co-localizzazione con l'applicazione/client aziendale.

Alcuni dei blog precedenti nella serie 101 sono i seguenti:

API 101
Comunicazione asincrona 101 Database 101 Progettazione di database 101 Strategie di distribuzione 101

Cos'è l'Ambassador Pattern?

Ambassador è un caso speciale del modello ide -car che scarica le funzionalità di connettività client comuni come monitoraggio, registrazione, routing, sicurezza, resilienza utilizzando un servizio/contenitore comune co-locato (in caso di implementazioni basate su Kubernetes/Docker). Un servizio Ambassador funge da soluzione proxy riutilizzabile per servizi legacy scritti in più lingue e framework offrendo funzionalità L7 come tentativi HTTP, pattern di interruttori automatici, modifica delle intestazioni delle richieste ecc. Le versioni e l'infrastruttura di Ambassador possono essere rilasciate e ridimensionate indipendentemente dall'azienda applicazioni/contenitori, rendendolo una scelta idonea per chiudere le esigenze non funzionali dei Domini Business.

Ambasciatore come SideCar

Flusso di sequenza

1. Il contenitore dell'applicazione invia la richiesta al Servizio B/Servizio C remoto tramite il proxy Ambassador
2. Il Proxy SideCar aggiunge informazioni di traccia alle intestazioni della richiesta. Crittografa anche la richiesta aggiungendo certificati per TLS reciproco . Inoltre, inizia a misurare la latenza della richiesta.
3. Il Servizio remoto B/Servizio C riceve la richiesta e convalida le intestazioni della richiesta prima di inviare un messaggio di risposta.
4. L'auto laterale Ambassador riceve la risposta e registra la latenza della richiesta.
5. Il contenitore dell'applicazione riceve la risposta finale.

1. Quando i servizi legacy sono costruiti in più lingue e il tempo e il costo di sviluppo per l'aggiunta di funzionalità di rete/routing per client sono notevolmente elevati rispetto all'aggiunta a una comune soluzione basata su proxy.
2. Quando i comuni modelli di architettura non funzionali come l' interruzione del circuito, la strumentazione dell'applicazione, la limitazione della velocità hanno politiche indipendenti dall'applicazione client.
3. Applicazione con database/livelli di messaggistica partizionati e più istanze/nodi dell'infrastruttura in esecuzione, di conseguenza la necessità di atrarre la configurazione utilizzando un componente comune.

Limitazioni

1. Le richieste di applicazioni che hanno requisiti di latenza critici e andata e ritorno end-2-end possono essere influenzate dall'aggiunta di un proxy side-car
2. Le applicazioni che hanno le esigenze di connettività profondamente integrate con il codice/lingua del client e l'isolamento delle richieste tramite proxy non è scalabile.

Abbiamo discusso le basi del modello Ambassador, che è un modello di progettazione popolare che aiuta a modernizzare le esigenze delle applicazioni legacy senza creare una soluzione integrata basata su mesh di servizi end-2-end. Nel mondo Kubernetes, il proxy ambassador può essere distribuito utilizzando come file manifest di servizio e ridimensionato insieme ai pod dell'applicazione

Per feedback, invia un messaggio a amit[dot]894[at]gmail[dot]com o contatta uno qualsiasi dei link su https://about.me/amit_raj .