Microservizi nell'implementazione di Docker


9

Stiamo scrivendo i nostri primi micro servizi utilizzando container Docker utilizzando Amazon Fargate. Abbiamo molti dubbi a livello di implementazione usando Spring Boot

Avremo più micro-servizi nel progetto, è una buona pratica scrivere tutti i micro-servizi in un singolo contenitore o devo creare un contenitore Docker separato per micro-servizi separati. In un modo economicamente conveniente utilizziamo un singolo contenitore, ma ciò creerà problemi per la struttura del nostro progetto in futuro?

Stiamo pianificando di distribuire l'applicazione in AWS Fargate e la nostra applicazione avrà una grande opzione per estendersi in futuro e prevediamo da 100 a 150 diversi micro servizi. In questo caso è conveniente se stiamo caricando tutti questi microservizi anche in contenitori diversi?


Tutto dipende dalla tua struttura. Devi condividere molti più dettagli in modo che altri possano aiutarti
Nico Haase,

6
È quasi sempre più sensato implementare un servizio per container, poiché ciò consente di scalare i servizi in modo indipendente e di sostituire i singoli servizi con versioni aggiornate o implementazioni alternative.
Larks

Il compromesso è con te tra i servizi di raggruppamento e l'esecuzione individuale. Esegui un taglio del dominio della tua attuale applicazione, raggruppa i servizi per dominio, poiché potrebbero condividere lo stesso archivio dati. Questo ti aiuterà a gestire meglio i servizi raggruppati.
Srini M,

Risposte:


21

La cosa più importante da ricordare con i microservizi è che non si tratta principalmente di risolvere problemi tecnici ma di problemi organizzativi. Pertanto, quando esaminiamo se un'organizzazione deve utilizzare i microservizi e come vengono distribuiti tali servizi, dobbiamo verificare se l'organizzazione ha i problemi che lo stile dei microservizi risolve.

La risposta alla tua domanda sulla tua architettura, quindi, dipenderà principalmente dalle dimensioni del tuo team tecnologico, dalla struttura organizzativa, dall'età del tuo prodotto, dalle tue attuali pratiche di implementazione e da come queste potrebbero cambiare nel medio termine.

Ad esempio, se la tua organizzazione:

  • ha meno di 25 dipendenti tecnici,
  • organizzato in 1 o 2 squadre,
  • ognuno dei quali funziona su qualsiasi parte del prodotto,
  • che ha meno di 12 mesi,
  • e viene distribuito tutto in una volta su base regolare (ad esempio giornaliero, settimanale, mensile),
  • e l'organizzazione non sta per crescere rapidamente,

allora quasi sicuramente ti dimenticherai dei microservizi per ora. In una situazione come questa, il team è ancora nuovo nell'imparare il dominio, quindi probabilmente non sa tutto ciò che dovrebbe sapere per capire davvero quale sarebbe un ottimo modo per suddividere il sistema in un'architettura distribuita. Ciò significa che se lo dividono ora, probabilmente vorranno cambiare i confini in un secondo momento, e questo diventa molto costoso quando si dispone già di un sistema distribuito, pur essendo molto più semplice in un monolite. Inoltre, con solo un piccolo team in grado di lavorare (e supportare) qualsiasi parte del sistema, ci sono poche ragioni per investire nella costruzione di una piattaforma in cui i singoli team possono implementare e mantenere singoli servizi. Un'organizzazione in questa fase sarà in genere molto più interessata a trovare clienti e iterare rapidamente il prodotto, forse persino a far perno sul prodotto, anziché a rendere i team autonomi e a costruire un'architettura su larga scala e resiliente. Un'architettura monolitica ha senso a questo punto, ma amonolito ben progettato , con chiari confini dei componenti imposti dalle API e accesso incapsulato ai dati, che semplifica l'estrazione dei servizi in processi separati in seguito.

Diamo un'occhiata un po 'più avanti e consideriamo un'organizzazione che è ...

  • oltre 50 addetti tecnologici,
  • organizzato in 7 squadre,
  • ognuno dei quali funziona solo su aree specifiche del prodotto,
  • che ha 3 anni,
  • e ha team che vogliono distribuire il proprio lavoro indipendentemente da ciò che fanno gli altri team.

Una tale organizzazione dovrebbe sicuramente costruire un'architettura distribuita. In caso contrario, e invece tutti questi team lavorano in un monolito, si imbatteranno in tutti i tipi di problemi organizzativi, con i team che devono coordinare il loro lavoro, i rilasci vengono ritardati mentre il team termina il QA sulla sua nuova funzionalità, patch si rivela una seccatura per il personale e i clienti. Inoltre, con un prodotto maturo, l'organizzazione dovrebbe conoscere abbastanza bene il dominio per poter dividere sensibilmente sia il dominio che i team (in questo ordine; vedi la Legge di Conway) in unità sensibili e autonome che possono fare progressi minimizzando il coordinamento.

Sembra che tu abbia già scelto i microservizi. A seconda di dove ti siedi sulla bilancia sopra, forse vuoi rivisitare quella decisione.

Se vuoi continuare a sviluppare con i microservizi ma implementandoli tutti in un unico contenitore, sappi che non c'è nulla di sbagliato in questose si adatta al modo in cui la tua organizzazione lavora al momento. In futuro creerà problemi per la struttura del tuo progetto? Bene, se hai successo e la tua organizzazione cresce, probabilmente arriverà un momento in cui questa distribuzione a contenitore singolo non è più la soluzione migliore, in particolare quando i team iniziano a possedere i servizi e vogliono distribuire solo il loro servizio senza distribuire l'intera applicazione . Ma tale autonomia arriverà a scapito del lavoro extra e della complessità, e potrebbe non darti alcun vantaggio in questo momento. Solo perché non sarà l'approccio giusto per il tuo sistema in futuro non significa che non sia l'approccio giusto per oggi. Il trucco sta nel tenerlo d'occhio e sapere quando fare l'investimento extra.


1
Questa è un'ottima spiegazione e siamo in grado di identificare dove dobbiamo usare le docker e i microservizi sulla base della struttura del progetto e del team. Grazie.
anoop,

2

Nessun problema se si utilizza un singolo contenitore per i microservizi ma l'obiettivo principale dei microservizi è quello di mantenere separatamente ciascun servizio separatamente, ogni servizio deve essere accoppiato liberamente e ogni servizio deve avere un database separato (se si desidera ottenere un database per architettura di servizio). Quindi cerca di raggiungere questo obiettivo esegui i tuoi servizi in un contenitore separato e orchestra questi servizi con docker swarm o Kubernetes. So che i costi sono importanti, ma se lo fai nel modo giusto, allora vedrai la potenza dell'architettura dei microservizi.


È vantaggioso in termini di costi se stiamo usando container docker diversi per diversi micro-servizi. Dal momento che ci aspettiamo da 100 a 150 micro servizi nel progetto
anoop il

No, non è vantaggioso dal punto di vista dei costi, ma l'esecuzione di ciascun servizio in modo separato sarà tecnicamente vantaggiosa.
Slim Coder,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.