🏰 🍢 🦗 Casos de uso de malha de serviço 🔇 🏔️ ◽️

Aproximadamente. trad. : O autor deste artigo (Luc Perkins) é um desenvolvedor defensor do CNCF, lar de projetos de código aberto como Linkerd, SMI (Service Mesh Interface) e Kuma (a propósito, você também se perguntou por que o Istio não está nesta lista? .). Em outra tentativa de trazer um melhor entendimento do hype da moda chamado malha de serviço para a comunidade DevOps, ele cita 16 recursos característicos que essas soluções fornecem. A malha de serviço é um dos tópicos mais quentes na engenharia de software

hoje(e com razão!). Acho essa tecnologia incrivelmente promissora e sonho em testemunhar sua ampla adoção (quando fizer sentido, é claro). No entanto, ele ainda é cercado por um halo de mistério para a maioria das pessoas. Além disso, mesmo aqueles queconhece-o bem , muitas vezes é difícil formular suas vantagens e o que exatamente é (incluindo seu humilde servo). Neste artigo, tentarei remediar a situação listando vários cenários para o uso de "grades de serviço" *.

* Aproximadamente. transl.: aqui e mais adiante no artigo, esta é a tradução ("malha de serviço") que será usada para o ainda novo termo malha de serviço.

Mas, primeiro, quero fazer alguns comentários:

, . , service mesh Twitter 2015 ( « ») Linkerd, - .
— . , , .
Ao mesmo tempo, nem toda implementação de malha de serviço existente oferece suporte a todos esses casos de uso. Portanto, minhas expressões como "malha de serviço pode ..." devem ser lidas como "separadas e, possivelmente, todas as implementações de malha de serviço populares podem ...".
A ordem dos exemplos não importa.

Lista curta:

descoberta de serviço;
criptografia;
autenticação e autorização;
balanceamento de carga;
quebra de circuito;
escalonamento automático;
implantações canário;
implantações azul-esverdeadas;
exame de saúde;
derramamento de carga;
espelhamento de tráfego;
isolamento;
limitação de taxa, novas tentativas e tempos limite;
telemetria;
auditoria;
visualização.

1. Descoberta de serviço

TL; DR: Conecte-se a outros serviços na rede usando nomes simples.

Os serviços devem ser capazes de "descobrir" automaticamente uns aos outros por meio do nome apropriado - por exemplo service.api.production, pets/stagingou cassandra. Ambientes de nuvem são resilientes e um único nome pode ocultar várias instâncias de um serviço. É claro que em tal situação é fisicamente impossível codificar todos os endereços IP.

Além disso, quando um serviço encontra outro, ele deve ser capaz de enviar solicitações a esse serviço sem medo de que elas acabem na entrada de sua instância ociosa. Em outras palavras, a malha de serviço deve monitorar a integridade de todas as instâncias de serviço e manter a lista de hosts atualizada.

Cada malha de serviço implementa um mecanismo de descoberta de serviço de maneira diferente. No momento, a maneira mais comum é delegar para processos externos como DNS Kubernetes. No passado, no Twitter, usávamos o sistema de nomenclatura Finagle para essa finalidade . Além disso, a tecnologia de malha de serviço possibilita o surgimento de mecanismos de nomenclatura personalizados (embora eu ainda não tenha encontrado nenhuma implementação SM com essa funcionalidade).

2. Criptografia

TL; DR: livre-se do tráfego não criptografado entre os serviços e torne o processo automatizado e escalonável.

É bom saber que os invasores não conseguem penetrar na sua rede interna. Firewalls fazem um excelente trabalho nisso. Mas o que acontece se um hacker entrar? Ele pode fazer o que quiser com o tráfego intra-serviço? Vamos torcer para que isso não aconteça. Para evitar esse cenário, você deve implementar uma rede de confiança zero na qual todo o tráfego entre os serviços é criptografado. A maioria das malhas de serviço modernas consegue isso por meio de TLS mútuo .(TLS mútuo, mTLS). Em alguns casos, o mTLS funciona em nuvens e clusters inteiros (acho que algum dia as comunicações interplanetárias serão organizadas de forma semelhante).

Obviamente, para mTLS, a malha de serviço é opcional . Cada serviço pode cuidar de seu próprio TLS, mas isso significa que será necessário encontrar uma forma de gerar certificados, distribuí-los entre os hosts de serviço, incluir o código na aplicação que carregará esses certificados dos arquivos. Sim, lembre-se também de renovar esses certificados em intervalos regulares. As grades de serviço automatizam o mTLS com sistemas como o SPIFFE , que por sua vez automatiza o processo de emissão e rotação de certificados.

3. Autenticação e autorização

TL; DR: determine quem inicia a solicitação e o que eles podem fazer antes que a solicitação chegue ao serviço.

Os serviços muitas vezes querem saber quem está fazendo a solicitação (autenticação) e, usando essas informações, decidir o que o sujeito pode fazer (autorização). Nesse caso, o pronome "quem" pode ocultar:

Outros serviços. Isso é chamado de "autenticação de pares ". Por exemplo, um serviço webdeseja acessar um serviço db. Malhas de serviço geralmente resolvem esses problemas com mTLS: os certificados, neste caso, atuam como um identificador necessário.
-. « ». , haxor69 . , , JSON Web Tokens.

. , users, , permissions .. service mesh , .

Depois de estabelecermos de quem veio o pedido, precisamos determinar o que esse sujeito pode fazer. Algumas malhas de serviço permitem definir políticas de linha de base (quem pode fazer o quê) como arquivos YAML ou na linha de comando, enquanto outras oferecem integração com estruturas como o Open Policy Agent . O objetivo final é garantir que seus serviços aceitem todas as solicitações, assumindo com segurança que vêm de uma fonte confiável e que essa ação é permitida.

4. Balanceamento de carga

TL; DR: distribuição de carga nas instâncias de serviço de acordo com um padrão específico.

Um "serviço" dentro de uma seita de serviço muitas vezes consiste em muitas instâncias idênticas. Por exemplo, hoje o serviço cacheé composto por 5 exemplares, amanhã seu número pode aumentar para 11. Os pedidos dirigidos cachedevem ser distribuídos de acordo com um objetivo específico. Por exemplo, minimize a latência ou maximize a probabilidade de chegar a uma instância íntegra. O algoritmo round-robin mais comumente usado (round-robin), mas existem muitos outros - por exemplo, o método de solicitações ponderadas (ponderadas) (você pode selecionar o destino preferido), anular (anel)hashing (usando hashing consistente para hosts upstream) ou o método de solicitação mínima (a instância com menos solicitações é preferida).

Os balanceadores de carga clássicos têm outros recursos, como cache HTTP e proteção DDoS, mas não são muito relevantes para o tráfego leste-oeste (ou seja, para o tráfego que flui dentro de um data center - transl. Aprox.) (Uso típico do serviço malha). Claro, você não precisa usar uma malha de serviço para balanceamento de carga, mas permite definir e controlar políticas de balanceamento para cada serviço de uma camada de gerenciamento centralizado, eliminando assim a necessidade de iniciar e configurar balanceadores de carga separados na pilha de rede.

5. quebra de circuito

TL; DR: interrompe o tráfego para um serviço problemático e controle os danos nos piores cenários.

Se, por algum motivo, o serviço não consegue lidar com o tráfego, a malha de serviço oferece várias opções para resolver esse problema (outras serão discutidas nas seções correspondentes). A quebra de circuito é a maneira mais severa de desconectar um serviço do tráfego. No entanto, isso não faz sentido por si só - você precisa de um plano de backup. Pode fornecer contrapressão ( contrapressão ) em serviços que consultam (só não se esqueça de configurar sua malha de serviço para isso!), Ou, por exemplo, manchar o status da página em vermelho e redirecionar os usuários para outra versão da página com a "baleia cadente" («Twitter está desativado ").

As grades de serviço fazem mais do que apenas determinar quando e o que acontecerá a seguir. Nesse caso, "quando" pode incluir qualquer combinação dos parâmetros especificados: o número total de solicitações para um determinado período, o número de conexões paralelas, solicitações pendentes, novas tentativas ativas, etc.

Você pode não querer abusar da interrupção do circuito, mas é bom saber que existe um plano de contingência para emergências.

6. Escala automática

TL; DR: aumenta ou diminui o número de instâncias de serviço com base nos critérios especificados.

Malhas de serviço não são agendadores, portanto, não podem ser escalonadas por conta própria. No entanto, eles podem fornecer informações com base nas quais os planejadores tomarão decisões. Uma vez que as malhas de serviço têm acesso a todo o tráfego entre serviços, elas têm uma riqueza de informações sobre o que está acontecendo: quais serviços estão enfrentando problemas, quais estão muito fracamente carregados (a energia alocada a eles é desperdiçada), etc.

Por exemplo, o Kubernetes escalona serviços dependendo do uso de CPU e memória dos pods (veja nossa palestra " Escalonamento automático e gerenciamento de recursos no Kubernetes " - tradução aproximada), mas se você decidir escalonar com base em qualquer outra métrica (em nosso caso, relacionada ao tráfego), você precisará de uma métrica especial. Um tutorial como este mostra como fazer isso com Envoy , Istio e Prometheus , mas o processo em si é bastante complexo. Gostaríamos que a malha de serviço simplificasse simplesmente permitindo condições como "aumentar o número de instâncias de serviço authse o número de solicitações pendentes exceder o limite por um minuto".

7. Implantações canário

TL; DR: experimente novos recursos ou versões de serviço em um subconjunto de usuários.

Digamos que você esteja desenvolvendo um produto SaaS e pretenda lançar uma nova versão legal dele. Você testou na preparação e funcionou muito bem. Mesmo assim, existem certas preocupações sobre seu comportamento em condições reais. Em outras palavras, é necessário testar a nova versão em tarefas reais, sem arriscar a confiança do usuário. As implantações canário são ótimas para isso. Eles permitem que você demonstre um novo recurso para um subconjunto de usuários. Este subconjunto pode ser os usuários mais leais, ou aqueles que usam a versão gratuita do produto, ou aqueles que expressaram o desejo de ser cobaias.

As malhas de serviço fazem isso permitindo que você especifique os critérios que determinam quem vê qual versão do seu aplicativo e roteando o tráfego de acordo. Ao mesmo tempo, nada muda para os próprios serviços. A versão 1.0 do serviço acredita que todas as solicitações vêm de usuários que deveriam vê-lo, e a versão 1.1 assume o mesmo para seus usuários. Enquanto isso, você pode alterar a porcentagem de tráfego entre a versão antiga e a nova, redirecionando um número cada vez maior de usuários para a nova, se funcionar de forma estável e seu "experimental" autorizar.

8. Implementações azul-verdes

TL; DR: implante o novo recurso legal, mas esteja preparado para colocá-lo de volta imediatamente.

O objetivo das implantações azul-verde é lançar o novo serviço azul, executando-o em paralelo com o antigo verde. Se tudo correr bem e o novo serviço provar que está bem, o antigo pode ser gradualmente desligado. (Infelizmente, algum dia esse novo serviço "azul" repetirá o destino do "verde" e desaparecerá ...) As implantações azul-verdes diferem das implantações canário porque a nova função cobre todos os usuários de uma vez (não apenas uma parte); o ponto aqui é ter um "porto reserva" pronto para o caso de algo dar errado.

As malhas de serviço oferecem uma maneira muito conveniente de testar um serviço azul e alternar instantaneamente para um verde funcional em caso de problema. Isso sem falar no fato de que ao longo do caminho dão muitas informações (veja o item “Telemetria” abaixo) sobre a obra do “azul”, o que ajuda a entender se ele está pronto para uma exploração plena.

Aproximadamente. trad. : Leia mais sobre as diferentes estratégias de implantação do Kubernetes (incluindo o canário, azul / verde mencionado e outros) neste artigo .

9. Verificação de saúde

TL; DR: controle quais instâncias de serviço estão ativas e reaja àquelas que não estão mais.

Uma verificação de integridade ajuda a decidir se as instâncias de serviço estão prontas para receber e processar o tráfego. Por exemplo, no caso de serviços HTTP, uma verificação de integridade pode parecer uma solicitação GET para um ponto de extremidade /health. A resposta 200 OKsignificará que a instância está íntegra, qualquer outra - que não está pronta para receber tráfego. As malhas de serviço permitem que você especifique a maneira como a integridade será verificada e a freqüência com que essa verificação será realizada. Essas informações podem então ser usadas para outros fins, como balanceamento de carga e interrupção do circuito.

Portanto, a verificação de integridade não é um caso de uso independente, mas geralmente é usada para atingir outros objetivos. Além disso, dependendo dos resultados das verificações de saúde, ações externas (em relação a outros alvos das grades de serviço) podem ser necessárias: por exemplo, atualizar a página de status, criar um problema no GitHub ou preencher um tíquete do JIRA. E a malha de serviço oferece um mecanismo útil para automatizar tudo isso.

10. Descarte de carga

TL; DR: redireciona o tráfego em resposta a picos temporários de uso.

Se um determinado serviço estiver sobrecarregado com tráfego, você pode redirecionar temporariamente parte desse tráfego para outro local (ou seja, "despejar", " descartá- lo " lá). Por exemplo, para um serviço de backup ou centro de dados, ou para um tópico Pulsar permanente . Como resultado, o serviço continuará a processar parte das solicitações em vez de travar e parar de processar tudo. Despejar a carga é preferível a interromper o circuito, mas ainda não é desejável abusar dela. Ajuda a evitar falhas em cascata que causam falhas nos serviços downstream.

11. Paralelização / espelhamento de tráfego

TL; DR: Envie uma solicitação para vários locais ao mesmo tempo.

Às vezes, é necessário enviar uma solicitação (ou alguma amostra de solicitações) a vários serviços de uma vez. Um exemplo típico é o envio de parte do tráfego de produção para um serviço temporário. O servidor da web de produção principal envia uma solicitação para products.productione somente para o serviço downstream . E a malha de serviço copia essa solicitação de maneira inteligente e a envia para a products.stagingqual o servidor da web nem tem conhecimento.

Outro cenário de uso de grade de serviço relacionado que pode ser implementado no topo da paralelização de tráfego é o teste de regressão... Envolve enviar as mesmas solicitações para diferentes versões de um serviço e verificar se todas as versões se comportam da mesma maneira. Ainda não encontrei uma implementação de malha de serviço com um sistema de teste de regressão integrado como o Diffy , mas a ideia em si parece promissora.

12. Isolamento

TL; DR: Divida sua malha de serviço em mini malhas.

Também conhecido como segmentação , o isolamento é a arte de dividir uma grade de serviço em segmentos logicamente distintos que não sabem nada uns sobre os outros. O isolamento é um pouco como criar redes privadas virtuais. A diferença fundamental é que você ainda pode aproveitar todas as vantagens da malha de serviço (como descoberta de serviço), mas com segurança adicional. Por exemplo, se um invasor conseguir penetrar em um serviço em uma das sub-redes, ele não poderá ver quais serviços estão sendo executados em outras sub-redes ou interceptar seu tráfego.

Além disso, os benefícios podem ser organizacionais. Você pode querer dividir seus serviços com base na estrutura de sua organização e aliviar os desenvolvedores da carga cognitiva de ter toda a malha de serviço em mente.

13. Limitação de taxa, novas tentativas e tempos limite

TL; DR: Não é mais necessário incluir as tarefas urgentes de gerenciamento de solicitações na base de código.

Todas essas coisas podem ser vistas como casos de uso separados, mas decidi combiná-los por causa de uma coisa em comum: eles assumem as tarefas de gerenciamento do ciclo de vida da solicitação, geralmente feito por bibliotecas de aplicativos. Se você estiver desenvolvendo um servidor da web Ruby on Rails (não integrado à malha de serviço) que faz solicitações para serviços de back-end via gRPC, o aplicativo terá que decidir o que fazer se N solicitações falharem. Você também terá que descobrir quanto tráfego esses serviços serão capazes de manipular e codificar esses parâmetros usando uma biblioteca especial. Além disso, o aplicativo terá que decidir quando desistir e deixar o pedido incorreto (por tempo limite). E para alterar qualquer um dos parâmetros acima, o servidor web terá que ser parado, reconfigurado e reiniciado.

Transferir essas tarefas para a grade de serviço significa não apenas que os desenvolvedores de serviço não precisam pensar sobre elas, mas que podem ser vistas de uma maneira mais global. Se você estiver usando uma cadeia complexa de serviços, digamos A -> B -> C -> D -> E, todo o ciclo de vida da solicitação deve ser considerado. Se a tarefa é estender os tempos limites no serviço C, é lógico fazer tudo de uma vez, e não em partes: atualizando o código de serviço e aguardando que a solicitação pull seja aceita e o sistema de CI implante o serviço atualizado.

14. Telemetria

TL; DR: Colete todas as informações necessárias (e não exatamente) dos serviços.

Telemetria é um termo geral que inclui métricas, rastreio distribuído e registro. As grades de serviço oferecem mecanismos para coletar e processar todos os três tipos de dados. É aqui que as coisas ficam um pouco confusas, pois há tantas opções disponíveis. Para coletar métricas, há Prometheus e outras ferramentas, para coletar logs você pode usar fluentd , Loki , Vector , etc. (por exemplo, ClickHouse com nosso loghouse para K8s - approx.transl.) , Para rastreamento distribuído há Jaegeretc. Cada malha de serviço pode oferecer suporte a algumas ferramentas e não a outras. Ficará curioso para ver se o projeto de Telemetria Aberta pode fornecer alguma convergência.

Nesse caso, a vantagem da tecnologia de malha de serviço é que os contêineres secundários podem, em princípio, coletar todos os dados acima de seus serviços. Em outras palavras, você tem um único sistema de coleta de telemetria à sua disposição, e a malha de serviço pode processar todas essas informações de maneiras diferentes. Por exemplo:

tail 'registra de um determinado serviço na CLI;
controlar o volume de solicitações do painel de malha de serviço;
coletar rastreamentos distribuídos e redirecioná-los para um sistema como o Jaeger.

Atenção, julgamento subjetivo: De modo geral, a telemetria é uma área onde uma forte interferência da malha de serviço é indesejável. Coletar informações básicas e rastrear algumas das "métricas de ouro" em tempo real, como taxas de sucesso e latências, é ótimo, mas esperamos não ver o surgimento de pilhas de Frankenstein que tentam substituir sistemas especializados, alguns dos quais já se provaram excelentes. e bem estudado.

15. Auditoria

TL; DR: Aqueles que esquecem as lições da história estão condenados a repeti-las.

Auditar é a arte de observar eventos importantes no sistema. No caso de uma malha de serviço, isso pode significar manter o controle de quem fez solicitações a endpoints específicos de determinados serviços ou quantas vezes no último mês houve um evento relacionado à segurança.

É claro que a auditoria está intimamente relacionada à telemetria. A diferença é que a telemetria geralmente está associada a coisas como desempenho e correção técnica, enquanto a auditoria pode estar relacionada a questões legais e outras que vão além da área estritamente técnica (por exemplo, conformidade com os requisitos do GDPR - Regulamento Geral da UE para proteção de dados).

16. Visualização

TL; DR: Long live React.js - uma fonte inesgotável de interfaces sofisticadas.

Talvez haja um termo melhor, mas não o conheço. Quero dizer apenas uma representação gráfica da malha de serviço ou alguns de seus componentes. Essas visualizações podem incluir indicadores como latências médias, informações de configuração do sidecar, resultados de verificação de integridade e alertas.

Trabalhar em um ambiente orientado a serviços carrega uma carga cognitiva muito maior do que Sua Majestade o Monólito. Portanto, a pressão cognitiva deve ser reduzida a todo custo. Uma interface gráfica cafona para uma malha de serviço com a capacidade de clicar em um botão e obter o resultado desejado pode ser crítica para o crescimento dessa tecnologia.

Não incluído na lista

Originalmente, pretendia incluir mais alguns casos de uso na lista, mas decidi não fazê-lo. Aqui estão eles, juntamente com os motivos da minha decisão:

Multi-data center . Em minha opinião, este não é tanto um caso de uso quanto uma área estreita e específica de aplicação de grades de serviço ou algum conjunto de funções como descoberta de serviço.
Entrada e saída . Esta é uma área relacionada, mas eu me limitei (talvez artificialmente) ao cenário de tráfego leste-oeste. A entrada e a saída merecem um artigo separado.

Conclusão

É tudo por agora! Novamente, esta lista é altamente provisória e provavelmente incompleta. Se você acha que estou perdendo algo ou me engano sobre algo, entre em contato comigo no Twitter ( @lucperkins ). Por favor, observe as regras de decência.

PS do tradutor

Como base para a ilustração do título do artigo, uma imagem do artigo “ O que é uma malha de serviço (e quando usá-la)? "(Por Gregory MacKinnon). Mostra como algumas das funcionalidades dos aplicativos (em verde) foram movidas para a malha de serviço, que fornece interconexões entre eles (em azul).

Leia também em nosso blog:

Casos de uso de malha de serviço