Se você busca criar uma arquitetura moderna de microsserviços, que seja altamente escalável, observável, segura e resiliente, faz sentido considerar algumas das tecnologias de service mesh que estão evoluindo rapidamente. No momento em que este texto foi escrito, o Istio é um dos principais frameworks que vem ganhando muito impulso e é um concorrente-chave na corrida de service mesh.
Para aqueles que são novos no assunto, uma service mesh é uma camada de software de infraestrutura entre um microsserviço e uma rede, que libera os desenvolvedores das considerações sobre políticas e rede, e provê os operadores com controles para monitoramento, aplicação de políticas, networking e questões sobre resiliência.
A service mesh faz isso utilizando uma estratégia bem definida: em vez de colocar um componente de software que implementa o pattern de proxy reverso de forma centralizada na frente de um grande número de serviços, como é bastante comum em arquiteturas orientadas a serviços, ela coloca uma variante mais leve desse proxy juntamente com cada serviço. Além de ser um proxy reverso, esse componente, também chamado de “sidecar” (devido ao fato de que cada serviço possui uma instância própria desse componente “ao seu lado”, como aqueles carros laterais acoplados a motocicletas antigas), é capaz de executar roteamento de tráfego, comunicação entre serviços, aplicação de políticas de acesso, controle de fluxo e uma miríade de outros recursos que tornam esse padrão muito poderoso.
Fonte: https://www.infoq.com/presentations/istio-service-mesh
Toda a comunicação dentro e fora do serviço é mediada através do sidecar que, agora, é capaz de realizar várias funcionalidades genéricas que, além de liberar o desenvolvedor dos detalhes referentes à interação com a rede, também oferece aos responsáveis por administrar a rede e sustentar a operação dos sistemas uma maneira uniforme de gerenciar e monitorar os microsserviços.
O Istio baseia-se em um sidecar amplamente testado, o Envoy, que foi desenvolvido e é usado em produção na Lyft há vários anos. Foi construído usando C++, consome pouca memória e suporta atualizações dinâmicas de configuração, balanceamento de carga inteligente, divisão de tráfego baseada em regras configuráveis, roteamento, circuit breakers, timeouts, mecanismo para repetição de tentativas em casos de falha (retries), injeção de falhas (para facilitar a realização de testes), além de trabalhar com os protocolos HTTP/2 e gRPC. Cada instância do side car é orquestrada pelo Istio através da rede por um módulo piloto (veja figura).
Fonte: https://www.infoq.com/presentations/istio-service-mesh
O Pilot, o Mixer e o CA (Certification Authority) constituem a camada de controle (plano de controle) do Istio através do qual toda a configuração, a aplicação de políticas e o controle de fluxo acontecem. A camada de dados (plano de dados), por sua vez, é constituída de todos os proxies (que fazem parte de cada instância do Envoy) que mediam todas as requisições de serviço e as comunicações de dados.
Cada instância do Envoy publica métricas para o módulo Mixer, que possui adaptadores para vários backends de monitoramento populares, por exemplo, um bem conhecido é o Prometheus. O Mixer também é usado para avaliação de políticas, implementação de cotas e limitação de tráfego de chamadas e dados.
Fonte: https://www.infoq.com/presentations/istio-service-mesh
O Envoy, sendo um proxy reverso que cumpre tanto as atribuições da Camada 4 quanto da Camada 7, é capaz de realizar controle de tráfego complexo com base em regras impostas pelos administradores da plataforma e pode ser configurado para aplicar as novas regras imediatamente, sem reinicialização. Isso torna a infraestrutura extremamente ágil para a equipe de operações. Veja na figura a seguir um exemplo de como 1% do tráfego pode ser direcionado para uma rota alternativa para a realização de testes A/B:
Fonte: https://www.infoq.com/presentations/istio-service-mesh
Isso seria possível forçando a seguinte mudança de política para o Envoy:
Fonte: https://www.infoq.com/presentations/istio-service-mesh
O Envoy também pode realizar roteamento de mensagens da Camada 7 para direcionamento de tráfego com base em cabeçalhos HTTP, como no cenário abaixo:
Fonte: https://www.infoq.com/presentations/istio-service-mesh
O Envoy também cuida da integração com ferramentas como o Zipkin, que fornece recursos de rastreamento distribuído, trazendo para a camada da service mesh funções como a observação de uma interação distribuída complicada em busca de uma relação de causalidade, algo que antes os desenvolvedores precisavam considerar e incorporar em seus serviços.
As métricas capturadas pelos backends de monitoramento podem ser visualizadas por meio de muitas das ferramentas disponíveis, como Grafana, para uma visualização em tempo real do estado e das condições de funcionamento da service mesh.
Uma das principais diferenças desse pattern, em comparação com o middle proxy centralizado, é que o sidecar está vinculado ao mesmo domínio que o serviço e, no caso de comprometimento, isso reduz a área de ataque. Em segundo lugar, essa arquitetura também permite que os serviços implementem políticas com maior controle da comunicação entre serviços, usando identidades criptografadas, ao invés de elementos que podem ser falsificados por um usuário interno mal-intencionado (e esperto).
Por exemplo, o serviço A pode ser configurado para ter permissão apenas para chamar o serviço B, e a interação será regida e controlada pelo proxy através do uso de certificados TLS com o Istio CA. Anteriormente, esse tipo de aplicação de política era complicado em ambientes altamente dinâmicos, como plataformas de orquestração, onde os endereços IP mudam com frequência e a carga de trabalho tende a ser altamente variável. Isso tornava muito difícil proteger os sistemas contra os ataques internos, pois não havia identidade inerente vinculada ao serviço que pudesse ser criptograficamente verificada no momento da execução.
Fonte: https://www.infoq.com/presentations/istio-service-mesh
No caso de um possível comprometimento da segurança, os certificados vinculados às identidades podem ser revogados individualmente, proporcionando um controle mais preciso sobre a área eventualmente comprometida.
Fonte: https://weeraman.com/building-a-service-mesh-with-istio-be5ccce1bf98
Autor: Anuradha Weeraman
