Separazione del contesto in microservizi

Vorrei andare con 1 servizio con moduli ben progettati, in modo che possa essere facilmente suddiviso in più servizi in futuro.

Inoltre, non inserire alcuna logica nel gateway API, che ingombrerà il sistema e renderà più difficile la manutenzione / il bilanciamento delle risorse / gli aggiornamenti futuri. Il gateway API deve solo preoccuparsi di quale messaggio inviare a quale servizio, non dovrebbe preoccuparsi della logica interna di tali servizi.

Monitoraggio del set-up del servizio e attenzione ai problemi nello sviluppo / produzione. Se vedi che il servizio di divisione in multiplo può produrre più benefici rispetto al costo, fallo.

Vorrei cercare problemi di bilanciamento / prestazioni (ad esempio gli ordini di lavoro sono colli di bottiglia e rallentamento dell'intero sistema) e problemi di sviluppo - molte persone che lavorano al servizio, divise in team, che si occupano solo di parte del sistema e che hanno molti conflitti tra di loro.

Una nota generale: i microservizi aggiungeranno molta complessità e costi al tuo sistema. Possono pagare, ma molti sistemi andranno bene senza microservizi. Il modo migliore per adottare i microservizi che ho visto finora è stato quello di creare un servizio / monolite e dividere quando necessario. E presta sempre attenzione alla modularizzazione del servizio / monolite, in modo da poterlo dividere (o unire) facilmente.

Sei sicuro che il contesto limitato (Tecnico, Squadra, WorkOrder) sia ottimale?

Team e WorkOrder suonano come due entità separate per me. Immagino che possa essere creato un WorkOrder prima di assegnarlo a un Team. Forse un WorkOrder potrebbe anche essere riassegnato a un altro Team se non è stato assegnato correttamente in primo luogo.

Prenderò in considerazione due contesti separati e due servizi: Team e WorkOrders. Ci sarebbe una dipendenza tra questi contesti, ma dovrebbe essere facilmente gestibile. Team e WorkOrder probabilmente hanno comunque un ID, quindi non dovrebbe essere troppo difficile tenere traccia dei WorkOrder assegnati a un team senza riferimenti diretti agli oggetti.

Se sembra una sovrastruttura, quale potrebbe essere, potresti anche iniziare con un singolo servizio e un singolo contesto limitato, ma tieni l'opzione di dividerlo in un secondo momento assicurandoti che il tuo progetto sia il più modulare possibile. Riferimenti diretti come Team- > List o WorkOrder- > Team potrebbero rivelarsi problematici se un WorkOrder potrebbe essere creato prima di assegnarlo a un Team o potrebbe essere riassegnato a un altro Team in qualsiasi momento. Li eviterei all'interno di un servizio e nell'interfaccia di un servizio. Puoi sempre fornire una query separata per ottenere gli ordini attualmente assegnati a un team.

I servizi riguardano la proprietà dei dati e la logica aziendale, non le entità e non si desidera inserire gli stessi dati di servizio e la logica che non appartengono insieme. Quindi ci si aspetta che diversi servizi possiedano dati diversi relativi alle stesse entità. Ad esempio, un servizio sarà proprietario dei nomi e dei compleanni dei tecnici e un altro proprietario del team a cui appartiene ciascun tecnico.

Per me, sembra auspicabile che il servizio che gestisce la logica della struttura dei team non sia lo stesso servizio che gestisce gli ordini di lavoro, poiché la logica di business degli ordini di lavoro dovrebbe essere indipendente dai team. Da quello che dici, gli ordini di lavoro vengono assegnati direttamente ai tecnici, indipendentemente dalla loro squadra.

Quindi, date queste condizioni, da un lato, hai un servizio che ti permette di interrogare gli ordini di lavoro di un dato TechnicianId o un elenco di TechnicianIds. Dove ottieni questi TechnicianIds non è una preoccupazione di questo servizio.

D'altra parte, hai un servizio che dato un TechnicianId può dirti il team a cui appartiene e l'elenco di TechnicianIds di quel team se il TechnicianId chiamante è il manager.

Ora hai solo bisogno di mettere insieme le cose: - Chiama il primo servizio per ottenere i Team TechnicsIds se sei il team manager (il servizio lo sa) - Chiama il secondo servizio passando l'elenco di TecnicianIds (o solo uno se non sei manager)

Il modo in cui metti insieme queste due richieste è un problema tecnico che può essere risolto in molti modi (dall'interfaccia utente direttamente su un gateway API) e, poiché si tratta di un problema tecnico, non stai perdendo la logica aziendale. La parte più importante è che questi due servizi non si conoscono l'un l'altro. Sono autonomi e disaccoppiati.

La scelta dei microservizi ti dice già che desideri più servizi qui. Un singolo servizio potrebbe essere una buona scelta, ma non è microservizio.

Il gateway API conosce tutti i diversi servizi. Ma non dovrebbe conoscere alcun dettaglio. Ciò richiede una maggiore comunicazione tra i servizi. Ma il gateway API non lo sa. Conosce la parte che il cliente conosce; e come instradarlo in un servizio. Questo è tutto ciò che sa.

Probabilmente hai bisogno di tre servizi.

I tecnici richiedono un elenco dei loro workorder attraverso il servizio tecnico. Il servizio tecnico conosce il servizio di workorder, ma non come funziona. Indica al servizio di workorder quale tecnico sta effettuando la richiesta.

Il servizio di squadra sa che il tecnico esiste e sa che alcuni tecnici sono manager. (oppure puoi renderli separati, non importa qui) E sa che esistono dei work worker, ma non c'è nulla in loro. In questo modo è possibile aggiungere una funzionalità di servizio che riunisce i membri del team sotto il gestore e quindi, per ciascun membro del team, contatta il servizio tecnico e richiede i tecnici per quel tecnico. Quindi il servizio tecnico può andare a prendere i lavori.

C'è molto più traffico di rete rispetto a un servizio monolitico, ma è così che si ottiene il disaccoppiamento. Se cambi il concetto di team in modo da avere sottotitoli o ruoli diversi nei team con capacità diverse, cambi solo il servizio del team.

Se sei preoccupato per servizi o modelli anemici o simili, disegna le relazioni e scopri cosa succede da un capo all'altro quando viene fatta una richiesta. Quelli anemici appariranno come passi extra inutili nel mezzo in cui gli input e gli output sono semplicemente passati senza aggregazione, filtraggio o effetti collaterali.