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

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

Os serviços canônicos permitem navegar por muitas configurações diferentes. Para ter a melhor experiência com o Cloud Service Mesh Para painéis de serviço, 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 o namespace do Kubernetes e o nome de um serviço canônico implantado em um cluster ou região forem iguais ao de um serviço canônico implantado em outro cluster ou região, o Cloud Service Mesh vai presumir que se trata do 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.

Embora seja possível definir um serviço canônico para agrupar vários microsserviços conceitualmente diferentes, os painéis de serviço não oferecem o valor completo. Eles mostram uma agregação de componentes diferentes que podem ter desempenho e configuração muito diferentes. 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 em vários 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 operacional ou foco para sua organização.

Por exemplo, uma falha em um serviço de produção crítico pode fazer com que as páginas 3AM bombeiros. Você não quer alertar ninguém se a tag "dev" da implantação do Google Cloud falha 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 de serviço no Cloud Service Mesh durante a vida útil desse serviço.

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