Implementazione di un microservizio di memorizzazione nella cache evitando potenziali colli di bottiglia

Question

Implementazione di un microservizio di memorizzazione nella cache evitando potenziali colli di bottiglia

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

4

Il sistema su cui sto lavorando impiega un meccanismo di caching / preloading piuttosto sofisticato per terze parti esterne e, poiché è basato su un'architettura di microservizio, vorrei estrarre l'intera funzionalità di caching / preloading da un microservice di funzionalità (per esempio , prenotazione / ricerca) ad uno dedicato:

+-----+      +--------------------+            +----------+
| API | <--> | booking | internal | <--------> | external |
|     |      | service | cache    |            | service  |
+-----+      +--------------------+            +----------+

versus

+-----+      +---------+      +---------+      +----------+
| API | <--> | booking | <--> | caching | <--> | external |
|     |      | service |      | service |      | service  |
+-----+      +---------+      +---------+      +----------+

Sono preoccupato dei potenziali colli di bottiglia che questo potrebbe introdurre: invece del microservizio di prenotazione che utilizza un sistema di cache interno che parla con un back-end, comunicherà con un microservizio separato per tutte le chiamate get / set (che a sua volta parla al backend). Il collo di bottiglia che vedo è principalmente il tempo aggiunto per comunicare attraverso il microservizio aggiuntivo. Questa dovrebbe essere una grande preoccupazione? Come devo affrontare la comunicazione tra il microservice di prenotazione e quello di memorizzazione nella cache (REST, code di messaggi)? Dovrebbe essere la comunicazione sincrona, per quanto vedo le cose. Quali altri colli di bottiglia (nascosti) possono sorgere da questa configurazione?

rest microservices caching message-queue

posta linkyndy 14.04.2017 - 14:39

fonte

3 risposte

Leggi altre domande sui tag rest microservices caching message-queue

come migliorare la stabilità della build in una squadra DDD: devono tutte le relazioni del modello Aggregati o possono essere "superficiali"?

score 7 · Answer 1

Il mio suggerimento è che invece di preoccuparti se utilizzare una cache esterna o interna, la prima preoccupazione dovrebbe essere che al tuo servizio di prenotazione non importi indipendentemente dal fatto stai utilizzando un servizio esterno.

Cioè, il tuo servizio di prenotazione dovrebbe essere messo in cache contro un'interfaccia con l'implementazione concreta inserita; non avrebbe saputo o importato se stesse usando:

Un servizio di memorizzazione nella cache esterna (fuori processo)
Una cache interna (in elaborazione)
Un pass through cache che è andato direttamente al servizio esterno

A un certo punto, potresti persino sviluppare un sistema che utilizzava una combinazione intelligente di esterni e interni.

Una volta che questo comportamento è correttamente isolato, sei molto più libero di esplorare i vantaggi e gli svantaggi di ciascuna soluzione per il tuo caso d'uso specifico.

score 2 · Answer 2

In effetti stai creando un grave collo di bottiglia e un singolo punto di errore nella catena.

Probabilmente sarebbe più appropriato impostare più istanze del servizio di caching come proxy per ognuno dei tuoi servizi effettivi (magari avendo ciascun proxy proxy per un numero ma non tutti i servizi per salvare alcune porte di rete). Un'altra opzione è che ogni servizio implementa il proprio caching utilizzando un sistema di caching generico (che si estende da un servizio astratto che crea e gestisce la cache, ad esempio, con le classi di implementazione che non chiamano direttamente i servizi esterni ma lo lasciano in un metodo in la base astratta che gestisce anche la memorizzazione nella cache).

C'è qualcosa da dire per entrambe le varianti. Il primo naturalmente significa che potresti avere meno sforzi iniziali di codifica, ma hai un carico di rete maggiore internamente. Il secondo ha un carico di rete inferiore, ma dovrai fare più lavoro per riscrivere i tuoi servizi esistenti per implementarlo (e per i servizi futuri che i tuoi dipendenti devono rispettare quando li codificano piuttosto che quando li configuri, ti fidi dei tuoi programmatori o i tuoi specialisti di implementazione di più? O sono le stesse persone ...).

score 2 · Answer 3

Vedo solo tre buoni motivi per cui è necessario estrarre la cache:

Più servizi interni interagiscono con lo stesso servizio esterno. Se tutti i tuoi servizi condividessero una cache, questo potrebbe essere un vantaggio netto in quanto ci sarebbero più hit nella cache e meno duplicati tra le cache.
Interagire con il servizio esterno è piuttosto complicato e si desidera offrire un'API semplificata ai servizi interni. Qui, il servizio di memorizzazione nella cache sarebbe piuttosto un "adattatore". Tuttavia, non è davvero necessario trasformare l'adattatore in un servizio separato, poiché probabilmente anche una libreria nativa funzionerebbe.
A causa dei requisiti di risorse, la cache deve essere eseguita su hardware diverso rispetto al servizio di prenotazione. Vorresti scalare la cache indipendentemente dagli altri servizi. Per esempio. se il tuo servizio di prenotazione e la cache sono vincolati alla RAM, due server di medie dimensioni potrebbero essere più economici di un server enorme con risorse sufficienti per entrambi.