Prácticas recomendadas para los servicios canónicos

Nota: Los servicios canónicos son compatibles de forma automática con la versión 1.6.8 y versiones posteriores de Cloud Service Mesh.

Los servicios canónicos te permiten explorar muchas configuraciones diferentes. Para obtener la mejor experiencia con los paneles de servicio de Cloud Service Mesh, ten en cuenta las siguientes prácticas estándar cuando configures los servicios:

• Reserva un servicio único [espacio de nombres, nombre] en toda la malla.
• Define solo una aplicación de software por servicio canónico.
  • No agrupes los servicios canónicos en los entornos (por ejemplo, prod/stage/dev).
  • Usa los paneles de Cloud Monitoring para obtener vistas de nivel superior de varios servicios.
• Planifica para que los servicios canónicos sean de larga duración en la etapa de producción.

Reserva un servicio único [espacio de nombres, nombre] en toda la malla.

Si un servicio canónico implementado en un clúster o una región tiene el mismo espacio de nombres de Kubernetes y nombre de servicio canónico que uno implementado en otro clúster o región, Cloud Service Mesh supone que es el mismo servicio lógico.

Este comportamiento es coherente con el principio de “similitud” de la flota, que dice que un espacio de nombres debe tener el mismo significado y representar a la misma entidad en toda la flota.

Importante: Asegúrate de que los servicios que sean lógicamente diferentes (por ejemplo, la API de facturación de pagos y la API de transacción de pagos) no usen el mismo par [namespace, name] (p.ej., “payments/api”) porque se unen de forma involuntaria a un Panel de servicio. Ten en cuenta que esta unión conceptual ocurre incluso entre límites regionales. Además, la función de los servicios puede verse afectada.

Una aplicación de software por servicio canónico

Los servicios canónicos están destinados a representar un único servicio o microservicio lógico. Están diseñados para abarcar cargas y objetos binarios homogéneos que representen la misma aplicación de software y función empresarial.

Si bien podrías definir un servicio canónico para agrupar varios microservicios conceptualmente diferentes, los paneles del servicio no proporcionarían su valor completo.Los paneles del servicio mostrarían una agregación de componentes diferentes que pueden tener un rendimiento individual y configurar de manera muy diferente. Sería difícil o incluso imposible comprender el estado, el rendimiento y la configuración de todo el conjunto.

Las siguientes prácticas no son necesariamente negativas, pero el servicio canónico podría ser demasiado grande si se dan las siguientes situaciones:

• Existe tráfico de red entre diferentes cargas de trabajo dentro de un único servicio canónico.
• Un servicio canónico abarca varias cargas de trabajo que se implementan en diferentes programas de actualizaciones.
• Distintos equipos dentro de tu organización son responsables de operar diferentes partes de un mismo servicio canónico.

No agrupar un servicio canónico en los entornos

Muchas organizaciones tecnológicas usan varios entornos de implementación para garantizar la calidad del software y limitar el riesgo. A menudo, estos entornos incluyen desarrollo, prueba, staging, producción o algún subconjunto.

Incluso si implementas el mismo servicio conceptual en cada uno de tus diversos entornos, no es una buena práctica convertirlos en un solo servicio canónico. Estos servicios no son los mismos y no representan el mismo nivel de preocupación o enfoque operativo para tu organización.

Por ejemplo, una falla en un servicio de producción crítico puede causar páginas a las 3 a.m. y incendios. No querrás alertar a nadie si la implementación “dev” falla en medio de la noche. Lo mismo se aplica para comprender el rendimiento, la capacidad y la seguridad de la versión.

Importante: Te recomendamos separar los servicios de tus diversos entornos en servicios canónicos independientes. Para ello, tiene tres alternativas:

Existen tres formas de separar los servicios en diferentes entornos, desde el más sencillo, pero menos riguroso, hasta el que requiere el mayor esfuerzo, pero más potente:

1. Sepáralos con varios nombres de servicio, por ejemplo, payments-prod y payments-test.
2. Sepáralos con varios espacios de nombres, como billing-team y billing-team-test.
3. Sepáralos con varias flotas, uno para cada entorno.

Usa los paneles personalizados de Cloud Monitoring para agregaciones arbitrarias

En lugar de ampliar artificialmente los servicios canónicos en alcances más grandes para datos agregados, usa los paneles de Cloud Monitoring a fin de crear vistas de nivel superior de varios servicios lógicos a la vez.

Los servicios canónicos están diseñados para ser de larga duración

Más allá de los casos de uso de desarrollo, exploración y prueba, los servicios canónicos deben representar servicios lógicos globales y de alto nivel. Estos servicios cambian lentamente y tienden a durar mucho tiempo. Esta longevidad incluye no cambiar los nombres de servicio. Si bien puedes hacerlo, esto afecta las métricas, los SLO y los registros. Sin embargo, puedes ajustar libremente el campo Display name sin interrupciones.

Un nuevo servicio canónico suele representar software nuevo o actualizado, mientras que un servicio canónico que desaparece suele representar un servicio que deja de estar disponible. Tu capacidad para ver el historial de rendimiento de tu servicio, plan y capacidad del proyecto depende de mantener una sola noción de ese servicio en Cloud Service Mesh durante su vida útil.

Ten en cuenta que esto contrasta con los recursos de nivel inferior, como las instancias de VM, los pods y las implementaciones de Kubernetes, y hasta con los clústeres completos, que a menudo surgen o dejan de estar disponibles como parte de la actualización y el mantenimiento de los sistemas de producción.

¿Qué sigue?

• Más información sobre los servicios canónicos.
• Aprende a definir un servicio canónico.