È valido dividere un'API in diversi microservizi?

0

Assumere il seguente scenario.

Un blog in cui chiunque può visualizzare pubblicazioni e commenti e utenti con privilegi sufficienti a creare, aggiornare o eliminare queste pubblicazioni o commenti.

  • Servizio elenco pubblicazioni (M1) è responsabile di solo elenca pubblicazioni e commenti.
  • Servizio di pubblicazione (M2) che in pratica salva, aggiorna o elimina

All'inizio pensavo che il servizio di pubblicazione (M3) potesse fare tutto (CRUD) ma diciamo che la forma di pubblicazione è in qualche modo complessa e dipende da altri servizi, se decido di chiudere M3 per una manutenzione

  • Come posso mostrare agli utenti l'elenco delle pubblicazioni?
  • È giusto separare un'API per questi scenari?
  • Mi manca un servizio o un software in grado di risolvere questo problema?

PS: Durante la scrittura mi sono ricordato di IC / CD ma di nuovo se voglio che gli utenti vedano solo pubblicazioni e commenti e non ne pubblichino fino a quando il servizio non è attivo. Come posso gestirlo?

    
posta Daniel Alvarez 07.07.2018 - 20:26
fonte

2 risposte

2

Vorrei sconsigliarlo. Uno dei principi fondamentali dei microservizi è che un servizio dovrebbe possedere i propri dati. Se i dati sono condivisi, i servizi tendono a non essere dispiegabili in modo indipendente a causa dell'accoppiamento con i dati. cioè - cosa succede quando hai bisogno di versionare il tuo modello di dati? L'API di scrittura deve essere conosciuta e l'API di lettura deve essere informata e non è possibile distribuirli contemporaneamente ...

Mi piacerebbe solo fare loro la propria API insieme e averne finito. Non guadagni molto dal tenerli separati nella maggior parte degli scenari.

    
risposta data 07.07.2018 - 21:02
fonte
0

Dai un'occhiata a CQRS Comando Query Response Segregation ed Event Sourcing.

In questo caso il tuo editore potrebbe semplicemente pubblicare eventi quando un articolo viene pubblicato e l'archivio query potrebbe, ad esempio, solo scriverlo su disco o un indice lucene o qualcosa di ottimizzato per la lettura. Quindi, in effetti, avresti un sito flat per i consumatori e forse un negozio SQL solo sul lato dell'editore.

    
risposta data 08.07.2018 - 15:51
fonte

Leggi altre domande sui tag