Progetta l'interfaccia di un microservizio per soddisfare più richieste di assistenza

1

Ho lavorato a un progetto con più microservizi la cui comunicazione avviene tramite chiamate API. Diciamo che microservizio A chiama un servizio fornito da microservice B. Secondo l'attuale implementazione, non abbiamo più API per i diversi servizi forniti da Microservice B; invece quello che abbiamo è una singola API che accetta un parametro che indica quale servizio deve essere invocato.

Penso che sia una cattiva pratica a causa della seguente ragione. Nel codice corrente, ciò che dobbiamo fare è controllare il parametro usando if condizioni e invocare i metodi nei livelli interni di conseguenza.

if (param == service_1) {
    // call service 1 business logic and return
} else if (param == service_2) {
    // call service 2 business logic and return
}
..............
..............
..............
} else if (param == service_n) {
    // call service n business logic and return
}

Questo design andrebbe bene fino a un numero limitato di servizi. Ma per ogni servizio che aggiungiamo al microservizio B, dobbiamo aggiungere una condizione if all'interfaccia sopra indicata che finirà per aumentare la complessità del metodo.

Penso che tu sia d'accordo con la mia preoccupazione sul design sopra. Al momento, sto cercando un modo migliore per risolvere questo problema e trovare un design adeguato per l'API.

Lo so, fornire diverse chiamate API per diversi servizi è un modo corretto. Ma a parte questo, quali possibilità ci sono?

    
posta vigamage 15.11.2017 - 16:39
fonte

1 risposta

4

Sembra che staresti meglio usando una coda. Controlla RabbitMQ o AWS SQS. Apache ha anche un pacchetto open source per l'architettura basata su eventi e / o code chiamata Kafka.

Più interessante, è il servizio AWS SNS che invia immediatamente i messaggi anziché attendere l'elaborazione di una coda. Ciò significa che i tuoi dati sono garantiti per l'espansione verso il proprio endpoint, indipendentemente dal fatto che tali nodi siano attivi e in esecuzione. È più per la messaggistica mission-critical e in tempo reale. Mentre una coda potrebbe introdurre una certa latenza se quei nodi o consumatori non sono online per elaborare il messaggio / carico utile al momento della consegna iniziale.

L'idea è che con ogni richiesta API che si verifica su un rispettivo micro servizio, un payload viene pubblicato sulla coda. Gli abbonati della coda (che saranno gli altri tuoi micro servizi) possono tutti ascoltare più canali e consumare qualsiasi messaggio essi ritengano appropriato per adempiere al loro scopo.

Esempio:

  1. L'utente si è iscritto al sito Web e raggiunge un endpoint API responsabile della pubblicazione di tali dati utente in una coda

    1. Tutti gli altri servizi sottoscritti a quella particolare coda riceveranno i dati pubblicati dal "Produttore".

    2. Ciò consente di avere un servizio esclusivamente per le informazioni persistenti in un database, un servizio per inviare via email all'utente un'email di benvenuto o un servizio che soddisfi qualche altra azione.

Se una coda non sembra adatta, probabilmente vorrai creare un livello di servizio all'interno del tuo micro-servizio middleware.

Il livello di servizio sarà responsabile della memorizzazione di classi che interagiscono con sistemi esterni e altre API. Quando un particolare endpoint viene colpito all'interno dell'API sul servizio A, il controller appropriato (o qualunque sia il punto di ingresso) deve caricare un particolare servizio, eseguire una richiesta al servizio-B e il controller per il servizio-A dovrebbe gestire i dati di risposta e produrre una risposta per la macchina client.

Speriamo che questa risposta abbia aiutato alcuni.

    
risposta data 15.11.2017 - 19:06
fonte

Leggi altre domande sui tag