Max. chiamate downstream raccomandate per l'interconnessione di micro servizi

Ciò che è sensato può variare.

• Se il tuo servizio è nascosto dietro un'interfaccia utente reattiva, potrebbe andar bene aspettare.
• Se d'altra parte impedisce agli utenti di svolgere un'altra attività, è un problema.

Le aspettative

Scopri quanto deve essere reattivo il tuo sito / servizio. Pin giù in modo misurabile.

80% are within Xms, 95% are within Yms, ... 100% are within Zms

Potrebbe avere senso interrompere l'aspettativa in base al carico del sistema corrente o all'ora del giorno.

• Come dovrebbe comportarsi il tuo sistema con x mila utenti, e se ci fossero migliaia?
• Come dovrebbe comportarsi il tuo sistema tra le 8:00 e le 20:00?

Potresti voler diventare più specifico:

• Numero massimo di utenti simultanei e qualsiasi altra cosa viene considerata un servizio eccezionale.
• Degrado del servizio: per mantenere la reattività sacrificare la qualità della risposta. vale a dire. non restituire statistiche con il nome utente e il badge.
• Processi della linea rossa: per mantenere la funzionalità a scapito di altre funzionalità. vale a dire. prioritizza l'elaborazione degli ordini rispetto alla visualizzazione di commenti e recensioni.

Raccolta dati

Esegui diversi client (selenio o script di richieste Web personalizzate) che eseguono il ping di una pagina o un gruppo di pagine con qualche schema di distribuzione. Cerca di renderlo simile a un peek load oa giorni generali. Misura i tempi di risposta al cliente.

Se 80% are within Xms, 95% are within Yms, ... 100% are within Zms allora sei bravo. Altrimenti scopri cosa sta rallentando quel gruppo di richieste.

Annota anche il degrado del servizio e il rivestimento rosso. I tempi di risposta stretti non sono utili se la qualità del servizio si riduce eccessivamente o le linee rosse sono troppo dominanti rispetto ad altre funzionalità.

Experiment

Ora che sai in modo specifico quali tipi di richiesta sono troppo lenti, troppo poveri o che richiedono più risorse e in quali casi, trova i modi per migliorarlo.

Forse:

• Hardware come cache, proxy, load balancer.
• Modifiche del front-end per evitare o ritardare il caricamento di tali dati, magari suddividendo le pagine.
• Modifiche del back-end combinando, ottimizzando o suddividendo i servizi.

Raccogli più dati, hai fatto le cose meglio o peggio?

Convalida

Assicurati sempre che il tuo esperimento sia valido durante la produzione.

Per fare questo è necessario avere un buon monitoraggio in produzione. Confronta ciò che hai visto prima con ciò che vedi ora. La qualità è apparentemente migliorata?

Ingegneria del caos

Solo una volta che hai maturato il sistema, e credi che andrà bene. Prova a progettare un modello di carico e osserva se le metriche soddisfano le tue aspettative.

Utilizza gli script client progettati contro il sistema di test. Ovviamente essere pignoli su quali test devono essere utilizzati, non c'è bisogno di corrompere il sistema qui.

Informare anche tutti sull'esperimento in anticipo. Non sorprendere le tue squadre. Se sono a disagio con la bilancia o il bersaglio, ascoltali. Riduci lo scopo e stringi il test, aumentando la fiducia lentamente.