Mi è stato assegnato il compito di pensare a un'architettura di microservizi su più livelli per Azure Service Fabric. Ma la mia esperienza è stata per lo più su architetture monolitiche. Non riesco a trovare una soluzione specifica.
Ciò che ho pensato fin da ora è come ...
Livello dati - qui si trovano tutte le entità Code First e DBContext.
Business Layer - Qui è dove tutti i Service Manager eseguono e applicano la Business Logic, cioè UserManager (IUserManager), OrderManager (IOrderManager), InvoiceManager (IInvoiceManager) ecc.
WebAPI (Self Service Inside Service Self Self Service) - Sebbene questa WebAPI sia all'interno di Service Fabric ma non fa altro che ricevere la richiesta e chiamare i rispettivi servizi in Service Fabric. WebAPI Layer eseguirà inoltre qualsiasi autenticazione e autorizzazione (identità ASP.NET) prima di passare la chiamata ad altri servizi.
Servizi Fabric Service - UserService, OrderService, InvoiceService. Questi servizi sono invocati da WebAPI Layer e DI the Business Layer (IUserManager, IOrderManager, IInvoiceManager) per eseguire la sua operazione.
Pensi che questo sia okay per procedere?
Un problema teorico, tuttavia, durante la lettura di diverse risorse di architettura dei microservizi, ho scoperto che, tutti suggeriscono di avere Business Logic all'interno del servizio in modo che il servizio specifico possa essere ridimensionato in modo indipendente. Quindi, credo, sto violando l'aspetto base dei microservizi.
Lo sto facendo perché, il requisito del cliente è quello di utilizzare questo Business Layer su diversi progetti, come Lavori batch (Lavori Web di Azure), Pannello di controllo backend per dipendenti interni (ASP.NET MVC), ecc. Quindi, se io indosso Mantenere lo stesso Business Layer, devo ancora scrivere la stessa Business Logic per Web Jobs e Backend Dashboard, che ritengo non sia una buona idea. Come un semplice cambiamento in Business Logic richiederebbe un cambio di codice in più punti allora.
Un'altra preoccupazione è che, in quel caso, devo andare con la comunicazione Service to Service per le transazioni ACID. Ad esempio, durante la creazione di un ordine, è necessario creare un ordine e una fattura. Quindi, in quel caso, ho pensato di utilizzare la programmazione Event Driven, ad esempio il servizio ordini emetterà un evento a cui il servizio di fatturazione può sottoscrivere, per creare la fattura sulla creazione dell'ordine. Ma le complicazioni sono se il servizio di fatturazione non riesce a creare la fattura, può continuare a provare a farlo all'infinito (che è una cattiva idea credo), o emettere un altro evento per ordinare il servizio per iscriversi e ripristinare l'ordine. Ci può essere molta confusione con questo.
Inoltre, devo menzionare che stiamo usando un singolo database fin d'ora.
Quindi le mie domande sono ...
- Che problema vedi nel mio approccio? Va bene?
- In caso contrario, mi suggerisca un approccio migliore. Puoi guidarmi ad alcune risorse anche per dettagli di implementazione o dettagli concettuali.
NOTA: il requisito del cliente è che possono ridimensionare un modulo specifico che necessita. Ad esempio, UserService potrebbe non essere utilizzato tanto quanto non ci saranno molte registrazioni giornaliere o modifiche nel profilo utente, ma OrderService può essere ridimensionato in quanto ci possono essere molti ordini in entrata ogni giorno.
Sarò felice di imparare. Poiché questa è la mia prima possibilità di mettere le mani su come progettare un'architettura di microservizi.