Ho pensato di esercitarmi con una semplice applicazione Microservice (Oxymoron I guess) e ho trovato un problema che non ero in grado di risolvere.
Verrò con un esempio concreto poiché la definizione di preoccupazioni trasversali è piuttosto vaga. Supponiamo di utilizzare alcuni dei provider MQ del cloud per impostare una comunicazione per almeno due servizi. Potrebbero usare code diverse, diversi tipi di messaggi, ecc., Ma c'è ancora qualche codice di codice standard come la creazione di una richiesta al MQ, l'eliminazione di un messaggio, ecc. Pertanto, mi piacerebbe avere questo codice ripetitivo memorizzato in un posto. D'altra parte, mi piacerebbe anche ottenere la capacità di "sperimentare" con i servizi, ad es. se viene visualizzata una nuova versione dell'SDK MQ, mi piacerebbe poterlo utilizzare in uno dei miei servizi, che, ad esempio, non è così importante per il business.
- Crea una libreria condivisa che verrebbe utilizzata da due dei servizi. Alcune mappature dei messaggi potrebbero essere introdotte dai servizi, così come la configurazione della coda, il timeout della visibilità, ecc. Il codice dello standard sarà in un posto, il che è bello. D'altra parte, se preferissi aggiornare questa libreria condivisa con la nuova versione di MQ SDK, tutti i servizi inizieranno a funzionare con la nuova versione non appena li ridistribuisco, che non è la migliore opzione IMO.
- Inserisci semplicemente lo stesso codice in ogni servizio. Con tale approccio, se volessi aggiornare il servizio A, cambierei semplicemente il suo codice e il gioco è fatto. Tuttavia, penso che non sia l'opzione migliore.
- Avere una sorta di repository di pacchetti e utilizzare un gestore di pacchetti come NuGet o sbt. Pertanto, la libreria con cui lavorare con il MQ verrà pubblicata come pacchetto e avrà il proprio controllo delle versioni. Quando si aggiorna l'SDK MQ, si aggiorna anche la versione principale della libreria e la si rilascia al repository. I servizi a cui è interessato scaricheranno il pacchetto e lo aggiorneranno, altri rimarranno intatti.
Per me, il terzo è il più promettente, tuttavia non posso dire di averlo affrontato in ogni progetto con cui ho lavorato. Presumo perché non è facile da configurare. Ho fatto qualche ricerca su questo e sembra che in generale la gente preferisca qualcosa vicino alla terza via.
Sono riuscito a trovare una simile discussione per Python, e anche se Parlo principalmente di .NET e Java / Scala, penso che sia abbastanza vicino. Mi piacerebbe sentire alcune idee che sono probabilmente più vicine all'area in cui lavoro, tuttavia, se si pensa di chiudere la domanda come un duplicato, capisco, anche se penso che potrebbe essere discusso in modo più dettagliato che è stato con Python.