Microservizi livello di dettaglio

0

Ho detto al mio capo che per la nostra prossima applicazione creeremo servizi di riposo che seguono l'architettura dei microservizi. Il design che avevo era un po 'come questo:

all functions related to users - 1 rest service
all functions related to payment - 1 rest service
all functions related to audit log - 1 rest service
all functions related to corporate accounts - 1 rest service
etc..etc..

Il problema è che non era d'accordo con questo. Ha menzionato un po 'come un microservice deve contenere funzioni più fini. Qualcosa come un microservizio per questo particolare tipo di pagamento, un altro per un altro tipo di pagamento, uno per la creazione dell'utente, uno per i dettagli dell'utente, ecc. Dice che il mio design non dovrebbe essere chiamato architettura di progettazione di microservizi.

Quindi la mia domanda è ... il mio progetto segue davvero il principio di progettazione del microservizio? è a grana troppo grossa e dovrebbe essere più fine? è il mio capo, giusto? qual è il limite massimo delle funzioni di dettaglio più fini che un microservizio dovrebbe avere?

Ho bisogno del tuo aiuto. Gradirei chiunque possa far luce su questo. Grazie

    
posta Davoin Showerhandles 13.05.2017 - 15:27
fonte

3 risposte

2

Leggi la Guida ai microservizi del blog di Martin Fowler. Tra le altre cose, troverai tutto il necessario per discutere il livello di granularità dei tuoi microservizi con il tuo capo.

Ma se vuoi uno spoiler: hai ragione (o almeno "più strong" del tuo capo). Si suppone che i microservizi siano autonomi, nel senso che dovrebbero avere la propria interfaccia utente e il database raggruppati come un unico dispiegabile. Pertanto, disporre di un "microservice" per Sign-Up e un altro per Dettagli utente non si adatta al concetto. Invece, come era il tuo progetto originale, questi casi d'uso dovrebbero essere raggruppati in un unico Microservice che è responsabile per gli utenti.

    
risposta data 13.05.2017 - 15:40
fonte
2

Non esiste una regola complessa che ti dirà che al di sopra o al di sotto di una certa quantità di granularità, i tuoi servizi smettono di essere microservizi. Alcuni servizi possono, infatti, gestire un compito molto ristretto e specifico, come ad esempio trattare un particolare tipo di pagamento. Altri possono essere piuttosto grandi in termini di responsabilità. Inoltre, l'architettura dei microservizi riguarda la infrastruttura che circonda e supporta un insieme di servizi, non la dimensione dei servizi.

Una domanda da porsi è se abbia senso avere una determinata porzione di codice in una forma di servizio autonomo. In altre parole, avrebbe senso usare solo quel servizio, o la maggior parte dei casi d'uso comporterebbe l'uso in combinazione con altri servizi.

  • Se hai un servizio per la creazione di un utente e un altro per i dettagli dell'utente, e praticamente in tutti i casi, vengono utilizzati insieme, lo hai diviso troppo.

  • Se si dispone di un servizio utente globale che viene utilizzato da un insieme di applicazioni per creare solo utenti ma non accedere mai ai propri dettagli e un diverso insieme di applicazioni che gestiscono i dettagli degli utenti, ma mai creare nuovi utenti, il il servizio è un buon candidato per una divisione.

Ottenere la giusta dimensione dei servizi non è facile. Ancora più importante, non provare a farlo subito dall'inizio, ma piuttosto progettarlo in modo che sia relativamente facile suddividerlo e unirli in seguito, quando si ha una migliore comprensione dell'utilizzo effettivo dei servizi.

    
risposta data 13.05.2017 - 15:50
fonte
0

Oltre alla risposta di Arseni (che sono d'accordo)

È davvero difficile determinare quanto piccolo deve essere un Microservices e molte volte le linee dei contesti limitati sono sfocate.

Più leggo su Microservices e più pratico, più sono convinto che È richiesta una profonda comprensione del dominio che stiamo modellando e dell'organizzazione della società che viene riflessa .

Forse, ti sei precipitato prematuramente nella progettazione dei servizi. Probabilmente, il tuo capo vede i bisogni / obiettivi da un altro punto di vista. È chiaro che hai bisogno di consenso. Il consenso è raggiunto quando tutti i punti di vista sono allineati con gli obiettivi e le esigenze dell'organizzazione (il nostro o il cliente "per cui lavoriamo).

Non so qual è il tuo ruolo nel progetto, ma se sei un tecnico (come sono io), determinare i contesti limitati è lontano dall'essere una decizione tecnica. Ciò non significa che tu non abbia nulla da dire. Siamo un po 'uno "strumento". Siamo lo strumento che meglio serve una proposta specifica e fornisce una guida. Realizziamo la visione del business proiettando la visione tecnica su quella aziendale. Ma entrambe le visioni devono essere allineate ed equilibrate.

D'altra parte, quando pensiamo in Microservices, tendiamo a identificare i servizi con le caratteristiche del dominio. Trasformiamo le diverse funzionalità dell'applicazione in servizi.

Tuttavia, spesso dimentichiamo che i microservizi sono sistemi indipendenti (di per sé) piuttosto che "semplici caratteristiche". Quindi, cosa ci impedisce di determinare i limiti all'interno di un dato servizio? Cosa ci impedisce di dividere un microservizio in due o più microservizi annidati? O viceversa, perché le funzionalità correlate non possono essere raccolte in un singolo Microservice?

Ciò che conta è la coesione che fornisce al sistema globale.

Gli altri microservizi non hanno bisogno di conoscere gli interni né i dettagli di protesi del resto. L'interfaccia per la collaborazione è tutto ciò che hanno bisogno di sapere sugli altri.

Ad esempio, quando il tuo capo ha suggerito diversi microservizi per ogni possibile tipo di pagamento, non stava andando oltre.

Il processo di pagamento è abbastanza importante da meritare un microservizio. La sua complessità può anche portarci a determinare che i microservizi nidificati possono fornirci la flessibilità che richiede un mercato globale. E, naturalmente, renderà più facile aggiungere nuovi tipi di pagamento, per distribuirli senza il rischio di introdurre bug in quelli esistenti. Inoltre facilita il test e il monitoraggio.

Ad esempio, nel mercato di oggi (quello globale), le applicazioni sono esposte a diverse regolarizzazioni del mercato locale e leggi in cui alcuni tipi di pagamento potrebbero non essere consentiti a spese di altri tipi.

Riassumendo, prima di formulare le tue ipotesi su come dovrebbe essere il sistema e pensare in termini di hai ragione / torto , siediti con tutti gli stakeholder al fine di raggiungere il consenso. Consenso nel senso che parti interessate tecniche e non tecniche condividono la visione strategica (cosa fare) e la tecnica (come fare).

is my boss right?

Quando devo progettare un nuovo sistema, devo ricordare a me stesso uno dei motivi più difficili che ho imparato in questo lavoro:

  • La creazione di un decennio unilaterale spesso mi porta a conseguenze terribili a causa di ipotesi errate.

Né tu né il tuo capo avete torto o ragione. Entrambi non condividete la stessa visione. Ricorda che nella tecnologia del software non ci sono regole d'oro, né regole fisse inamovibili. Solo convenzioni e buone intenzioni.

Resta flessibile e scettico sul significato di tutto ciò che leggi là fuori. Fai molta attenzione con frasi come: ha senso , buon senso , ecc. Ciò che per te ha senso può o non può avere senso. E non esiste il buon senso

    
risposta data 13.05.2017 - 20:08
fonte

Leggi altre domande sui tag