Condividi tramite

Modello Sidecar

Distribuire i componenti dell'applicazione in un processo o in un contenitore separato dall'applicazione principale per fornire isolamento e incapsulamento. Questo modello consente di creare applicazioni da diversi componenti e tecnologie.

Come un sidecar per moto, questi componenti si collegano a un'applicazione padre e condividono lo stesso ciclo di vita, in modo da crearli e disattivarli insieme. Questo modello è noto anche come modello Sidekick e supporta la scomposizione dell'applicazione.

Contesto e problema

Le applicazioni e i servizi spesso richiedono funzionalità correlate, ad esempio il monitoraggio, la registrazione, la configurazione e i servizi di rete. È possibile implementare queste attività periferiche come componenti o servizi separati.

I componenti strettamente integrati vengono eseguiti nello stesso processo e usano in modo efficiente le risorse condivise, ma non hanno isolamento. Un'interruzione in un componente può influire sull'intera applicazione. Richiedono anche l'implementazione nel linguaggio dell'applicazione padre, che crea interdipendenza.

Se si scompone l'applicazione in servizi, è possibile compilare ogni servizio usando linguaggi e tecnologie diversi. Questo approccio offre maggiore flessibilità. Tuttavia, ogni componente ha le proprie dipendenze e richiede librerie specifiche del linguaggio per accedere alla piattaforma e alle risorse condivise. Quando si distribuiscono queste funzionalità come servizi separati, si aggiunge la latenza. Anche il codice e le dipendenze specifiche del linguaggio aumentano la complessità per l'hosting e la distribuzione.

Soluzione

Distribuire un set coeso di attività insieme all'applicazione primaria in un processo o un contenitore separato. Questo approccio offre un'interfaccia coerente per i servizi della piattaforma in tutti i linguaggi.

Diagramma che mostra il modello Sidecar.

Un servizio sidecar si connette all'applicazione senza essere parte di essa e viene distribuito insieme a essa. Ogni istanza dell'applicazione ottiene la propria istanza sidecar che condivide il suo ciclo di vita.

Il modello Sidecar offre i vantaggi seguenti:

  • Indipendenza della lingua: Il sidecar viene eseguito indipendentemente dall'ambiente di runtime e dal linguaggio di programmazione dell'applicazione primaria. È possibile usare un'implementazione sidecar tra applicazioni scritte in linguaggi diversi.

  • Accesso alle risorse condivise: Il sidecar può accedere alle stesse risorse dell'applicazione primaria. Ad esempio, il sidecar può monitorare le risorse di sistema usate da entrambi i componenti.

  • Bassa latenza: La prossimità del sidecar all'applicazione primaria riduce al minimo la latenza di comunicazione.

  • Estendibilità avanzata: È possibile estendere le applicazioni che non dispongono di meccanismi di estendibilità nativi collegando un sidecar come processo separato nello stesso host o nello stesso sottocontenitore.

L'implementazione più comune di questo modello usa contenitori, detti anche contenitori sidecar o contenitori sidekick.

Problemi e considerazioni

Quando si implementa questo modello, tenere presente quanto segue:

  • Prendere in considerazione il formato di distribuzione e packaging per distribuire servizi, processi o container. I contenitori funzionano bene per il modello Sidecar.

  • Quando si progetta un servizio sidecar, scegliere attentamente il meccanismo di comunicazione tra processi. Usare tecnologie indipendenti dal linguaggio o indipendenti dal framework, a meno che i requisiti di prestazioni non rendano questo approccio poco pratico.

  • Prima di aggiungere funzionalità a un sidecar, valutare se funziona meglio come servizio separato o come daemon tradizionale.

  • Valutare se implementare la funzionalità come libreria o tramite un meccanismo di estensione tradizionale. Le librerie specifiche del linguaggio offrono un'integrazione più approfondita e un sovraccarico di rete inferiore.

Quando usare questo modello

Usare questo modello quando:

  • L'applicazione principale usa linguaggi e framework diversi. I sidecar offrono un'interfaccia coerente che le diverse applicazioni possono usare indipendentemente dal linguaggio o dal framework.

  • Un team separato o un partner esterno è proprietario di un componente.

  • È necessario distribuire un componente o una funzionalità nello stesso host dell'applicazione.

  • È necessario un servizio che condivide il ciclo di vita complessivo dell'applicazione principale, ma che è possibile aggiornare in modo indipendente.

  • È necessario un controllo granulare sui limiti delle risorse per una risorsa o un componente specifico. Ad esempio, è possibile distribuire un componente come sidecar per limitare e gestire l'utilizzo della memoria indipendentemente dall'applicazione principale.

Questo modello potrebbe non essere adatto quando:

  • È necessario ottimizzare la comunicazione tra processi. I sidecar aggiungono sovraccarico, soprattutto la latenza, che li rende non adatti alle applicazioni con comunicazioni frequenti tra componenti.

  • L'applicazione è piccola. I costi delle risorse per l'implementazione di un sidecar per ogni istanza potrebbero superare i benefici dell'isolamento.

  • È necessario ridimensionare il componente in modo indipendente. Se è necessario ridimensionare il componente in modo diverso dall'applicazione principale, distribuirlo come servizio separato.

  • La piattaforma offre funzionalità equivalenti. Se la piattaforma dell'applicazione fornisce già le funzionalità necessarie in modo nativo, i sidecar aggiungono complessità non necessarie.

Progettazione del carico di lavoro

Valutare come usare il modello Sidecar 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
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. Quando si incapsulano queste attività e le si distribuiscono in processi separati, si riduce la superficie di attacco solo al codice necessario. È anche possibile usare sidecar per aggiungere controlli di sicurezza trasversali ai componenti dell'applicazione che non supportano il supporto nativo per queste funzionalità.

- Segmentazione SE:04
- SE:07 Crittografia
L'eccellenza operativa consente di offrire la qualità del carico di lavoro attraverso processi standardizzati e coesione del team. Questo modello consente di integrare in modo flessibile gli strumenti di osservabilità senza aggiungere dipendenze al codice dell'applicazione. È possibile aggiornare e gestire il sidecar indipendentemente dall'applicazione.

- Strumenti e processi di OE:04
- Sistema di monitoraggio OE:07
l'efficienza delle prestazioni consente al carico di lavoro soddisfare in modo efficiente le richieste tramite ottimizzazioni di ridimensionamento, dati e codice. Questo modello consente di centralizzare le attività trasversali in sidecar che possono essere scalati in più istanze dell'applicazione. Non è necessario distribuire funzionalità duplicate per ogni istanza dell'applicazione.

- PE:07 Codice e infrastruttura

Se questo modello introduce compromessi all'interno di un pilastro, considerarli contro gli obiettivi degli altri pilastri.

Example

È possibile applicare il modello Sidecar a molti scenari. Si considerino gli esempi seguenti:

  • Astrazione delle dipendenze: Distribuire un servizio personalizzato insieme a ogni applicazione per fornire l'accesso alle funzionalità di dipendenza condivise tramite un'API coerente. Questo approccio sostituisce le librerie client specifiche del linguaggio con un sidecar che gestisce problemi come la registrazione, la configurazione, l'individuazione dei servizi, la gestione dello stato e i controlli di integrità.

    Il sidecar Distributed Application Runtime (Dapr) esemplifica questo caso d'uso.

  • Piano dati della service mesh: Distribuire un proxy sidecar accanto a ogni istanza di servizio per gestire problematiche di rete trasversali, come l'instradamento del traffico, i ritentativi, mTLS (mutua autenticazione Transport Layer Security), l'applicazione delle policy e la telemetria.

    I mesh di servizio come Istio usano proxy sidecar per implementare queste funzionalità senza richiedere modifiche al codice dell'applicazione.

  • Ambasciatore sidecar: Distribuire un servizio ambasciatore come sidecar. L'applicazione instrada le chiamate tramite ambassador, che gestisce la registrazione delle richieste, il routing, l'interruzione del circuito e altre funzionalità di connettività.

  • Adattatori di protocollo: Distribuire un sidecar per la conversione tra protocolli o formati di dati incompatibili, o per collegare i sistemi di messaggistica. Questo approccio consente all'applicazione di usare interfacce più semplici o legacy.

  • Arricchimento dei dati di telemetria: Distribuire un sidecar per pre-elaborare o arricchire i dati di telemetria, ad esempio metriche, log e tracce, prima di inoltrare i dati a sistemi di monitoraggio esterni. I componenti come OpenTelemetry Collector possono essere eseguiti come sidecar per normalizzare, arricchire o instradare i dati di telemetria separatamente dall'applicazione.

Passaggi successivi

  • Last updated on