Práticas recomendadas para o serviço canónico

Nota: os serviços canónicos são suportados automaticamente na versão 1.6.8 e superiores do Cloud Service Mesh.

Os serviços canónicos permitem-lhe navegar em muitas configurações diferentes. Para ter a melhor experiência com os painéis de controlo do Cloud Service Mesh, considere as seguintes práticas padrão ao configurar os seus serviços:

  • Reserve um serviço exclusivo [namespace, nome] em toda a malha.
  • Defina uma aplicação de software por serviço canónico.
    • Não agrupe serviços canónicos em vários ambientes (por exemplo, produção/preparação/desenvolvimento).
    • Use os painéis de controlo do Cloud Monitoring para ter vistas de nível superior de vários serviços.
  • Planeie que os serviços canónicos sejam de longa duração em produção.

Reservar um serviço exclusivo [namespace, name] em toda a malha

Se um serviço canónico implementado num cluster ou numa região tiver o mesmo espaço de nomes do Kubernetes e nome do serviço canónico que um serviço implementado noutro cluster ou região, o Cloud Service Mesh assume que se trata do mesmo serviço lógico.

Este comportamento é consistente com o princípio da frota de "igualdade", que afirma que um espaço de nomes deve ter o mesmo significado e representar a mesma entidade em toda a frota.

Uma aplicação de software por serviço canónico

Os serviços canónicos destinam-se a representar um único serviço lógico ou microsserviço. Destinam-se a abranger binários ou cargas de trabalho homogéneos que representam a mesma aplicação de software e função empresarial.

Embora possa definir um serviço canónico para agrupar vários microsserviços conceptualmente diferentes, os painéis de controlo de serviços não oferecem o seu valor total.Os painéis de controlo de serviços apresentam uma agregação de componentes diferentes que podem ter um desempenho e uma configuração muito diferentes individualmente. Seria difícil ou mesmo impossível compreender o estado, o desempenho e a configuração do todo.

As seguintes situações não são necessariamente práticas incorretas, mas o seu serviço canónico pode ser demasiado grande se:

  • Existe tráfego de rede entre diferentes cargas de trabalho num único serviço canónico.
  • Um serviço canónico compreende várias cargas de trabalho implementadas em horários de lançamento diferentes.
  • Diferentes equipas na sua organização são responsáveis por operar diferentes partes de um único serviço canónico.

Não agrupe um serviço canónico em vários ambientes

Muitas organizações tecnológicas usam vários ambientes de implementação para garantir a qualidade do software e limitar o risco. Estes ambientes incluem, na maioria das vezes, dev, test, staging, prod ou algum subconjunto.

Mesmo que implemente o mesmo serviço conceptual em cada um dos seus vários ambientes, é uma má prática torná-los um único serviço canónico. Estes serviços não são iguais e não representam o mesmo nível de preocupação ou foco operacional para a sua organização.

Por exemplo, uma falha num serviço de produção crítico pode causar páginas de erro às 3 da manhã e ações de resposta a incidentes. Não quer alertar ninguém se a implementação "dev" falhar a meio da noite. O mesmo se aplica à compreensão do desempenho, da capacidade e da segurança do lançamento.

Desde a mais fácil, mas menos rigorosa, até à mais trabalhosa, mas mais eficaz, existem três formas de separar os serviços em diferentes ambientes:

  1. Separe-os com vários nomes de serviços, por exemplo, payments-prod e payments-test.
  2. Separe-os com vários espaços de nomes, por exemplo, billing-team e billing-team-test.
  3. Separe-os usando várias frotas, uma para cada ambiente.

Prefira os painéis de controlo personalizados do Cloud Monitoring para agregações arbitrárias

Em vez de aumentar artificialmente os serviços canónicos em âmbitos maiores para dados agregados, use os painéis de controlo do Cloud Monitoring para criar vistas de nível superior de vários serviços lógicos em simultâneo.

Os serviços canónicos destinam-se a ser duradouros

Fora dos exemplos de utilização de desenvolvimento, exploração e testes, os serviços canónicos devem representar serviços lógicos globais de nível superior. Estes serviços mudam lentamente e tendem a durar muito tempo. Esta longevidade inclui não alterar os nomes dos serviços. Embora possa alterar os respetivos nomes, fazê-lo afeta as métricas, os SLOs e os registos. No entanto, pode ajustar livremente o campo Display name sem interrupções.

Um novo serviço canónico representa frequentemente software novo ou atualizado, enquanto um serviço canónico descontinuado representa frequentemente uma descontinuação de serviço. A sua capacidade de ver o histórico de desempenho do seu serviço, plano e capacidade do projeto depende da manutenção de uma única noção desse serviço na Cloud Service Mesh durante a sua duração.

Tenha em atenção que isto contrasta com os recursos de nível inferior, como instâncias de VMs, implementações/pods do Kubernetes e até clusters completos, que muitas vezes aparecem e desaparecem como parte da atualização e manutenção dos sistemas de produção.

O que se segue?