Sto configurando un'architettura di microservizi e sono confuso su come gRPC possa liberamente - accoppiare servizi (rispetto a un servizio di messaggi pub-sub come Kafka). La richiesta non va direttamente al server, e non attraverso un sistema pub / sub? Mentre gRPC supporta richieste asincrone, dovrei comunque utilizzare pub / sub come buffer tra i servizi per ridimensionarli in modo indipendente?
gRPC può fare richieste asincrone, ma è ancora un pattern RPC e quindi è soprattutto per quando non ti interessa la risposta, non per implementare i sistemi di messaggi (sub / pub).
Quello che faccio è, se ho bisogno di RPC, uso gRPC per la comunicazione e ProtocolBuffer per serializzare i dati, e poi quando ho bisogno di messaggi uso AMQP, anche con ProtocolBuffers.
È logico che il gRPC bufferizzi i dati attraverso un sistema di messaggistica se è necessario ridimensionarli, avere routing tra i server o se si desiderano funzionalità come i messaggi offline e anche la notifica di ricezione dei messaggi.
Il mio consiglio è di diagrammare gli scenari di comunicazione su carta e dovrebbe essere chiaro quale tipo di servizio è necessario.
Inoltre, si noti che l'utilizzo di gRPC è in gran parte chiavi in mano e AMQP no; in genere i sistemi di messaggistica richiedono di scrivere molto codice. Se non lo riduci davvero molto, potrebbe essere una quantità eccessiva di lavoro. Inoltre, penso che sia raro che tu voglia entrambi; il pattern RPC è principalmente un sottoinsieme del pattern di messaggistica. Se hai intenzione di superare RPC, utilizza la messaggistica dall'inizio IMO.
gRPC e queue broker non si escludono a vicenda. Non è che dobbiamo scegliere l'uno o l'altro. Potremmo scegliere uno, entrambi o nessuno. Potremmo anche utilizzare un server SMTP come coda o un file di testo normale.
Possono completarsi a vicenda poiché soddisfano diversi scopi.
Pensa in una pipeline in cui ogni fase è un processo (servizio).
[Process A] < ----- > [Process B]
Le frecce indicano la cardinalità e la dipendenza.
Il diagramma mostra due servizi client e server allo stesso tempo. A è client e server di B . E viceversa. Tale IPC implica che i servizi siano consapevoli l'uno dell'altro indipendentemente dal protocollo di comunicazione (HTTP 1/2, socket Web, socket, ecc.).
Ora metti una coda o un intermediario tra
[Process A] <----- > [Queue|Broker] <------> [Process B]
Le frecce indicano la cardinalità o la dipendenza.
Le code e i broker rompono la cardinalità tra i servizi, quindi la dipendenza. Non hanno più bisogno di essere consapevoli l'uno dell'altro. Potremmo persino abbandonare le interfacce pubbliche dei servizi, poiché potrebbero non essere più necessarie. Nessuna interfaccia pubblica, nessun accoppiamento.
Le code e i broker di solito sono progettati per essere performanti / affidabili / coerenti / scalabili / resilienti per quanto riguarda I / O e possiamo fornire alla nostra architettura queste funzionalità implementando l'una o l'altra. Ad esempio, gRPC è un meccanismo di trasporto per richieste / risposte e casi di utilizzo dello streaming (non persistenti). Se non possiamo permetterci i messaggi mancanti, probabilmente dovremo cercare alternative o componenti architetturali complementari. Code e broker potrebbero fare il lavoro. La persistenza non è l'unica funzione per fornire il nostro IPC. Per citarne alcuni
Ho trovato questo post di blog che si tuffa un po 'di più nell'argomento.
Vale la pena menzionare post sul blog Nginx su Microservice e implementazioni IPC .
Sì, la richiesta verrà inviata direttamente al server.
gRPC consente a uno sviluppatore di generare interfacce per i vari servizi. I client devono solo dipendere dall'interfaccia e non da un'implementazione.
in genere le interfacce possono essere progettate per essere retrocompatibili. Pertanto, quando un servizio cambia, vengono aggiunte nuove funzionalità all'interfaccia e nessuna funzionalità viene rimossa. Pertanto i vecchi clienti possono parlare con le nuove versioni dell'interfaccia mentre i nuovi clienti possono accedere alle nuove funzionalità. Una volta aggiornati tutti i client, è possibile rimuovere parti obsolete dell'interfaccia obsolete.
Leggi altre domande sui tag microservices apache-kafka