Disintegrazione dell'applicazione monolitica con Micro services vs approccio ESB?

Question

Disintegrazione dell'applicazione monolitica con Micro services vs approccio ESB?

#1 da (1 voti)

3

Ho solo conoscenze teoriche su ESB.

Caso di utilizzo: -

Ho un'applicazione di e-commerce in cui posso ricevere ordini da più fonti in diversi formati.
Una volta inviata la domanda, devo inviare e-mail a due sistemi
Una volta inviata la domanda, devo inviare un file di output a un sistema di terze parti. Oggi solo XML, ma potremmo aver bisogno di supportare i formati lungo la linea
Analogamente, ho bisogno di eseguire analisi e preparazione dei rapporti.

Vedo che sia ESB che Micro-servizi possono adattarsi qui in teoria. Entrambi rendono l'applicazione liberamente accoppiabile e scalabile invece di un'unica applicazione monolitica. Non sono sicuro di cosa sono criteri / attributi che dovrei considerare per selezionare il prodotto ESB a scaffale (a pagamento o open source) rispetto alla disintegrazione dell'app nei micro servizi?

La mia comprensione: - ESB può essere più adatto in quanto rende l'applicazione più liberamente accoppiata dove un componente / applicazione verrà semplicemente inserito il messaggio sul canale (che non è altro che l'oggetto java nelle app ESB basate su java su cui gli altri componenti sono in ascolto). Ora altri componenti come router / trasformatori / adattatori / endpoint ecc. Entreranno in scena e intraprenderanno ulteriori azioni. Qui il componente di invio deve solo conoscere la destinazione indirizzo che sarà l'indirizzo del singolo canale.

In caso di microservizi questo è anche vero, ma qui il consumatore deve conoscere l'URL per ogni operazione specifica.

Ma ora un giorno ho osservato che la maggior parte della gente preferisce i micro servizi su ESB. Penso che la ragione possa essere che ESB ha una propria curva di apprendimento / DSL / Prodotti a pagamento, ma i micro servizi non sono altro che servizi divisi in componenti restful più piccoli mantenibili. Quindi nessuna curva di apprendimento e nessun prodotto a pagamento.

java microservices enterprise-architecture architectural-patterns esb

posta user3222249 01.01.2018 - 10:21

fonte

1 risposta

Leggi altre domande sui tag java microservices enterprise-architecture architectural-patterns esb

Come si possono applicare metodologie agili in una tipica azienda di "servizi"? Il cetriolo è appropriato per le specifiche estese del case d'angolo?

score 1 · Answer 1

Penso che la mia osservazione sia che in entrambi i casi devi fare un po 'di codice.

Se si codifica tutto da soli, si ha il costo degli stipendi degli sviluppatori e il tempo necessario per la codifica di ogni nuova cosa che si desidera aggiungere

Gli ESB off-shelf promettono la super-configurabilità e le interfacce drag and drop in modo da poter collegare facilmente tutto insieme ed evitare questo costo.

Tuttavia, in pratica ho scoperto che le cose che connetti non devono essere molto complicate per superare le funzionalità dell'interfaccia drag and drop e sei costretto a ricorrere alle funzioni speciali di codifica.

Presto finirai per assumere un team di programmatori ESB che lavorano esclusivamente con quel prodotto, la tua configurazione ESB diventa così complessa che nessuno la capisce più e in pratica hai appena scambiato un linguaggio di programmazione con un altro più costoso con blocco del fornitore a.

Non dovresti confondere i microservizi con i microservizi HTTP però. È possibile nascondere i microservizi codificati a mano dietro tutti i tipi di gateway. Se l'http è un problema per il tuo cliente, perché non lasciare che invii il file via email? o FTP it up, o utilizzare una coda di messaggi per renderlo più basato su eventi ecc.

Vorrei aggiungere un'altra osservazione (controversa). Man mano che una società diventa più grande diventa meno importante automatizzare alcuni di questi processi. Assumendo il personale amministrativo per fare le cose semi manualmente, si aggiunge un livello di flessibilità e una rapida risposta ai cambiamenti a cui un'interfaccia automatica non può competere.

Quel cliente che ha sempre sbagliato il nome del file? Il grande business che non può pianificare lo sviluppo dell'API perché ha un piano tecnico di 5 anni? Quel software di terze parti con cui hai a che fare non espone un'API?

Una volta che hai alcuni di questi problemi, c'è abbastanza lavoro per mantenere occupato un team di amministratori e hai cose migliori da fare per il tuo team di sviluppo sul tuo prodotto principale.