Micro Service con gateway API

Question

Per il mio nuovo progetto, devo utilizzare i servizi Micro con Gateway Api. Così ho raccolto informazioni dettagliate su Micro Service ma la parte Api Gateway non è chiara.

La mia domanda è,

1. C'è qualcuno che sa su come la richiesta di routing parte è fatto in Api Gateway?
2. è che può essere fatto da semplice se la condizione [codice pseudo: se (parola chiave == "prodotto"), poi percorso ("product service")]?
3. Oppure è un modo migliore di farlo?

Sto usando C# .Net per sviluppare Api.
ho ottenuto alcune informazioni su Api Gateway da https://www.nginx.com/blog/building-microservices-using-an-api-gateway/

Answer 1

È praticamente chiesto tre domande e sono tutti in qualche modo legati quindi farò del mio meglio per affrontare tutti e tre insieme.

Per uno, l'instradamento delle richieste in un gateway API è più di un semplice proxy e l'implementazione non implica condizioni per esaminare la richiesta prima di inviarla a un servizio a valle. Il gateway API potrebbe essere l'unico punto di accesso ai servizi in cui l'autenticazione sarebbe gestita dal livello per garantire che una richiesta abbia il permesso di accedere a un servizio a valle. L'autenticazione è probabilmente un altro servizio stesso. L'implementazione di alto livello del gateway API è in grado di consolidare la maggior parte se non tutti gli endpoint su tutti i servizi downstream.

Consente di fare un piccolo esempio come un'applicazione di e-commerce che include un servizio per l'elencazione di prodotti, la ricerca di prodotti e carrelli della spesa. Il gateway API avrà quindi anche questi stessi endpoint e delegherà ulteriormente la richiesta a un servizio responsabile della richiesta. L'API in questo esempio potrebbe avere /products per elencare tutti i prodotti, /products?query=... per cercare prodotti e infine /carts/:id/products per elencare i prodotti in un carrello. Spero che questo risponda alla tua domanda.

A parte questo, so che hai menzionato che è un nuovo progetto e volevo solo darti 2 centesimi che questa potrebbe non essere la migliore architettura da utilizzare per il tuo nuovo progetto se la tua squadra è davvero piccola perché c'è un grande sovraccarico operativo. Sovraccarico che richiede la standardizzazione, l'automazione delle implementazioni, l'integrazione, ecc. Probabilmente è meglio iniziare con un'architettura MVC tradizionale e lentamente trasformarlo in microservizi quando il progetto è decollato.

Answer 2

A seconda dell'architettura, è possibile utilizzare alcuni software davvero interessanti come Weave with CoreOS (https://github.com/weaveworks/weave). Stiamo utilizzando Docker per distribuire le nostre applicazioni sui nodi CoreOS, quindi il DNS interno viene gestito da Weave.

Questo è davvero ottimo perché possiamo semplicemente inoltrare la richiesta al nome dell'applicazione con una porta, e quindi siamo fuori e fuori.

Ad esempio, un utente richiede application.com/api/apiName/request/path~~V~~3rd

La nostra porta è stata implementata con nodo.js, e prende l'apiName after/api per instradarlo su quell'api, e quindi il seguente percorso dell'URL da aggiungere alla chiamata stessa.

Quindi la richiesta dal gateway verrebbe inoltrata internamente come apiName: 8080/request/path. A tale riguardo, l'API non richiede modifiche quando vengono visualizzati nuovi servizi, poiché il percorso viene creato dinamicamente dalla richiesta.

Questo è ottimo perché non dobbiamo preoccuparci di tracciare i percorsi dalle diverse API e di memorizzarli da qualche parte.

In caso contrario, è necessario mantenere un elenco (probabilmente esterno) di endpoint per renderlo più semplice. Questo potrebbe essere fatto a livello di codice dalle stesse API.

Non sono sicuro quali siano le vostre esigenze, tuttavia, e come Will ha risposto, comporta costi infrastrutturali piuttosto grandi. Tuttavia, i nostri rilasci sono rapidi e indolori perché non dobbiamo preoccuparci di apportare modifiche al codice in più livelli e le nuove API ottengono il nostro proxy proxy, registrazione e autenticazione gratuitamente.