PHP 5 ha llegado al final del ciclo de asistencia y quedará obsoleto el 31 de enero del 2026. Después de la retirada, no podrás desplegar aplicaciones PHP 5, aunque tu organización haya usado anteriormente una política de organización para volver a habilitar los despliegues de los tiempos de ejecución antiguos. Tus aplicaciones PHP 5 seguirán funcionando y recibiendo tráfico después de la fecha de retirada. Te recomendamos que migres a la versión compatible más reciente de PHP.

Esta página se ha traducido con Cloud Translation API.

Prácticas recomendadas para mejorar el rendimiento de los microservicios

ID de región

El REGION_ID es un código abreviado que Google asigna en función de la región que selecciones al crear tu aplicación. El código no corresponde a un país o provincia, aunque algunos IDs de región pueden parecerse a los códigos de país y provincia que se usan habitualmente. En las aplicaciones creadas después de febrero del 2020, REGION_ID.r se incluye en las URLs de App Engine. En las aplicaciones creadas antes de esa fecha, el ID de región es opcional en la URL.

Más información sobre los IDs de región

El desarrollo de software se basa en las concesiones y los microservicios no son una excepción. Lo que ganas en independencia de implementación y funcionamiento del código, lo pagas en sobrecarga de rendimiento. En esta sección se ofrecen algunas recomendaciones sobre los pasos que puedes seguir para minimizar este impacto.

Convertir operaciones CRUD en microservicios

Los microservicios son especialmente adecuados para las entidades a las que se accede con el patrón de creación, recuperación, actualización y eliminación (CRUD). Cuando trabajas con estas entidades, normalmente solo usas una a la vez, como un usuario, y solo realizas una de las acciones CRUD a la vez. Por lo tanto, solo necesitas una llamada de microservicio para la operación. Busca entidades que tengan operaciones CRUD y un conjunto de métodos empresariales que se puedan utilizar en muchas partes de tu aplicación. Estas entidades son buenas candidatas para convertirse en microservicios.

Proporcionar APIs combinadas

Además de las APIs de tipo CRUD, puedes seguir ofreciendo un buen rendimiento de microservicios para grupos de entidades proporcionando APIs por lotes. Por ejemplo, en lugar de exponer solo un método de API GET que recupere un único usuario, proporciona una API que tome un conjunto de IDs de usuario y devuelva un diccionario de los usuarios correspondientes:

Solicitud:

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

Respuesta:

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

El SDK de App Engine admite muchas APIs por lotes, como la capacidad de obtener muchas entidades de Cloud Datastore a través de una sola llamada a procedimiento remoto, por lo que el servicio de estos tipos de APIs por lotes puede ser muy eficiente.

Usar solicitudes asíncronas

A menudo, tendrás que interactuar con muchos microservicios para crear una respuesta. Por ejemplo, puede que tengas que obtener las preferencias del usuario que ha iniciado sesión, así como los detalles de su empresa. A menudo, estos fragmentos de información no dependen los unos de los otros, por lo que puedes obtenerlos en paralelo. La biblioteca Urlfetch del SDK de App Engine admite solicitudes asíncronas, lo que le permite llamar a microservicios en paralelo.

Usar la ruta más corta

En función de cómo invoques Urlfetch, se usarán diferentes infraestructuras y rutas. Para usar la ruta con el mejor rendimiento, ten en cuenta las siguientes recomendaciones:

Usa REGION_ID.r.appspot.com, no un dominio personalizado: Un dominio personalizado hace que se use una ruta diferente al enrutar a través de la infraestructura de Google. Como las llamadas a microservicios son internas, es fácil hacerlo y el rendimiento es mejor si usas https://PROJECT_ID.REGION_ID.r.appspot.com.

Asigna el valor False a follow_redirects.: Define follow_redirects=False de forma explícita al llamar a Urlfetch, ya que así se evita un servicio más pesado diseñado para seguir redirecciones. Tus endpoints de API no deberían tener que redirigir a los clientes, ya que son tus propios microservicios, y los endpoints solo deberían devolver respuestas de las series HTTP 200, 400 y 500.
Preferir los servicios de un proyecto a los de varios proyectos: Hay buenos motivos para usar varios proyectos al crear una aplicación basada en microservicios, pero si el rendimiento es tu objetivo principal, usa servicios en un solo proyecto. Los servicios de un proyecto se alojan en el mismo centro de datos y, aunque el rendimiento de la red entre centros de datos de Google es excelente, las llamadas locales son más rápidas.

Evitar las conversaciones durante la aplicación de medidas de seguridad

No es recomendable usar mecanismos de seguridad que impliquen muchas comunicaciones de ida y vuelta para autenticar la API que llama, ya que esto afecta al rendimiento. Por ejemplo, si tu microservicio necesita validar un ticket de tu aplicación llamando a la aplicación, has incurrido en varias idas y vueltas para obtener tus datos.

Una implementación de OAuth 2.0 puede amortizar este coste a lo largo del tiempo mediante tokens de actualización y almacenando en caché un token de acceso entre invocaciones de Urlfetch. Sin embargo, si el token de acceso almacenado en caché se almacena en memcache, tendrás que incurrir en la sobrecarga de memcache para obtenerlo. Para evitar esta sobrecarga, puedes almacenar en caché el token de acceso en la memoria de la instancia, pero seguirás experimentando la actividad de OAuth2 con frecuencia, ya que cada instancia nueva negocia un token de acceso. Recuerda que las instancias de App Engine se activan y desactivan con frecuencia. Una combinación híbrida de memcache y caché de instancias ayudará a mitigar este problema, pero tu solución empezará a ser más compleja.

Otra estrategia que funciona bien es compartir un token secreto entre microservicios, por ejemplo, transmitiéndolo como un encabezado HTTP personalizado. En este enfoque, cada microservicio podría tener un token único para cada llamador. Normalmente, los secretos compartidos son una opción cuestionable para las implementaciones de seguridad, pero, como todos los microservicios están en la misma aplicación, se convierte en un problema menor, teniendo en cuenta las mejoras de rendimiento. Con un secreto compartido, el microservicio solo tiene que comparar la cadena del secreto entrante con un diccionario que se supone que está en la memoria, y la seguridad es muy ligera.

Si todos tus microservicios están en App Engine, también puedes inspeccionar el encabezado X-Appengine-Inbound-Appid de entrada. La infraestructura de Urlfetch añade este encabezado al hacer una solicitud a otro proyecto de App Engine y no puede configurarlo un tercero. En función de tus requisitos de seguridad, tus microservicios podrían inspeccionar este encabezado entrante para aplicar tu política de seguridad.

Trazar solicitudes de microservicios

A medida que desarrollas tu aplicación basada en microservicios, empiezas a acumular sobrecarga de llamadas Urlfetch sucesivas. Cuando esto ocurre, puedes usar Cloud Trace para saber qué llamadas se están haciendo y dónde se produce la sobrecarga. Es importante destacar que Cloud Trace también puede ayudarte a identificar dónde se invocan de forma serial microservicios independientes para que puedas refactorizar tu código y realizar estas recuperaciones en paralelo.

Una función útil de Cloud Trace se activa cuando usas varios servicios en un mismo proyecto. A medida que se realizan llamadas entre los servicios de microservicios de tu proyecto, Cloud Trace combina todas las llamadas en un único gráfico de llamadas para que puedas visualizar toda la solicitud de extremo a extremo como una sola traza.

Captura de pantalla de Google Cloud Trace

Ten en cuenta que, en el ejemplo anterior, las llamadas a pref-service y user-service se realizan en paralelo mediante un Urlfetch asíncrono, por lo que las RPCs aparecen desordenadas en la visualización. Sin embargo, sigue siendo una herramienta valiosa para diagnosticar la latencia.

Al diseñar las respuestas de la API, es útil incluir el ID de solicitud único en la respuesta predefinida que envías al llamante. Este enfoque puede vincular las solicitudes de los clientes con las respuestas de los microservicios y ayudar a depurar y diagnosticar. Otros elementos útiles son el nombre de host, la ruta, el ID de instancia y la versión que ha publicado la respuesta. Toda esta información se puede encontrar en el entorno de la solicitud, por lo que no supone un coste elevado incluirla en la respuesta.

Por ejemplo (en pseudocódigo):

response = {
  'status': 200,
  'apiVersion': '1.2',  # helpful to show the formal minor version to the client
  'hostname': os.environ.get('HTTP_HOST'),
  'path': os.environ.get('PATH_INFO'),
  'instanceId': os.environ.get('INSTANCE_ID'),
  'codeVersion': os.environ.get('CURRENT_VERSION_ID'),
  'requestId': os.environ.get('REQUEST_LOG_ID'),
  'data': {
    # your actual API response goes here
  }
}

Siguientes pasos

Consulta una descripción general de la arquitectura de microservicios en App Engine.
Consulta cómo crear y asignar nombres a entornos de desarrollo, prueba, control de calidad, preproducción y producción con microservicios en App Engine.
Consulta las prácticas recomendadas para diseñar APIs que permitan la comunicación entre microservicios.
Consulta cómo migrar una aplicación monolítica a una con microservicios.

Prácticas recomendadas para mejorar el rendimiento de los microservicios Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.