Best practice per ridurre le chiamate nell'architettura dei microservizi

Question

Best practice per ridurre le chiamate nell'architettura dei microservizi

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

3

Ho più artefatti (applicazioni) distribuiti su host diversi (chiamiamoli A, B e C per semplicità) e attualmente sto cercando un tipo di modello di integrazione, perché devo ridurre il numero di chiamate al backend, in modo che non abbia bisogno di chiamate separate per A, B e C, ma piuttosto una chiamata a D che raccoglie tutte le informazioni e la restituisce al client. Lo considero come una specie di applicazione di aggregazione.

Ho letto il libro di Sam Newman su Microservices e sto cercando di implementare qualcosa che sia conforme al modello "Backend for frontends", il che significa che ogni canale (mobile, web) ha una propria interfaccia RESTful. Parla anche delle chiamate interne, ma non dei dettagli di implementazione.

Uso Java (RestEasy) per tutte le applicazioni e ho pensato di utilizzare Retrofit per l'invio di chiamate interne, che potrebbe risolvere alcuni dei miei problemi. Ci sono altri quadri da recensire?

Inoltre, mi piacerebbe avere una sorta di re-routing automatico in atto e non so se questa è la strada da percorrere. Provo a spiegarlo con un esempio: c'è un endpoint GET / cliente / nome utente / qualcosa / istruzioni che possono essere utilizzate solo dagli utenti verificati. Se un cliente non viene verificato, l'endpoint deve restituire informazioni sull'upgrade che è possibile recuperare chiamando GET / cliente / nome utente / verifica. Così ho pensato a diverse opzioni:

/ customer / nomeutente / sometool / istruzioni restituisce un'eccezione, il programma di lettura delle eccezioni legge il codice di errore (qualcosa come "cliente non verificato") e il programma di mappatura delle eccezioni sa che deve raccogliere le informazioni da / customer / username / verification - & gt ; lato negativo: il mapping delle eccezioni diventerà onnipotente nel tempo
/ customer / username / sometool / instructions controlla se il cliente è già verificato, e in caso contrario chiama / customer / username / verification e raccoglie le informazioni - > lato negativo: aggiunge logica alle istruzioni endpoint che in realtà non appartengono alle istruzioni
un modulo aggregatore che funziona con annotazioni che vengono intercettate prima che venga richiamato MessageResponseWriter. Qualcosa di simile a: @OnFailure (errorCode="notverified" invoke="/ customer / username / verification") - > lato negativo: ancora una volta, l'aggregatore diventerà onnipotente

Come pensi che dovrebbe essere implementato?

java architecture microservices soa

posta Daniel 02.05.2017 - 11:22

fonte

3 risposte

Leggi altre domande sui tag java architecture microservices soa

Come ridurre la dipendenza nelle comunicazioni tra i server Qual è più pitone: controllando l'esistenza e non essere None, o usando la verità e get () con dicts?

score 2 · Answer 1

Sembra che lo schema che stai cercando sia Gateway API . Talvolta chiamato anche "Edge" o "EdgeService". Può essere utilizzato come singolo punto di accesso al cluster e per aggregare i risultati delle chiamate di servizio. Altri casi d'uso includono l'autenticazione e / o l'autorizzazione centrale, nonché il routing, il monitoraggio e la resilienza.

Alcune persone indirizzano solo le chiamate esterne attraverso un gateway, altre instradano anche le chiamate interne attraverso il gateway.

Ecco alcune tecnologie da esaminare:

Zuul dallo stack Netflix. Hai scritto un filtro per l'aggregazione.

Amazon API gateway - Se stai utilizzando AWS (molto comodo se usi Lambda).

Kong .

score 1 · Answer 2

Un modello per il tuo primo requisito di ridurre le chiamate al back-end (A, B & C) non è tanto un modello di integrazione ma di solito chiamato "Facciata", il che significa semplicemente che c'è un'interfaccia facile da capire che fornisce operazioni questo ha senso per un dato cliente, come un'app mobile. Quella facciata internamente può quindi orchestrare le chiamate ad altri moduli o sistemi (A, B e C) al fine di adempiere ai suoi doveri. Si potrebbe anche trovare questo spesso chiamato un mediatore, che oltre alla facciata semplice soddisfa la mappatura da e in diverse strutture di dati (strutture lato client vs server).

Poiché si desidera utilizzare un'API REST, non è necessario implementare la logica per l'autenticazione client sul server ma sul lato client. L'interfaccia API server restful significa che non si cura dello stato sul server, ovvero non sa se un client è autenticato o meno a meno che il client non trasmetta informazioni che indicano che, come un token o un segreto, ecc. Il routing nel caso di errore dovrebbe essere implementato a livello del cliente. Ci sono molti esempi di Angular2 che mostrano questo tipo di implementazioni.

La paura che un error mapper diventi troppo potente non è realmente valida se si implementa il client in modo modulare, ovvero diversi controller che sono responsabili dell'invio / ricezione di informazioni per una parte dell'app. Dovrebbero avere una gestione degli errori molto esplicita e dal momento che sono solo responsabili di alcuni aspetti dell'app non dovrebbero crescere eccessivamente.

Spero che ti aiuti un po 'a partire dal tuo sistema!

Saluti, Lars

score 0 · Answer 3

Voglio metterti in guardia contro la condivisione dei dati tramite eventi. Molto presto smetterete di capire chi è il proprietario di un dato dato. L'unica fonte di verità per i tuoi dati sarà inevitabilmente vaga.

L'architettura basata su eventi utilizza eventi per notificare ad altri servizi cosa è successo, in modo che possano avviare i propri processi. Gli eventi non sono mai stati pensati per la trasmissione di dati. Molto spesso significa che i limiti di servizio sono errati . Anche se mi rendo conto che la tua domanda riguarda i frontend, probabilmente troverai il post sottolineando il mio punto una lettura utile.