Servizio Fabric Microservice equivalente AMQP

1

TLDR; Esiste un AMQP equivalente all'interno di Service Fabric per i servizi stateless per la comunicazione tra microservizi?

Sto costruendo un'applicazione che contiene più microservizi.

Per i principianti questa applicazione avrà i microservizi bloccati dietro il gateway API. Questo gateway API è accessibile pubblicamente dalla mia applicazione web o tramite un URL fornito dal gateway.

Motivo per cui lo sto spiegando? I microservizi saranno in grado di comunicare tra loro e potranno essere utilizzati dagli sviluppatori per collegare tutto ciò che desiderano. Da questo post, ho capito che un'interfaccia REST è utile per esporre il tuo servizio al pubblico, mentre si utilizza AMQP (Advanced Messaging Query Protocol) per richiedere elementi dal database o altri servizi. Da questo post ho capito che AMQP è il metodo di comunicazione preferito tra i servizi perché è completamente asincrono.

Quindi, in base a questo, sto cercando un'implementazione in cui i miei microservizi dispongono di un'interfaccia REST e useremo AMQP per interrogare i dati che vengono richiesti tramite l'interfaccia REST.

Poiché utilizzo Service Fabric e reinventare la ruota è una perdita di tempo, mi chiedo se Service Fabric sia dotato di una soluzione "pronta all'uso" per AMQP o no. Ho visto IReliableCollection vieni, ma la documentazione mi ha dato l'impressione che fosse limitato ai servizi di stato (ho dimenticato di menzionare i miei servizi sono senza stato)

Grazie mille.

    
posta Bart de Ruijter 10.07.2017 - 17:46
fonte

1 risposta

2

No, Service Fabric non fornisce alcun meccanismo di messaggistica per comunicare con servizi affidabili. In pratica, i servizi affidabili (stateful e stateless) sono fondamentalmente processi in esecuzione senza fare nulla finché non si dice loro di fare qualcosa. Sei responsabile di creare il meccanismo per consentire a un servizio di ricevere richieste di lavoro (con servizi remoti, REST, messaggistica ...). Service Fabric fornisce solo le basi su come implementare questo meccanismo che è ICommunicationListener .

Se si desidera una comunicazione asincrona tra servizi, è possibile utilizzare, ad esempio, il bus di servizio di Azure e utilizzare un listener di comunicazione pronto all'uso. .

Ora, l'uso della messaggistica non risolve completamente il tuo problema di avere processi in esecuzione lunghi, poiché l'avvio di un lungo processo può essere eseguito in modo sincrono (ad esempio, puoi chiamare il tuo servizio con REST e il servizio potrebbe tornare immediatamente con un OK e avviare il processo di lunga durata in modo che il client non sia in attesa in modo sincrono). Il problema principale con i processi a lunga esecuzione è normalmente come comunicare al client che il processo è stato completato. Si noti che essendo servizi stateless, non è possibile eseguire il polling del servizio per ottenere lo stato del processo in quanto la richiesta potrebbe andare a un'istanza diversa del servizio (e andrebbe comunque contro le regole di progettazione dei servizi stateless).

Se il tuo scenario è di due microservizi che parlano tra loro, hai diverse opzioni per comunicare i risultati. Se si sta introducendo una dipendenza circolare, è possibile eseguire semplicemente una chiamata REST da A a B per avviare il processo e una chiamata REST da B a A per comunicare il completamento.

Se si utilizza la messaggistica, è possibile creare un meccanismo per consentire le risposte, senza introdurre una dipendenza circolare, ad esempio inviando la coda di risposta come parte del messaggio originale (o delle proprietà del messaggio in ASB). In questo modo il tuo servizio B non deve sapere nulla del chiamante.

Spero che abbia senso.

    
risposta data 17.02.2018 - 23:22
fonte

Leggi altre domande sui tag