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 serviço do Cloud Service Mesh É importante considerar as seguintes práticas padrão ao configurar seus painéis. serviços:

• Reserve um serviço exclusivo [namespace, nome] em toda a malha.
• Defina um aplicativo de software para cada serviço canônico.
  • Evite agrupar os serviços canônicos em vários 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.

Importante: certifique-se de que serviços logicamente diferentes (por exemplo, API de contabilidade de pagamento e API de transação de pagamento) não usem o mesmo par [namespace, nome] (por exemplo, "payments/api"), porque eles acidentalmente se unem um Painel de serviços. Observe que essa união conceitual ocorre mesmo em limites regionais. Além disso, a função dos serviços pode ser afetada.

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 conceituais diferentes, mas os painéis de serviço não fornecem o valor total. Eles mostram um conjunto de componentes diferentes que podem estar sendo configurados e executados individualmente e de forma 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.

Evite agrupar 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 gerar páginas às 3 da manhã e acionar bombeiros. Não é conveniente alertar alguém porque a implantação "desenvolvimento" falhou no meio da noite. O mesmo se aplica ao desempenho, a capacidade e a segurança da versão.

Importante: recomendamos separar os serviços de seus vários ambientes em serviços canônicos separados. Existem três maneiras de fazer isso.

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

• Saiba mais sobre os serviços canônicos.
• Saiba como definir um serviço canônico.