Considerazioni sulla progettazione dell'IPC

3

Nella nostra architettura interna, abbiamo diversi server Tomcat che distribuiscono il carico di lavoro e isolano i diversi processi della nostra attività. Stiamo pianificando di passare a un approccio in cui diverse attività (principalmente correlate a BD) saranno gestite da un endpoint Tomcat (bilanciato per disponibilità e prestazioni), ma siamo turbati nel determinare quale potrebbe essere il metodo di migliore pratica per la comunicazione interna tra le diverse app Web eseguite nei diversi server Tomcat. Abbiamo già utilizzato HornetQ, MQTT (basato su Mosquitto) e HTTP per diversi aspetti, ma considerando che questo endpoint pianificato dovrebbe esporre internamente un'API agli altri server.

L'obiettivo principale di questo cambiamento di architettura è di evitare problemi legati al fatto di avere diversi software che eseguono lavori simili, ma con regole e algoritmi diversi, portando così a errori di codifica e comportamenti non uniformi all'interno del sistema per un entità singola.

Che cosa dovrebbe essere considerato? Quale comunicazione inter-processo sarebbe effettivamente raccomandata? Qualche tipo di ESB, forse?

    
posta Gonzalo Vasquez 07.02.2017 - 20:39
fonte

1 risposta

1

The main goal of this architecture change is to avoid problems related to the fact of having different pieces of software doing similar work, but with different rules and algorithms, thus leading to coding mistakes and non-uniform behaviors across the system for a single entity.

Il modo in cui lo fai è creare un'API e richiedere a tutti di utilizzare quell'API per i loro processi aziendali. Stabilendo un'architettura semplice, puoi fornire una piattaforma comune che tutti possono seguire.

Il modo in cui implementate quella piattaforma dipende interamente da voi. Come hai già sottolineato, ci sono diversi modi per farlo. Prenderò in considerazione un'implementazione del modello di attore come Akka; ha IPC integrato (sotto forma di caselle di posta elettronica di messaggistica), funzioni robuste per ridondanza e affidabilità ed è infinitamente scalabile. Puoi creare un sistema di workflow su di esso, se lo desideri.

L'eliminazione del debito tecnico sarà un processo graduale per spostare ogni bit delle funzionalità esistenti nella nuova API e rimuoverne le occorrenze multiple altrove.

    
risposta data 08.02.2017 - 18:24
fonte

Leggi altre domande sui tag