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

Observação: os serviços canônicos são compatíveis automaticamente na versão 1.6.8 e mais recentes do Cloud Service Mesh.

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

  • Reserve um serviço exclusivo [namespace, nome] em toda a malha.
  • Defina um aplicativo de software para cada serviço canônico.
    • Não agrupe serviços canônicos entre ambientes (por exemplo, prod/stage/dev).
    • Use os painéis do Cloud Monitoring para ter uma visualização melhor de vários serviços.
  • Planeje os serviços canônicos para serem de longa duração na produção.

Reserve um serviço exclusivo [namespace, nome] em toda a malha

Se um serviço canônico implantado em um cluster ou região tiver o mesmo namespace do Kubernetes e nome de serviço canônico que um implantado em outro cluster ou região, o Cloud Service Mesh presumirá que é o mesmo serviço lógico.

Esse comportamento é consistente com o princípio de "semelhança" da frota, que diz que um namespace precisa ter o mesmo significado e representar a mesma entidade em toda a frota.

Um aplicativo de software por serviço canônico

Os Serviços canônicos são usados para representar um único serviço lógico ou microsserviço. Eles foram criados para abranger binários/cargas de trabalho homogêneos que representam o mesmo aplicativo de software e a mesma função de negócios.

É possível definir um serviço canônico para agrupar vários microsserviços conceitualmente diferentes, mas os painéis de serviço não forneceriam o valor total.Eles exibiriam uma agregação de componentes diferentes que, individualmente, têm desempenho e podem ser configurados de maneira muito diferente. Seria difícil ou até mesmo impossível entender a integridade, o desempenho e a configuração de todo o processo.

As opções a seguir não são necessariamente práticas ruins, mas seu serviço canônico pode ser muito grande se:

  • existir tráfego de rede entre diferentes cargas de trabalho em um único serviço canônico;
  • um serviço canônico incluir várias cargas de trabalho implantadas em diferentes programações de lançamento;
  • equipes diferentes dentro da organização forem responsáveis por operar diferentes partes de um único serviço canônico.

Não agrupe um serviço canônico entre ambientes

Muitas organizações de tecnologia empregam vários ambientes de implantação para garantir a qualidade do software e limitar o risco. Esses ambientes costumam incluir desenvolvimento, teste, preparo, produção ou algum subconjunto.

Mesmo que você implante o mesmo serviço conceitual em cada um dos vários ambientes, não é recomendado torná-los um único serviço canônico. Esses serviços não são iguais e não representam o mesmo nível de preocupação ou foco operacional para sua organização.

Por exemplo, uma falha em um serviço de produção crítico pode causar páginas da 3h e bombeiros. Você não quer alertar ninguém se a implantação "dev" falhar no meio da noite. O mesmo se aplica ao desempenho, a capacidade e a segurança da versão.

Há três maneiras de separar serviços em ambientes diferentes, do mais fácil e menos rigoroso ao que exige mais esforço, mas é mais potente:

  1. Usar vários nomes de serviços, como payments-prod e payments-test.
  2. Usar vários namespaces, como billing-team e billing-team-test
  3. Usar várias frotas, uma para cada ambiente.

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

Em vez de sobrecarregar os serviços canônicos em escopos maiores para agregar dados, use os painéis do Cloud Monitoring e crie visualizações de nível superior de vários serviços lógicos de uma só vez.

Os serviços canônicos devem ser de longa duração

Fora dos casos de uso de desenvolvimento, exploração e teste, os serviços canônicos precisam representar serviços lógicos globais e de alto nível. Esses serviços são lentos e tendem a ter longa duração. Essa longevidade inclui não alterar nomes de serviço. Embora seja possível alterar os nomes, isso afeta as métricas, os SLOs e os registros. Mas é possível ajustar livremente o campo Display namesem interrupções.

Geralmente, um novo serviço canônico representa um software novo ou atualizado, e o serviço canônico que desaparece geralmente representa uma suspensão de uso do serviço. A capacidade de ver o desempenho histórico do serviço, plano e capacidade do projeto depende de manter uma única noção desse serviço no Cloud Service Mesh durante toda a vida útil.

Isso se compara a recursos de nível inferior, como instâncias de VM, pods/implantações do Kubernetes e até clusters inteiros, que geralmente vêm como parte da atualização e da manutenção de sistemas de produção.

A seguir