Best practice per le prestazioni dei microservizi

ID regione

REGION_ID è un codice abbreviato assegnato da Google in base alla regione selezionata quando crei l'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID regione possono sembrare simili ai codici di paesi e province di uso comune. Per le app create dopo febbraio 2020, REGION_ID.r è incluso negli URL di App Engine. Per le app esistenti create prima di questa data, l'ID regione è facoltativo nell'URL.

Scopri di più sugli ID regione.

Lo sviluppo software è incentrato sui compromessi e i microservizi non fanno eccezione. Ciò che ottieni in termini di deployment del codice e indipendenza operativa, paghi dell'overhead delle prestazioni. Questa sezione fornisce alcuni consigli su come minimizzare questo impatto.

Trasforma le operazioni CRUD in microservizi

I microservizi sono particolarmente adatti alle entità a cui si accede con il pattern di creazione, recupero, aggiornamento ed eliminazione (CRUD). Quando lavori con queste entità, in genere ne utilizzi una alla volta, ad esempio un utente, ed esegui una sola delle azioni CRUD alla volta. Pertanto, serve una sola chiamata a microservizi per l'operazione. Cerca con operazioni CRUD più una serie di metodi di business che utilizzato in molte parti della tua applicazione. Queste entità sono ottime candidate per i microservizi.

Fornire API batch

Oltre alle API in stile CRUD, puoi comunque offrire buone prestazioni dei microservizi per gruppi di entità fornendo API batch. Ad esempio, anziché esporre solo un metodo API GET che recupera un singolo utente, fornisci un'API che prende un insieme di ID utente e restituisce un dizionario di utenti corrispondenti:

Richiesta:

/user-service/v1/?userId=ABC123&userId=DEF456&userId=GHI789

Risposta:

{
  "ABC123": {
    "userId": "ABC123",
    "firstName": "Jake",
    … },
  "DEF456": {
    "userId": "DEF456",
    "firstName": "Sue",
    … },
  "GHI789": {
    "userId": "GHI789",
    "firstName": "Ted",
    … }
}

L'SDK App Engine supporta molte API batch, ad esempio la possibilità di recuperare molte entità da Cloud Datastore tramite una singola RPC, pertanto la gestione di questi tipi di API batch può essere molto efficiente.

Utilizza richieste asincrone

Spesso dovrai interagire con molti microservizi per scrivere una risposta. Ad esempio, potresti dover recuperare le preferenze dell'utente che ha eseguito l'accesso e i dettagli dell'azienda. Spesso queste informazioni non dipendono l'uno sull'altro e recuperarli in parallelo. La libreria Urlfetch nell'SDK App Engine supporta le richieste asincrone, consentendoti di chiamare i microservizi in parallelo.

Utilizza il percorso più breve

A seconda di come richiami Urlfetch, puoi utilizzare infrastrutture e percorsi diversi. Per utilizzare il percorso con il rendimento migliore, tieni conto dei seguenti consigli:

Utilizza REGION_ID.r.appspot.com, non un dominio personalizzato
Un dominio personalizzato fa sì che venga utilizzato un percorso diverso per il routing nell'infrastruttura Google. Poiché le chiamate ai microservizi sono interne, puoi da fare e ha prestazioni migliori se utilizzi https://PROJECT_ID.REGION_ID.r.appspot.com.
Imposta follow_redirects su False
Imposta esplicitamente follow_redirects=False quando chiami Urlfetch, in quanto evita un servizio più pesante progettato per seguire i reindirizzamenti. Gli endpoint API non dovrebbero dover reindirizzare i client, perché sono i tuoi microservizi e gli endpoint dovrebbero restituire solo risposte HTTP della serie 200, 400 e 500.
Preferisci i servizi all'interno di un progetto rispetto a più progetti
Ci sono buoni motivi per utilizzare più progetti quando si crea basata su microservizi, ma se l'obiettivo principale sono le prestazioni, possono usare i servizi all'interno di un singolo progetto. I servizi di un progetto sono ospitati lo stesso data center e anche se la velocità effettiva nel data center di Google è eccellente, le chiamate locali sono più veloci.

Evitare le conversazioni durante l'applicazione della sicurezza

L'utilizzo di meccanismi di sicurezza che richiedono molte comunicazioni avanti e indietro per autenticare l'API chiamante è dannoso per il rendimento. Ad esempio, se il tuo microservice deve convalidare un ticket dalla tua applicazione richiamando nuovamente l'applicazione, hai generato una serie di viaggi di andata e ritorno per recuperare i dati.

Un'implementazione OAuth2 può ammortizzare questo costo nel tempo utilizzando l'aggiornamento e memorizza nella cache un token di accesso tra le chiamate a Urlfetch. Tuttavia, se il token di accesso memorizzato nella cache è archiviato in memcache, dovrai sostenere il sovraccarico di memcache per recuperarlo. Per evitare questo sovraccarico, potresti memorizzare nella cache il token di accesso nella memoria di istanza, ma continuerai a sperimentare l'attività OAuth2 di frequente, poiché ogni nuova istanza negozia un token di accesso; ricorda che l'app Le istanze di motore si avviano e si arrestano frequentemente. Alcuni ibridi tra memcache e la cache di un'istanza contribuisce a mitigare il problema, ma la soluzione più complesso.

Un altro approccio che offre buoni risultati è condividere un token segreto tra i microservizi, ad esempio trasmesso come intestazione HTTP personalizzata. In questo approccio, ogni microservizio potrebbe avere un token univoco per ogni chiamante. In genere, i secret condivisi sono una scelta discutibile per la sicurezza ma poiché tutti i microservizi si trovano nella stessa applicazione, non rappresenta più un problema, dato il miglioramento delle prestazioni. Con un secret condiviso, deve solo eseguire un confronto tra stringhe del secret in entrata a un dizionario presumibilmente in memoria e l'applicazione della sicurezza molto leggera.

Se tutti i tuoi microservizi si trovano su App Engine, puoi anche esaminare in arrivo Intestazione X-Appengine-Inbound-Appid. Questa intestazione viene aggiunta dall'infrastruttura Urlfetch quando viene effettuata una richiesta a un altro progetto App Engine e non può essere impostata da terze parti. In base a requisiti di sicurezza, i microservizi potrebbero esaminare l'intestazione in entrata per applicare i criteri di sicurezza.

Trace le richieste dei microservizi

Man mano che crei l'applicazione basata su microservizi, inizi ad accumulare il sovraccarico delle chiamate Urlfetch successive. In questi casi, puoi utilizzare Cloud Trace per capire quali chiamate vengono e dove si trova l'overhead. È importante sottolineare che Cloud Trace consente anche di identificare in cui i microservizi indipendenti vengono richiamati in modo seriale, eseguire il refactoring del codice in modo da eseguire questi recuperi in parallelo.

Una funzionalità utile di Cloud Trace viene attivata quando utilizzi più servizi all'interno di un singolo progetto. Poiché le chiamate vengono effettuate tra i servizi di microservizi Cloud Trace comprime tutte le chiamate in un unico grafico per consentirti di visualizzare l'intera richiesta end-to-end come un'unica traccia.

Screenshot di Google Cloud Trace

Tieni presente che nell'esempio precedente le chiamate a pref-service e user-service vengono eseguite in parallelo utilizzando un Urlfetch asincrono, pertanto le RPC appaiono confuse nella visualizzazione. Tuttavia, questo è comunque uno strumento prezioso per diagnosticare la latenza.

Passaggi successivi