Microservizi e modelli di archiviazione dati isolati [duplicati]

Naviga le tue risposte
10

Ho osservato Microservices per un po 'di tempo. Il concetto non è nuovo ma è comunicato in modo leggero. Quindi, sono molto entusiasta di questo.

Tuttavia, c'è una domanda che non sono sicuro di quale sia la risposta: ogni microservice dovrebbe avere un proprio modello di archiviazione dei dati isolato completamente? Considera quanto segue:

Note: This is probably not a good example as the seperation here is done based on read/writes whereas the good approach would be to separate the business concerns.

  • products-write-service: responsabile della gestione della creazione e delle modifiche dei prodotti. Conosce MongoDB e scrive i dati lì.
  • product-lookup-service: responsabile della gestione del recupero dei prodotti tramite i loro identificatori, fornendo un elenco di base dei prodotti in base alle categorie, ecc. Conosce MongoDB e legge i dati da lì.
  • product-search-service: responsabile della gestione delle richieste di ricerca sui prodotti. Conosce Elasticsearch e legge i dati da lì.

Qui abbiamo due tecnologie separate per l'archiviazione dei dati tra tre servizi. Tuttavia:

  • products-write-service e products-lookup-service funzionano sullo stesso modello di archiviazione dati. Esiste una relazione collaudata tra due servizi.
  • alla fine della giornata, dovrebbe esserci un processo per eseguire ETL da MongoDB a Elasticsearch per products-search-service per funzionare. In un certo senso, tre microservizi hanno il proprio modello di archiviazione dei dati, ma esiste un processo intermedio che conosce questi due modelli.

Che cosa dici di questo modello? La separazione è completamente sbagliata qui?

    
posta tugberk 23.12.2015 - 15:44
fonte

3 risposte

6

Penso che ogni servizio dovrebbe avere il proprio spazio di archiviazione . Altrimenti manchi un punto di (micro) servizi - non puoi evolvere rapidamente il servizio se sei limitato dallo storage condiviso con altri servizi.

Perché dividi la logica di lettura e scrittura in servizi separati? È un po 'un odore per me.

Non c'è nulla che dice che un servizio non possa avere più archivi. Forse stai guardando un singolo servizio con più depositi? L'aggiornamento di un prodotto può comportare aggiornamenti simultanei sia di MongoDB che di ES.

Sulla base di una conoscenza di dominio limitato, fornirei 2 servizi: Catalogo prodotti con MongoDB e Ricerca prodotti con ES come backend. Il modo in cui trasferisci i dati tra i servizi è una domanda separata:

  1. ETL come hai suggerito (dovresti capire entrambi gli archivi - veloce e sporco)
  2. Eventi di dominio: il servizio di ricerca dei prodotti potrebbe abbonarsi agli eventi pubblicati dal servizio Catalogo prodotti (sarebbe la mia scelta preferita)
  3. Processo batch che userebbe l'API dei servizi invece di andare direttamente allo spazio di archiviazione (probabilmente meglio di 1. ma richiede lo sviluppo di API più ricche)
risposta data 23.12.2015 - 17:39
fonte
1

Bene, la migliore analogia è incapsulamento e Nascondersi dei dati in OOP.

L'unico modo per interagire con lo stato dell'oggetto è attraverso la sua interfaccia pubblica. Allo stesso modo, l'unico modo in cui dovresti essere in grado di interagire con i dati di un (micro) servizio deve essere attraverso la sua API pubblica . Detto questo, (micro) servizi spesso eventi a cui altri servizi potrebbero aderire.

Pertanto, i servizi di lettura e scrittura sono praticamente lo stesso (micro) servizio quando accedono alla stessa origine dati.

Quindi qual è la differenza con il classico SOA? Beh, non molto qui. Ma se inizi a rompere il catalogo prodotti nei suoi diversi aspetti, i servizi saranno più piccoli. Ad esempio, un servizio clienti SOA classico archivia tutto ciò che riguarda il cliente, ma in un mondo Microservice, l'indirizzo viene assegnato a un servizio mentre le preferenze vengono assegnate a uno o più servizi.

Ma non tutti i microservizi dispongono di un archivio dati. Alcuni microservizi sono servizi composizione che aggregano i dati di più servizi (arricchiti) e rappresentano una facciata più utilizzabile. Inoltre alcuni Microservices racchiudono un algoritmo e non hanno dati in quanto tali, forse solo una configurazione.

Spero che questo aiuti.

    
risposta data 23.12.2015 - 17:51
fonte
-2

Per risposta: ogni servizio dovrebbe avere un proprio meccanismo di archiviazione.

Informazioni sottolineature:

Forse i confini del tuo micro-servizio (contesto limitato) sono errati. Il servizio di scrittura e consultazione dei prodotti potrebbe appartenere allo stesso limite, ma la ricerca non è un concetto di dominio, quindi la ricerca potrebbe essere un altro limite del servizio. Il servizio di ricerca del prodotto è un servizio di assistenza di base nel contesto limitato del prodotto, quindi non è necessario un altro database.

link

    
risposta data 24.12.2015 - 12:11
fonte

Leggi altre domande sui tag

In una posizione di Scrum, la discussione di ciò che è stato fatto ieri può essere limitata a compiti sulla lavagna oa tutto il lavoro svolto? Dove convalidare le regole del modello di dominio che dipendono dal contenuto del database?