Scoping di ID di correlazione in microservizi

4

Abbiamo un microservizio che legge in file di dati di grandi dimensioni, ogni riga contenente informazioni sugli account.

Per ogni record trovato, si spegne e fa altre "cose" e quella roba è distribuita su altri microservizi. Pertanto, dobbiamo considerare l'uso degli ID di correlazione per legare insieme le transazioni distribuite da una prospettiva di registrazione.

Tuttavia, stiamo lottando per comprendere i limiti di questi ID di correlazione.

Sono consapevole del fatto che l'entità generale è "usa un ID di correlazione che ti è stato dato o ne crea uno", ma è la singolarità di quell'ID di correlazione che ci sta dando il problema.

Ad esempio:

  • il file di dati contiene 1.000 record di account: sarebbe utile ritirare i registri di tutte le attività su quel 1 file di dati attraverso i 1.000 account; ma
  • sarebbe anche utile per solo richiamare i registri risultanti per un singolo account nel file di dati.

Quindi è necessario che siano necessari due ID di correlazione separati, uno per il file, uno per l'account, quasi uno stack.

Tuttavia, nulla di ciò che ho visto sull'interweb si avvicina mai alla correlazione in questo modo, quindi immagino che il mio modo di pensare / design sia sbagliato.

Qualche consiglio? Come sono stati gli altri a occuparsi di questo?

    
posta Chris Wood 07.02.2018 - 17:15
fonte

4 risposte

1

Ho pensato un po 'a questa domanda e penso di aver trovato un modo per ottenere ID composti, abbastanza significativi per noi da cercare e correlare file, account e transazioni .

account_id@sercive_name://file_path/file_name.ext

È fondamentalmente un URI. Abbastanza significativo per noi per sapere l'account , il file da cui proviene e il servizio coinvolto nella sua elaborazione .

Ora, dovremmo decidere dove inserire l'ID di correlazione che identifica l'intera transazione.

Potrebbe essere nella stringa di query

account_id@sercive_name://file_path/file_name.ext?transaction=ID

Oppure potrebbe far parte delle credenziali *

account_id:tx_id@sercive_name://file_path/file_name.ext

I servizi devono solo sostituire nome_servizio con il suo nome (o qualsiasi tipo di codice di servizio che potremmo avere).

Potremmo aggiungere ancora più informazioni, come ad esempio la data del processo

account_id@sercive_name://file_path/file_name.ext?transaction=ID&intake=yyyy-MM-ddTHH:mm:ss+00:00

Nei sistemi distribuiti, potrebbe essere interessante conoscere anche l'istanza del servizio. Ad esempio, come sottodominio

account_id@sercive_name.instance.server_name://file_path/file_name.ext?transaction=ID&intake=yyyy-MM-ddTHH:mm:ss+00:00

Non c'è bisogno di dire che potremmo scambiare la posizione degli elementi. Ad esempio

tx_id@sercive_name.instance.server_name://file_path/file_name.ext?account=account_id&intake=yyyy-MM-ddTHH:mm:ss+00:00

o

tx_id@sercive_name.instance.server_name://accounts/{id}?file=file_name.ext&intake=yyyy-MM-ddTHH:mm:ss+00:00

Scopri qual è la soluzione adatta alle tue esigenze di ricerca. Ricorda che più informazioni ha, meno possibilità di collisione e più informazioni vengono recuperate per query.

* Onestamente, l'ultimo non mi piace tanto quanto il primo. Se dovessi scegliere, vorrei andare per il primo.

    
risposta data 06.10.2018 - 21:59
fonte
0

È possibile aggiungere un prefisso all'ID di correlazione per il file. Dovresti generare un ID di correlazione per il file, quindi quando inizi ad elaborare ogni singola riga aggiorna l'ID di correlazione per aggiungere un nuovo suffisso. Questo fa alcune ipotesi sulla tua capacità di controllare l'ID di correlazione e cercare i prefissi.

    
risposta data 07.02.2018 - 17:26
fonte
0

crea un "." ID di correlazione separato e inserire qualsiasi livello di informazioni che si desidera inserire, quindi qualcuno che toglie il registro da diff. i microservizi dividono l'id di correlazione in base a "." e fornisce la vista che desideri

    
risposta data 08.02.2018 - 07:47
fonte
0

C'è una convenzione Zipkin per fare proprio questo, che usa un trace-id , parent-span-id e span-id . Il livello più alto (cosa che ha avviato tutto) crea un id-traccia con un id-span avente lo stesso valore dell'ID-traccia. Non ha un parent-span-id. Questo potrebbe essere nel tuo caso il file. Ogni unità downstream avrebbe lo stesso valore trace-id e un valore span-id appena generato con il valore parent-span-id imposta l'inizializzazione span-id . Può esserci ulteriore nidificazione di span-id s. Anche se Zipkin è pensato per l'uso oltre i confini della rete con intestazioni specificatamente denominate, l'ho utilizzato anche in un singolo processo di applicazione per delineare le parti per la registrazione. Quicklog.io è un servizio di registro eventi tracciabile che potrebbe interessarti. Ecco alcune informazioni sulle intestazioni di Zipkin link

    
risposta data 08.10.2018 - 00:26
fonte

Leggi altre domande sui tag