Indipendentemente dal tipo di canale o mezzo di comunicazione esistente tra due interfacce, quando il produttore modifica il formato del messaggio che i consumatori sanno come accettare, c'è un rischio di cambiamento sui client.
The whole idea of using a AMQP broker is to be sure that the services can communicate with each other without them knowing each other. So the producer doesn't know the consumers. That's what is making this pretty confusing for me.
Questa non è la ragione per cui si dovrebbe usare l'accodamento di messaggi asincroni in un'applicazione. Questo è il motivo per cui si impiegherebbe l'architettura SOA (Service Oriented Architecture) e Microservice. Pensa alle code dei messaggi come a un semplice canale di comunicazione con alcune proprietà speciali come la perdita di messaggi zero, la consegna garantita dei messaggi, la messaggistica asincrona e la più facile capacità di sviluppare transazioni reversibili su un messaggio.
Il formato del messaggio è essenzialmente il contratto che il produttore e il cliente concordano nello scambio di messaggi. Il cliente non deve conoscere il funzionamento interno del produttore, tuttavia deve essere in grado di ragionare sul produttore in termini di contratto. I componenti software sono ragionevolmente disaccoppiati. Ciò significa che se il produttore stava persistendo dati in un database, allora è possibile rifattare il database in modo fattibile, e fintanto che non si modifica il formato del messaggio, i clienti vengono ragionevolmente astratti da questo cambiamento, riducendo così i rischi.
Questo è l'aspetto dell'architettura software. Misura e ragiona sugli attributi qualitativi del software (modularità, componibilità, ecc.) Per prendere decisioni e compromessi per mitigare i rischi.
Se devi modificare il formato del messaggio, allora stai modificando il contratto. Il modo migliore per procedere in avanti è adottare un approccio disciplinato.
- Formalizza il formato del tuo messaggio. I formati strutturati come XML sono buoni qui perché posso definire uno schema XML che posso utilizzare per applicare e convalidare un messaggio.
- Crea la versione XSD in modo che sia più facile ragionare, identificare e descrivere i clienti che utilizzano il tuo servizio.
- Stub il servizio con uno strumento di derisione. Puoi farlo con strumenti di test delle unità o qualcosa di più sofisticato come SoapUI per emulare una modifica del formato dei messaggi del provider che non è ancora stata implementata.
- Esegui i test dei componenti e dei componenti dei tuoi clienti sulla tua interfaccia stubbata e verifica i casi d'uso.
- Implementa la modifica del provider, quindi l'unità e il componente testano questo contro i casi d'uso.
- Eseguire test di integrazione del sistema per verificare che client e provider comunichino correttamente tra loro.