Due processi in un singolo container docker o due servizi che si connettono allo stesso db?

Question

Due processi in un singolo container docker o due servizi che si connettono allo stesso db?

#1 da (2 voti)
#2 da (1 voti)

3

Recentemente ho iniziato a spostare un'applicazione monolitica su architettura di microservizi utilizzando contenitori docker. L'idea generale dell'app è:

scraping data - > formatta i dati - > salva i dati su MySQL - > servire i dati tramite API REST.

Voglio suddividere ciascuno dei passaggi in un servizio separato. Penso di avere due scelte, qual è la migliore pratica nell'architettura dei microservizi qui?

Opzione uno
Servizio di raschiatura - raschia e pubblica su Kafka
Servizio di formattazione - consuma messaggi da Kafka e li formatta
Servizio API - consuma messaggi Kafka, aggiorna MySQL e espone un'API REST
Svantaggio: Se non sbaglio, i contenitori docker devono preferibilmente eseguire solo un processo per contenitore

Opzione due
Servizio di raschiatura - raschia e pubblica su Kafka
Servizio di formattazione - consuma messaggi da Kafka e li formatta
Salvataggio in servizio DB - riceve le informazioni formattate e aggiorna solo MySQL (viene eseguito come processo python)
Servizio API - espone un'API REST che serve le richieste con il flacone python.
Svantaggio: Due servizi che si collegano allo stesso DB, supposto sconsigliato in quanto non sarebbero disaccoppiati

Qual è la migliore pratica qui? dovrei andare con l'opzione uno ed eseguire il server flask e il listener di kafka nello stesso contenitore?

Grazie!

python microservices docker flask apache-kafka

posta roGamba 23.09.2016 - 01:02

fonte

2 risposte

1

Senza dubbio è l'opzione due, e l'inconveniente che si evoca è lo stesso per l'opzione uno dato che si dispone di un servizio ("servizio API") con 2 responsabilità molto diverse (salvataggio in DB + expose in API) raggruppate in una pacchetto di distribuzione.

Questi 2 servizi (salvati in DB ed esporre in API) potrebbero tuttavia condividere un livello DAO comune, duplicato in entrambi i servizi. O il "expose to API service" è di sola lettura, quindi sarebbero servizi completamente indipendenti anche se interagiscono con lo stesso db.

AGGIORNAMENTO: solo se hai bisogno di vedere che condividere un database tra 2 microservizi non è un antipattern: link

risposta data 12.03.2017 - 12:24

fonte

Leggi altre domande sui tag python microservices docker flask apache-kafka

Il mio progetto agile ha davvero bisogno di un analista di business dedicato (BA)? Alternative al modello di delega che consente i messaggi ciechi tra i componenti

score 2 · Accepted Answer

Suggerirei qualcosa seguendo le linee seguenti.

Scraper: copia i dati e li pubblica su Kafka
Formatter / Persistenza: legge da Kafka, invia i dati al livello di archiviazione
Archiviazione: 1 database "reale" in cui vengono eseguite le scritture. Replica questo db in tutte le copie di sola lettura di cui hai bisogno.
: accede solo alle repliche di sola lettura per servire i dati.

Il concetto di coerenza finale entra in gioco qui. È possibile far ruotare il maggior numero di repliche e contenitori API necessari per soddisfare la domanda, a costo di restituire a volte dati (vecchi) diversi. Ad un certo punto la replica dbs viene aggiornata e l'API inizia a servire i dati più recenti. In questo modo, la scrittura di nuovi dati non ostacola i tempi di risposta delle tue letture.