Best practice per l'architettura di integrazione per le applicazioni Enterprise

Question

La nostra applicazione si integrerà come un consumatore in una serie di sistemi esterni.

Molte di queste integrazioni non riguardano solo l'elaborazione e il routing dei messaggi. Ci sono un sacco di logica complessa, come la memorizzazione di uno stato attuale, esecuzioni programmate e altre cose.

Inoltre, ogni integrazione non condivide molta logica comune.

Qual è la procedura migliore per realizzare questo tipo di sistemi?

Devo creare un livello di integrazione all-in-one? Può essere un'applicazione monolitica con differenti percorsi apache cammello e processori per ogni integrazione:

o devo dividere a un gruppo di piccoli e semplici applicazioni standalone modo che possano essere scalati e distribuiti in modo indipendente?

Quali sono i vantaggi e gli svantaggi posso ottenere con ogni soluzione?

Answer 1

Ci sono alcuni criteri da avere in mente:

• Economia: costo del progetto, i costi operativi
• Throughput: volume di dati per unità di tempo
• Latenza: tempo di percorrenza di messaggi
• Sicurezza: protezione dati
• Affidabilità: likelyhood di fallimenti
• Flessibilità: facilità di reagire alle mutevoli esigenze
• processo di supporto: il controllo del flusso di dati, evento/gestione

La scelta di un buon errore l'architettura della soluzione dipende dall'importanza di tali criteri per il dato ambiente IT. Per le applicazioni aziendali, è abbastanza comune utilizzare una piattaforma di integrazione piuttosto che costruire la logica di integrazione nelle applicazioni. Tale piattaforma include in genere componenti per la connettività, la mappatura del messaggio, il routing, monitoraggio/allarme, la registrazione, la contabilità, gestione del cambiamento, ecc

Chiedete al vostro motore di ricerca preferito per Integration Patterns o Enterprise Application Integration.

Answer 2

Lasciatemi condividere la mia opinione. In generale, come Axel Kemper ha affermato, ci sono molti fattori che possono influenzare la tua decisione e non esiste una soluzione di proiettili d'argento qui.

Cercherò di tenerlo tecnico, quindi:

Un'applicazione monolitico:

• più facile da distribuire. In generale, avrai bisogno solo di un/un paio di server. Dal punto di vista dello sviluppatore, la differenza potrebbe non essere ovvia, ma parla al tuo team di sviluppatori e diranno immediatamente che distribuire un'applicazione è molto più semplice per loro

• È più facile da monitorare. Fondamentalmente per lo stesso motivo di cui sopra. Chiedi a devOps anche su questo :)

• Può essere più veloce. Se diverse App di integrazione dovessero interconnettere in qualche modo (non è indicato nello schema, però), allora potenzialmente potrebbero soffrire di un lento protocollo "over-network". In un'applicazione monolitica, tutto è all'interno della stessa JVM.

• Richiede potenzialmente meno server. Se stai utilizzando un cloud privato/un ambiente obsoleto, può essere piuttosto complicato collegare un nuovo server. È possibile ottenere 2-3 server per l'applicazione e il gioco è fatto :)

architettura "applicazioni di integrazione multipla" (nella mia comprensione Assomiglia davvero architettura micro-servizi nel dominio di integrazione) ha i seguenti vantaggi:

• Più facile aggiornare parti diverse di esso. Se si dispone di un'applicazione monolitica, non esiste un modo normale per aggiornare solo parte dell'API, dovrebbe esserci un grande aggiornamento per l'intera applicazione. Se diversi "punti di integrazione" sono sviluppati da diversi team, non è ovvio coordinarsi tra le versioni.

• Come risultato del punto precedente, ci vorrà meno tempo per correggere un bug in un punto di integrazione (dal momento in cui il bug è stato rilevato al momento in cui la correzione viene distribuita in produzione). Basta correggere un particolare punto di integrazione e ridistribuirlo. È molto più leggero.

• Bilance "fuori" meglio. Se si verifica un utilizzo intensivo di un particolare punto di integrazione, è possibile aggiungere facilmente un altro (o più) su un altro server. In un approccio monolitico dovrai installare l'intera applicazione per ottenere un effetto simile. Un altro caso d'uso è che se si è distribuiti in un cloud e si ha un cliente disposto a pagare per un accesso esclusivo a un particolare punto di integrazione.

• Più facile da testare (probabilmente). Se si stanno eseguendo test di integrazione/sistema per verificare il proprio punto di integrazione, è possibile organizzare il flusso CI in modo che il sistema venga eseguito solo in parallelo. Aggiungi a questo un avvio molto più leggero e otterrai un flusso molto più flessibile.

Potrei aver perso alcuni aspetti del confronto (di sicuro) ma questa è la direzione IMO.

Spero che questo aiuti