Prácticas recomendadas de los servicios canónicos

Nota: Los servicios canónicos se admiten automáticamente en Cloud Service Mesh versión 1.6.8 y posteriores.

Los servicios canónicos te permiten desplazarte por muchas configuraciones diferentes. Para disfrutar de la mejor experiencia con los paneles de servicios de Cloud Service Mesh, ten en cuenta las siguientes prácticas estándar al configurar tus servicios:

  • Reserva un servicio único [espacio de nombres, nombre] en toda la malla.
  • Define una aplicación de software por cada servicio canónico.
    • No agrupes los servicios canónicos en diferentes entornos (por ejemplo, producción, fase de pruebas o desarrollo).
    • Usa los paneles de control de Cloud Monitoring para obtener vistas de nivel superior de varios servicios.
  • Planifica que los servicios canónicos tengan una larga duración en producción.

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

Si un servicio canónico desplegado en un clúster o una región tiene el mismo espacio de nombres de Kubernetes y el mismo nombre de servicio canónico que otro desplegado en otro clúster u otra región, Cloud Service Mesh asume que se trata del mismo servicio lógico.

Este comportamiento se ajusta al principio de "igualdad" de la flota, que establece que un espacio de nombres debe tener el mismo significado y representar la misma entidad en toda la flota.

Una aplicación de software por servicio canónico

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

Aunque puedes definir un servicio canónico para agrupar varios microservicios conceptualmente diferentes, los paneles de control de servicios no te ofrecerían todo su valor.Los paneles de control de servicios mostrarían una agregación de componentes diferentes que pueden tener un rendimiento y una configuración muy distintos. Sería difícil o incluso imposible entender el estado, el rendimiento y la configuración del conjunto.

Las siguientes no son necesariamente malas prácticas, pero tu servicio canónico puede ser demasiado grande si:

  • Hay tráfico de red entre diferentes cargas de trabajo de un mismo servicio canónico.
  • Un servicio canónico incluye varias cargas de trabajo que se implementan en diferentes programaciones de lanzamiento.
  • Diferentes equipos de tu organización son responsables de operar diferentes partes de un mismo servicio canónico.

No agrupes un servicio canónico en varios entornos

Muchas empresas tecnológicas utilizan varios entornos de implementación para asegurar la calidad del software y limitar los riesgos. Estos entornos suelen incluir desarrollo, pruebas, preproducción, producción o algún subconjunto.

Aunque implementes el mismo servicio conceptual en cada uno de tus entornos, no es recomendable que los conviertas en un único servicio canónico. Estos servicios no son iguales y no representan el mismo nivel de preocupación u objetivo operativo para tu organización.

Por ejemplo, un fallo en un servicio de producción crítico puede provocar que se produzcan páginas a las 3 de la mañana y que se tengan que tomar medidas urgentes. No quieres alertar a nadie si la implementación de "dev" falla en mitad de la noche. Lo mismo ocurre con el rendimiento, la capacidad y la seguridad de las versiones.

Hay tres formas de separar los servicios en diferentes entornos, desde la más sencilla, pero menos rigurosa, hasta la que requiere más esfuerzo, pero es más potente:

  1. Separa los nombres de los servicios con varios, por ejemplo, payments-prod y payments-test.
  2. Sepáralos con varios espacios de nombres, como billing-team y billing-team-test.
  3. Separa los entornos usando varias flotas, una por cada entorno.

Preferir los paneles de control personalizados de Cloud Monitoring para agregaciones arbitrarias

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

Los servicios canónicos deben tener una larga duración

Aparte de los casos prácticos de desarrollo, exploración y pruebas, los servicios canónicos deben representar servicios lógicos globales de alto nivel. Estos servicios cambian lentamente y suelen tener una larga duración. Esta durabilidad incluye no cambiar los nombres de los servicios. Aunque puedes cambiar sus nombres, esto afecta a las métricas, los SLOs y los registros. Sin embargo, puedes ajustar libremente el campo Display name sin que se produzcan interrupciones.

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

Ten en cuenta que esto contrasta con los recursos de nivel inferior, como las instancias de VM, los pods o las implementaciones de Kubernetes e incluso los clústeres completos, que suelen aparecer y desaparecer como parte de la actualización y el mantenimiento de los sistemas de producción.

Siguientes pasos