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 il giorno
Febbraio 2020, REGION_ID.r
è incluso in
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 tramite il pattern di creazione, recupero, aggiornamento ed eliminazione (CRUD). Quando si lavora con entità, in genere si utilizza una sola entità alla volta, ad esempio un utente, e si di solito eseguono solo una 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 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 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.
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
Svolgere il lavoro in parallelo spesso è in contrasto con una buona struttura del codice perché, in un
scenario reale, spesso si usa una classe per incapsulare i metodi delle preferenze
e un'altra classe per illustrare i metodi aziendali. È 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 consentono di mantenere una buona incapsulamento nel codice continuando a offrire
un meccanismo per ottenere chiamate parallele ai microservizi. 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 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
suFalse
- Imposta in modo esplicito
follow_redirects=False
durante la chiamata aUrlfetch
, per evitare un servizio di maggior peso progettato per seguire i reindirizzamenti. Gli endpoint API devono non è necessario reindirizzare i client, perché sono i tuoi microservizi, e devono restituire solo risposte HTTP 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 sul è 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 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 è memorizzato in memcache, dovrai utilizzare 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 del 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 funziona bene consiste nel condividere un token segreto tra di microservizi trasmessi come un'intestazione HTTP personalizzata. In questo , ciascun 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 sono su App Engine, puoi anche ispezionare l'intestazione X-Appengine-Inbound-Appid
in entrata.
Questa intestazione viene aggiunta dall'infrastruttura Urlfetch
quando effettui una richiesta a
in un altro progetto App Engine e non può essere impostato da un soggetto esterno. 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
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.
Tieni presente che nell'esempio precedente, le chiamate al pref-service
e al
Le user-service
vengono eseguite in parallelo utilizzando un Urlfetch
asincrono,
in modo che le RPC siano criptate nella visualizzazione.
Tuttavia, questo è comunque uno strumento prezioso per diagnosticare la latenza.
Passaggi successivi
- Consulta una panoramica dell'architettura dei microservizi su App Engine.
- Scopri come creare e denominare ambienti di sviluppo, test, QA, gestione temporanea e produzione con microservizi in App Engine.
- Scopri le best practice per la progettazione di API in modo da comunicare tra microservizi.
- Scopri come eseguire la migrazione di un'applicazione monolitica esistente a un'applicazione con microservizi.