Dovrei Microkernel o Microservice il mio ERP legacy?

Question

Dovrei Microkernel o Microservice il mio ERP legacy?

#1 da (1 voti)

0

Ho lavorato su un'applicazione monolith n-tier per un paio d'anni, e voglio costruire un piano per trasformare questa grande palla di fango in un altro sistema gestibile.

Mi sono imbattuto in Modelli di architettura software di Mark Richards, in cui spiega diversi modelli di architettura software, inclusi Microkernel e Microservices.

Cosa rende Microservices diverso da Microkernel? se stiamo considerando un sistema ERP.

Possiamo considerare i plugin nel modello MK simili ai microservizi? e il Core Module nel mio modello MK sono i servizi di vetro e autenticazione?

Il mio piano era quello di estrarre i moduli che condividono lo stesso dominio dal mio sistema legacy e posizionarlo in unità autonome. dato che il sistema originale fa molto affidamento sulla persistenza su un RDBMS e ha la maggior parte della logica aziendale elaborata attraverso stored procedure.

microservices legacy architectural-patterns

posta A.Rashad 13.07.2018 - 15:34

fonte

1 risposta

Leggi altre domande sui tag microservices legacy architectural-patterns

specificando diverse implementazioni dello stesso caso d'uso per diversi tipi di utenti - Usa il Case Diagram Web designer equivalente nei mondi Android e iOS?

score 1 · Accepted Answer

Esistono sicuramente delle somiglianze tra un'architettura di plugin e un'architettura di servizio. Entrambi gli approcci possono essere utilizzati per modulare un'applicazione. Ma ci sono differenze fondamentali:

Con un'architettura di plugin, tutto in genere viene eseguito nello stesso processo. E l'applicazione kernel / host orchestra come e se i plugin possono comunicare. Tipicamente un modello di dati comune viene esposto da questo kernel. Poiché condividono i dati, tutti i plug-in devono utilizzare un runtime comune, ad es. JVM.
Viene distribuita un'architettura di servizio. I servizi possono essere distribuiti in modo indipendente. A volte esiste un componente comune come un bus dei messaggi, ma questo non è necessario: i servizi possono in linea di principio parlarsi liberamente. Non esiste un componente comune che orchestra e organizza il flusso di dati tra questi servizi, sebbene possa esistere un servizio che funge da interfaccia con il mondo esterno. I messaggi tra i servizi devono utilizzare un tipo di formato compatibile, ma il modello di dati all'interno di ciascun servizio non è in genere condiviso. Poiché i servizi sono processi separati (possibilmente su server separati) non devono condividere un runtime comune e possono utilizzare tecnologie arbitrarie.

I principali punti di vendita delle architetture di servizio sono la dispiegabilità indipendente e le scelte tecnologiche indipendenti, che potenzialmente li rendono più adatti quando i team separati devono collaborare o quando la scalabilità è importante. Tuttavia, lo sviluppo e la distribuzione di un sistema distribuito ha anche molta complessità intrinseca, quindi non sono una buona scelta predefinita.

Se stai cercando solo più modularità, l'estrazione di plugin o librerie dal tuo progetto principale fornisce già la maggior parte di tale valore. Rimanendo nella stessa lingua si ottengono anche alcuni vantaggi, come un controllo dei tipi migliore.