Convalida dei messaggi in servizi di messaggistica asincrona

Naviga le tue risposte
6

Sto cercando informazioni sull'approccio migliore alla convalida dei messaggi nei servizi basati su messaggistica asincrona (ovvero servizi che estraggono messaggi da una sorta di coda di messaggi o broker, piuttosto che fornire un'API basata su HTTP o qualcosa di simile richiesta -risposta orientata).

In un'API HTTP, se il messaggio non è valido (campi errati, JSON / XML / Qualunque) non valido, puoi restituire un errore 400. Il servizio di ricezione può continuare come prima e il mittente deve gestire l'errore. (Molte librerie HTTP generano un'eccezione quando viene restituita una risposta non 200, rendendo molto chiara la fonte del problema.)

Con i processi di messaggistica asincrona, posso pensare ad alcuni approcci:

  1. Il processo di ricezione gestisce l'errore in qualche modo.
  2. Il servizio di ricezione ignora solo i messaggi che non sono validi.
  3. Il servizio ricevente registra il messaggio non valido e quindi passa al messaggio successivo. Se le cose non sembrano funzionare correttamente, si spera, possiamo individuare il problema nei registri.
  4. Il servizio di ricezione invia una notifica di errore su un qualche tipo di canale di risposta.

Nessuna di queste opzioni sembra particolarmente buona.

L'opzione (1) è in realtà solo una "mano d'onda" nella direzione di una soluzione ancora sconosciuta.

Le opzioni (2) - (3) sembrano correre il rischio che i problemi nel codice del mittente vengano mascherati e resi difficili da identificare (rispetto alla situazione richiesta-risposta, dove è possibile identificare immediatamente una risposta 400, che si verifica in una "posizione" strettamente collegata alla fonte dell'errore).

L'opzione (4) sembra tentare di ricreare un sistema di richiesta / risposta, annullando qualsiasi motivo per optare per un sistema basato su messaggistica asincrona. Se hai intenzione di richiedere / risposta, perché dovresti utilizzare un sistema basato sul broker di messaggi in primo luogo?

Gradirei qualsiasi informazione sulle migliori pratiche e su come la tensione descritta sopra potrebbe essere risolta.

    
posta samfrances 20.02.2018 - 00:45
fonte

5 risposte

1

La maggior parte delle piattaforme * Message Oriented Middleware forniscono un meccanismo per schematica validazione ( cioè contro uno schema ) dei messaggi in arrivo man mano che vengono accodati. Questa è la logica che controlla elementi come campi mancanti / nulli, valori al di fuori di determinati intervalli, formattazione errata, ecc. Tuttavia, poiché questi controlli vengono eseguiti dal broker dei messaggi e non dal sistema finale, non è possibile controllare i riferimenti esiste l'ID cliente, l'ordine esiste, ecc.

* "Most" dei broker di messaggi strongmente tipizzati, non solo sistemi che accodano le stringhe stupide.

Ad esempio, in JMS è possibile assegnare un metodo "Validator": link

Credo che la WCF abbia qualcosa di simile, la cosa più vicina che ho trovato è stata questo articolo .

Per quanto riguarda le opzioni, credo che 4 sia probabilmente il più comune. Vi sono motivi (relativi alla scalabilità) perché questo canale di risposta è preferibile a un sistema basato su richiesta-risposta (posso convalidare il tuo messaggio e inviarti l'eccezione ogni volta, invece di legare un socket + processo / thread su ciascuna estremità mentre tu aspetta che lo faccia vivere, ecc.)

    
risposta data 20.02.2018 - 01:39
fonte
1

Puoi anche inviare il messaggio a una coda di messaggi non recapitabili

In message queueing the dead letter queue is a service implementation to store messages that meet one or more of the following criteria :

Message that is sent to a queue that does not exist.

Queue length limit exceeded.

Message length limit exceeded.

Message is rejected by another queue exchange.

Message reaches a threshold read counter number, because it is not consumed.

Sometimes this is called a "back out queue". Dead letter queue storing of these messages allows developers to look for common patterns and potential software problems.

    
risposta data 26.02.2018 - 18:31
fonte
0

Ho lavorato con un'API basata su code da alcuni anni e ho trovato che la soluzione implementata funzionava perfettamente. Quello che hanno fatto in questa API è questo:

  1. Il client invia un messaggio da gestire a un endpoint REST
  2. Il messaggio è convalidato per la correttezza. Se non è valido, la risposta è un errore HTTP, 200 viene restituito altrimenti, contenente un id che identifica il messaggio nella coda
    1. Se si verifica un errore durante la gestione del messaggio, viene registrato in un file di registro separato
    2. Un client può sempre interrogare la coda attraverso un endpoint separato, trovando lo stato corrente del messaggio che ha messo in coda (o interrogando per tutti gli errori, ad esempio)

HTH.

    
risposta data 20.02.2018 - 09:16
fonte
0

Per quanto ho visto nel mio progetto corrente, # 4 è quello usato - Invia la notifica al canale sorgente se i controlli di validazione falliscono.

    
risposta data 24.02.2018 - 09:10
fonte
0

Abbiamo creato una libreria centrale con la richiesta, la logica degli oggetti di risposta per serializzare, deserializzare, spingere e ricevere dalla coda e validatori di parametri di base per tali scenari.

Ogni servizio include questa libreria comune e lo utilizza per accedere alle code. Le convalide dei parametri di base vengono eseguite attraverso questa libreria prima di spingere la richiesta e rifiutate in caso di errore prima di spingere.

Le convalide basate sulla logica aziendale vengono eseguite dai servizi e vengono respinte sul canale di risposta / le notifiche vengono generate in caso di errore.

    
risposta data 25.02.2018 - 10:54
fonte

Leggi altre domande sui tag

Ascolta le modifiche dei dati (base) usando Clean Architecture Qual è la migliore implementazione per la sincronizzazione delle app per dispositivi mobili offline?