Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Creare servizi helper che inviano richieste di rete per conto di un servizio consumer o di un'applicazione. Si pensi a un servizio di ambasciatore come un proxy out-of-process che è posizionato insieme al client.
Usare il modello Ambassador per eseguire l'offload di attività comuni di connettività client, ad esempio monitoraggio, registrazione, routing, sicurezza come TLS (Transport Layer Security) e modelli di resilienza in modo indipendente dal linguaggio. Estendere le funzionalità di rete delle applicazioni legacy o altre applicazioni difficili da modificare usando il modello Ambassador. I team specializzati possono anche usare il modello Ambassador per implementare tali funzionalità.
Contesto e problema
Le applicazioni basate sul cloud resilienti richiedono funzionalità come interruzione del circuito, routing, misurazione e monitoraggio e aggiornamenti della configurazione correlati alla rete. Se il team di sviluppo non gestisce il codice o non può modificarlo facilmente, potrebbe essere difficile o persino impossibile aggiornare applicazioni legacy o librerie di codice esistenti per aggiungere queste funzionalità.
Le chiamate di rete potrebbero anche richiedere una configurazione sostanziale per la connessione, l'autenticazione e l'autorizzazione. Quando più applicazioni usano queste chiamate in linguaggi e framework diversi, è necessario configurare le chiamate separatamente per ogni istanza. Un team centrale all'interno dell'organizzazione potrebbe dover gestire le funzionalità di rete e sicurezza. Con una base di codice di grandi dimensioni, può essere rischioso per il team aggiornare il codice dell'applicazione con cui non ha familiarità.
Soluzione
Inserire framework client e librerie in un processo esterno che funge da proxy tra l'applicazione e i servizi esterni. Per fornire il controllo sulle funzionalità di routing, resilienza e sicurezza e per evitare restrizioni di accesso correlate all'host, distribuire il proxy nello stesso ambiente host dell'applicazione. Usare il modello ambassador per standardizzare ed estendere la strumentazione. Il proxy può monitorare le metriche delle prestazioni, ad esempio la latenza o l'utilizzo delle risorse, nello stesso ambiente host dell'applicazione.
Diagramma che mostra un'applicazione client e un proxy ambassador che si collocano nello stesso host.Diagram that shows a client application and an ambassador proxy colocated on the same host. L'applicazione client invia richieste all'ambasciatore anziché chiamare direttamente i servizi esterni. L'ambasciatore inoltra tali richieste al servizio remoto. Le risposte dal servizio remoto transitano tramite l'ambasciatore e tornano all'applicazione client.
È possibile gestire le funzionalità caricate all'ambasciatore indipendentemente dall'applicazione. È possibile aggiornare e modificare l'ambassador senza disturbare la funzionalità legacy dell'applicazione. I team specializzati separati possono anche implementare e gestire funzionalità di sicurezza, rete o autenticazione spostate all'ambasciatore.
Puoi distribuire i servizi ambassador come sidecar per accompagnare il ciclo di vita di un'applicazione o servizio che consuma. In alternativa, se più processi separati in un host comune condividono un ambasciatore, è possibile distribuirlo come daemon o servizio Di Windows. Se il servizio di consumo è containerizzato, creare un container per l'ambasciatore come contenitore separato nello stesso host e configurare correttamente i collegamenti per la comunicazione.
Problemi e considerazioni
Quando si decide come implementare questo modello, tenere presente quanto segue:
Il proxy aggiunge un sovraccarico di latenza. Valutare se una libreria client che l'applicazione richiama direttamente è un approccio migliore.
Prendere in considerazione l'impatto possibile dell'inclusione delle funzionalità generalizzate nel proxy. Ad esempio, l'ambasciatore potrebbe gestire i tentativi, ma questo approccio potrebbe non essere sicuro a meno che tutte le operazioni non siano idempotenti.
Si consideri un meccanismo che il client può usare per passare un contesto al proxy e tornare al client. Ad esempio, includere intestazioni di richiesta HTTP per rifiutare esplicitamente il tentativo o specificare il numero massimo di tentativi da ripetere.
Si consideri come creare un pacchetto e distribuire il proxy.
Valutare se usare una singola istanza condivisa per tutti i client o un'istanza per ogni client.
Quando usare questo modello
Usare questo modello quando:
È necessario creare un set comune di funzionalità di connettività client per più linguaggi o framework.
È necessario delegare i problemi di connettività trasversali del client agli sviluppatori delle infrastrutture o ad altri team più specializzati.
È necessario supportare i requisiti di connettività cloud o cluster in un'applicazione legacy o in un'applicazione difficile da modificare.
È necessario supportare protocolli o modelli di connettività che gateway API, mesh di servizi o controlli di ingresso e uscita standard non gestiscono facilmente.
Questo modello potrebbe non essere adatto quando:
La latenza delle richieste di rete è fondamentale. Un proxy introduce un sovraccarico minimo e questo sovraccarico potrebbe influire sull'applicazione.
Le funzionalità di connettività client vengono utilizzate da un'unica lingua. In tal caso, un'opzione migliore potrebbe essere una libreria client distribuita ai team di sviluppo come pacchetto.
Le funzionalità di connettività non possono essere generalizzate e queste funzionalità richiedono un'integrazione più approfondita con l'applicazione client.
La piattaforma dell'applicazione supporta soluzioni predefinite, come un service mesh, per gestire le funzionalità di mutuo TLS (mTLS), la gestione del traffico e le funzionalità dei criteri. Usare queste soluzioni invece di creare una soluzione ambassador personalizzata.
Progettazione del carico di lavoro
Valutare come usare il modello Ambassador nella progettazione di un carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. La tabella seguente fornisce indicazioni su come questo modello supporta gli obiettivi di ogni pilastro.
| Pilastro | Come questo modello supporta gli obiettivi di pilastro |
|---|---|
| decisioni di progettazione dell'affidabilità consentono al carico di lavoro di diventare resiliente a un malfunzionamento e assicurano che ripristini a uno stato completamente funzionante dopo che si verifica un guasto. | Questo modello introduce un punto di mediazione delle comunicazioni di rete, in modo da poter aggiungere modelli di affidabilità alla comunicazione di rete, come ritenti o buffering. - RE:07 Autoconservazione |
| Le decisioni di progettazione della sicurezza consentono di garantire la riservatezza, l'integrità e la disponibilità dei dati e dei sistemi del carico di lavoro. | Con questo modello, è possibile implementare la sicurezza nelle comunicazioni di rete che il client non può gestire direttamente. - Controlli di rete SE:06 - SE:07 Crittografia |
Se questo modello introduce compromessi all'interno di un pilastro, considerarli contro gli obiettivi degli altri pilastri.
Esempio
Il diagramma seguente mostra un'applicazione che effettua una richiesta a un servizio remoto tramite un proxy Ambassador. L'ambasciatore fornisce routing, interruzione del circuito e registrazione. Chiama il servizio remoto e quindi restituisce la risposta all'applicazione client.
Diagramma che mostra un'applicazione client che invia una richiesta a un proxy ambassador. L'applicazione invia una richiesta al servizio remoto tramite un proxy ambassador. L'ambasciatore determina la posizione dei servizi remoti e instrada la richiesta in modo appropriato. L'ambasciatore controlla lo stato dell'interruttore automatico e arricchisce le intestazioni delle richieste con informazioni di tracciamento. L'ambasciatore inizia a misurare la latenza della richiesta. L'ambasciatore crittografa e invia la richiesta usando l'autenticazione basata su certificato reciproca. Il servizio remoto riceve la richiesta e invia la risposta. L'ambasciatore registra la latenza della richiesta. L'ambasciatore restituisce la risposta al cliente. L'applicazione riceve la risposta.
Negli ambienti containerizzati, l'ambassador viene eseguito come sidecar accanto al container dell'applicazione. Negli ambienti non vincolati, è necessario implementarlo come processo locale o servizio Windows nello stesso host.