Best practice per le prestazioni dei microservizi

ID regione

REGION_ID è un codice abbreviato assegnato da Google in base alla regione selezionata al momento della creazione dell'app. Il codice non corrispondono a un paese o a una provincia, anche se potrebbero essere visualizzati alcuni ID regione in modo simile ai codici paese e provincia 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 sui passaggi da seguire che puoi adottare per ridurre al minimo 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 si lavora con entità, in genere si usa una sola entità alla volta, ad esempio un utente, e di solito eseguono solo una delle azioni CRUD alla volta. Pertanto, è necessaria una sola chiamata al microservizio 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.

Fornisci API batch

Oltre alle API di tipo CRUD, puoi comunque fornire un buon microservizio le prestazioni di gruppi di entità fornendo API batch. Ad esempio, anziché rispetto alla sola esposizione di un metodo GET API che recupera un singolo utente, 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 di App Engine supporta molte API batch, come la possibilità di recuperare molte da Cloud Datastore tramite una singola RPC, quindi gestire questi tipi di dati Le API possono essere molto efficienti.

Utilizzare le richieste asincrone

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

Il seguente codice di esempio Python utilizza direttamente le RPC per utilizzare le richieste asincrone:

from google.appengine.api import urlfetch

preferences_rpc = urlfetch.create_rpc()
urlfetch.make_fetch_call(preferences_rpc,
                         'https://preferences-service-dot-my-app.uc.r.appspot.com/preferences-service/v1/?userId=ABC123')

company_rpc = urlfetch.create_rpc()
urlfetch.make_fetch_call(company_rpc,
                         'https://company-service-dot-my-app.uc.r.appspot.com/company-service/v3/?companyId=ACME')

 ### microservice requests are now occurring in parallel

try:
  preferences_response = preferences_rpc.get_result()  # blocks until response
  if preferences_response.status_code == 200:
    # deserialize JSON, or whatever is appropriate
  else:
    # handle error
except urlfetch.DownloadError:
  # timeout, or other transient error

try:
  company_response = company_rpc.get_result()  # blocks until response
  if company_response.status_code == 200:
    # deserialize JSON, or whatever is appropriate
  else:
    # handle error
except urlfetch.DownloadError:
  # timeout, or other transient error

Lavorare in parallelo spesso è in contrasto con una buona struttura del codice perché, in uno scenario reale, spesso utilizzi una classe per incapsulare i metodi delle preferenze e un'altra classe per incapsulare i metodi dell'azienda. È difficile sfruttare le chiamate Urlfetch asincrone senza rompere questa incapsulamento. Un buon nel pacchetto NDB dell'SDK per Python di App Engine: Tasklet. I tasklet ti consentono di mantenere una buona incapsulazione nel codice, offrendo al contempo un meccanismo per eseguire chiamate di microservizi in parallelo. Tieni presente che i tasklet utilizzano future anziché RPC, ma l'idea è simile.

Usa il percorso più breve

A seconda di come richiami Urlfetch, puoi causare una diversa infrastruttura e le route da utilizzare. Per utilizzare il percorso con il rendimento migliore, considera la possibilità seguenti consigli:

Utilizza le funzionalità di REGION_ID.r.appspot.com, non un dominio personalizzato
Un dominio personalizzato determina l'utilizzo di una route diversa durante l'instradamento tramite dell'infrastruttura di Google. Poiché le chiamate ai microservizi sono interne, è facile da eseguire e ha un rendimento migliore se utilizzi https://PROJECT_ID.REGION_ID.r.appspot.com.
Imposta follow_redirects su False
Imposta in modo esplicito follow_redirects=False durante la chiamata a Urlfetch, per evitare un servizio di maggior peso progettato per seguire i reindirizzamenti. Gli endpoint API non devono necessariamente reindirizzare i client, perché sono i tuoi microservizi e gli endpoint devono 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 nello stesso data center e, anche se il throughput sulla rete inter-data center di Google è eccellente, le chiamate locali sono più veloci.

Evitare le conversazioni durante l'applicazione della sicurezza

È negativo per le prestazioni utilizzare meccanismi di sicurezza che coinvolgono e la comunicazione per autenticare l'API chiamante. Ad esempio, se deve convalidare un ticket dalla tua applicazione richiamando l'applicazione, hai dovuto fare diversi viaggi di andata e ritorno per ottenere 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 overhead, puoi memorizzare nella cache il token di accesso nella memoria dell'istanza, ma l'attività OAuth2 verrà comunque eseguita frequentemente, poiché ogni nuova istanza negozia un token di accesso. Ricorda che le istanze App Engine vengono avviate e interrotte di frequente. Un ibrido di memcache e cache delle istanze contribuirà ad attenuare il problema, ma la soluzione inizierà a diventare più complessa.

Un altro approccio che funziona bene consiste nel condividere un token segreto tra di microservizi trasmessi come un'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 le implementazioni di sicurezza, ma poiché tutti i microservizi si trovano nella stessa applicazione, il problema diventa meno grave, dati i vantaggi in termini di prestazioni. Con un secret condiviso, il microservizio deve solo eseguire un confronto di stringhe del secret in entrata con un dizionario presumibilmente in memoria e l'applicazione della sicurezza è molto leggera.

Se tutti i tuoi microservizi sono su App Engine, puoi anche ispezionare l'intestazione X-Appengine-Inbound-Appid in entrata. 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 la tua applicazione basata su microservizi, inizi ad accumulare overhead derivante da chiamate Urlfetch successive. In questi casi, puoi utilizzare Cloud Trace per capire quali chiamate vengono fatte e dove si trova il sovraccarico. È importante sottolineare che Cloud Trace può anche aiutarti a identificare dove vengono invocati in sequenza microservizi indipendenti, in modo da poter eseguire il refactoring del codice per eseguire questi recuperi in parallelo.

Una funzionalità utile di Cloud Trace viene attivata quando utilizzi più servizi all'interno di un singolo progetto. Quando le chiamate vengono effettuate tra i servizi di microservizi nel tuo progetto, Cloud Trace le raggruppa in un unico grafico delle chiamate per consentirti di visualizzare l'intera richiesta end-to-end come una singola 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