Limiti dell'architettura dei microservizi

Question

Limiti dell'architettura dei microservizi

Naviga le tue risposte

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

0

Vorrei implementare il sito di giochi d'azzardo con le seguenti possibilità:

come giocatore vorrei ricevere l'elenco dei giochi
Come giocatore mi piacerebbe giocare ai giochi
Come giocatore mi piacerebbe vedere i giochi consigliati (in base ai Mi piace o al tempo trascorso su un particolare gioco da parte degli utenti)
Come giocatore vorrei iniziare / finire un particolare gioco

Per i requisiti di cui sopra, avrò bisogno di almeno 3 micro servizi dal mio parere:

Servizio GameCatalog - conterrà giochi e categorie di giochi
Servizio di consulenza di gioco - analizzerà quale gioco viene lodato per qualsiasi utente o utente in base ai Mi piace e al tempo trascorso in un gioco
UserManagement Service: conterrà account utente

I microservizi saranno comunicati tra loro da Apache Kafka. Ogni microservizio avrà il proprio database.

Quali altri servizi di microservizio dovrei avere o avviare / terminare i giochi in questo ambito?

La funzionalità "mi piace" dovrebbe essere inclusa nel servizio di GameRecommendation?

Dove è meglio conservare i dati relativi a Mi piace e "timeSpent" nel database dei servizi di GameRecommendation o in un altro?

microservices

posta Viktor V. 03.04.2018 - 09:40

fonte

2 risposte

Leggi altre domande sui tag microservices

L'implementazione di Oauth2.0 deve essere eseguita lato client o lato server Dovrei caricare il testo locale appropriato all'inizio, o ottenere il testo locale in base alle preferenze locali ogni volta?

score 2 · Answer 1

Disclaimer: Sono relativamente nuovo sia per Microservices che per DDD.

Hai familiarità con Domain Driven Design ? Ha un concetto chiamato Contesti limitati che può aiutarti.

In DDD, i contesti limitati sono un modo per gestire la complessità coinvolta nella modellazione di domini di grandi dimensioni. Servono per raggruppare concetti e operazioni strettamente correlati.

Penso che dovresti leggerli perché i contesti limitati tendono a mappare molto bene i confini di Microservice.

Scriverò di più su questo, ma sono al lavoro: P

score 0 · Answer 2

Quali sono le azioni nel tuo scenario e chi sono i soggetti?

1) users a log into della tua applicazione. Questo è facile da separare. Il lavoro è chiaramente definito. Questo dovrebbe fare per un servizio.

2) users ha interazione con games .

Ci sono diversi argomenti:

a) Lo stato attuale di games

b) Archiviazione e analisi di corrente / passato games

c) users vuole piacere games .

Microservices will be communicate to each other by Apache Kafka.

Perché?

What else microservice I should have to like or start/end games in this scope?

Forse ripensi il tuo "microservizio". Dal mio punto di vista, non è necessario alcun microservizio per come o per iniziare / fine . Queste sono azioni (= events ), un utente fa nel tuo sistema. Poiché i giochi che iniziano e che finiscono hanno un impatto sul states dei giochi attuali, ad esempio un gioco viene aggiunto all'elenco dei giochi correnti in esecuzione e il suo stato viene mantenuto come < em> in esecuzione .

Should 'like' functionality be in GameRecommendation Service as well?

A user Mi piace a certain game è un evento e in quanto tale è pubblicato come messaggio. Questo messaggio potrebbe essere utilizzato da molti abbonati: ad esempio il servizio di consigli e un servizio di analisi.

Where is better to keep data concerning likes and 'timeSpent' in GameRecommendation service database or another one?

Ci sono molti luoghi in cui queste informazioni potrebbero entrare, ad es. analytics - per il monitoraggio degli utenti della piattaforma nel suo complesso, quanta interazione ha ogni utente con ogni gioco e così via. Dipende dal tuo usecase.

Questo è un possibile progetto. Ma oltre a ci sono molti altri possibili.