Microservizi, browser e richieste HTTP

Una cosa non è cambiata: la velocità della luce. Per esempio. quando invio una richiesta HTTP dall'Europa a un server di New York, avrò una latenza di andata e ritorno di almeno 60 ms. L'apertura di una connessione TCP e la negoziazione della crittografia TLS richiedono roundtrip aggiuntivi, pertanto stiamo esaminando una latenza di ~ 200 ms per la prima richiesta a un server. E questo esclude la ricerca DNS, la latenza aggiuntiva dall'hardware di rete, il tempo di elaborazione sul server e anche il tempo per il trasferimento effettivo dei dati. Bandwith conta solo per l'ultima parte.

Per questo motivo, provare a fare il minor numero possibile di richieste al minor numero possibile di domini è ancora un buon consiglio se si desidera tempi di caricamento rapidi per il proprio sito Web (questo è anche uno dei motivi per cui le reti pubblicitarie rallentano una pagina). HTTP / 1.1 migliora questo dato che più richieste possono essere inviate a un server web senza dover attendere il completamento delle richieste precedenti (sebbene la maggior parte dei browser disattivhi il pipelining HTTP). HTTP / 2 consente anche a un server di inviare una risposta prima di ricevere una richiesta, evitando così una latenza aggiuntiva per la richiesta. Tuttavia, tutto ciò aiuta solo quando ci si connette a un server singolo che è anche sufficientemente intelligente per eseguire queste ottimizzazioni, non necessariamente nel caso di un'API REST.

Quando vengono utilizzati un paio di microservizi internamente , la latenza non è un fattore importante: probabilmente eseguirai tutti i tuoi servizi in un singolo data center, non in continenti diversi. Ma quando esponi una API REST, probabilmente è meglio avere solo una singola API. In questo modo, non importa se è implementato internamente con i microservizi.

Quando si progetta la tua API pubblica, puoi strutturarla in modo da ridurre la necessità di richieste aggiuntive. Per esempio. per un sito di domande e risposte, è possibile che si desideri recuperare un elenco di domande recenti. Questo potrebbe essere fatto in modo "pulito" restituendo un elenco di ID di domanda:

GET /recent-questions HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-type: application/json

["1234", "1235", "1236", "1237"]

Ma come sarà usato? Se voglio rendere una lista di domande, ho bisogno del titolo, punteggio, data, nomi utente, ecc. Dovrei fare una richiesta in più per ognuno di questi. Ma se invece anticipiamo questi requisiti e li includiamo nella risposta, è possibile evitare tempi di caricamento extra:

GET /recent-questions?format=short HTTP/1.1

HTTP/1.1 200 OK
Content-type: application/json

[{"id": "1234", "score": 2, "title": "How can I frob a bar?", ...}
,...
]

Molti framework per il rendering lato client (ad es. React) vedono questo problema e consentono il rendering della prima risposta sul server. Il client riceve quindi immediatamente il documento HTML completo senza dover effettuare richieste aggiuntive. Allo stesso modo, dovresti provare ad implementare il "rendering lato server" per le tue API REST.

Nell'implementazione di Micro-servizi di solito è l'idea di avere piccoli, singoli compiti, poiché questo ha molti vantaggi per semplicità e manutenibilità, ecc. in questi giorni molte persone hanno abbastanza larghezza di banda che il maggior numero di richieste & le risposte hanno un impatto minimo sulla reattività dei siti.

Tuttavia, a volte si riscontra un impatto negativo, ad esempio quando un numero elevato di client per i servizi forniti si trova in aree con larghezza di banda ridotta. In questi casi potrebbe valere la pena prendere in considerazione l'implementazione di un dispatch & servizio di aggregazione che riceve la richiesta iniziale, la invia ai vari microservizi, raggruppa le risposte e invia la risposta collazionata, possibilmente con un meccanismo in cui, se alcuni servizi richiedono molto tempo, possono essere inviate risposte parziali e quindi followup postati .