Bom dia a todos!
Hoje, temos o prazer de oferecer uma tradução de um artigo que fala brevemente sobre uma nova tendência tecnológica chamada “Service mesh”. A solução mais interessante nessa área (em nossa opinião) é o
Istio , mas o artigo proposto é interessante, antes de tudo, pela comparação expressa de tecnologias existentes desse tipo e uma visão geral de alto nível de todo o paradigma. O autor, Tobias Kunze, também escreveu um segundo artigo mais prático sobre a malha de serviços - um pedido para expressar se vale a pena publicar sua tradução
Este post é o primeiro de dois que fala sobre os benefícios das redes de serviço. Este artigo descreve o que é uma rede de serviço, como ela funciona e qual é a sua utilização. A
segunda parte explora por que, onde e quando usar essas redes e o que está por vir.
Ao decompor um aplicativo em microsserviços, fica rapidamente claro que chamar um serviço pela rede é um processo muito mais complexo e menos confiável do que se pensava. O que deveria "apenas funcionar" pelo design agora deve ser claramente articulado para cada cliente e cada serviço. Os clientes precisam descobrir terminais de serviço, garantir que sejam consistentes nas versões da API e empacotar e descompactar mensagens. Os clientes também precisam acompanhar a execução de chamadas e gerenciar essas operações, detectando erros, repetindo chamadas com falha e mantendo um tempo limite, se necessário. Os clientes também podem precisar verificar a autenticidade dos serviços, chamadas de log e transações de instrumentos. Por fim, acontece que o aplicativo inteiro deve estar em conformidade com as regras do
IAM , os requisitos de criptografia ou controle de acesso.
Obviamente, a maioria desses problemas não é nova e, por um longo tempo, temos à nossa disposição tecnologias que ajudam a organizar mecanismos de mensagens, por exemplo, SOAP, Apache Thrift e gRPC. Mas o que foi observado recentemente: a rápida distribuição de contêineres e o crescente crescimento explosivo de chamadas de serviço, o grau de escala horizontal e a curta duração dos terminais de serviço associados a ela. Quando a complexidade e a fragilidade atingem um novo nível, há um desejo de encapsular a comunicação de rede e levá-la a um novo nível de infraestrutura. A abordagem mais popular para fornecer esse nível, aplicada hoje, é chamada de "rede de serviços".
O que exatamente é uma "rede de serviço"?
Uma rede de serviço não é uma “grade de serviço”. Essa é uma rede de intermediários de API (proxies) aos quais (micro) serviços podem se conectar para abstrair completamente a rede. Como William Morgan
colocou , esta é "uma camada de infraestrutura dedicada que fornece comunicação segura, rápida e confiável entre serviços". As redes de serviço ajudam a lidar com os muitos desafios que os desenvolvedores enfrentam quando precisam trocar informações com terminais remotos. No entanto, deve-se notar que os principais problemas operacionais com a ajuda das redes de serviço não são resolvidos.
Como as redes de serviço funcionam?
Arquitetura de rede de serviço típica. Os proxies no plano de dados são implantados como complementares (carro lateral), e o plano de controle está localizado separadamente.Em uma rede de serviços típica, os serviços implantados são modificados para que cada um deles seja acompanhado por seu próprio
"companheiro" proxy . Os serviços não chamam diretamente outros serviços pela rede, mas recorrem a seus companheiros proxy locais, que, por sua vez, encapsulam a complexidade da troca de informações entre serviços. Esse conjunto interligado de proxies implementa o chamado plano de dados.
Pelo contrário, o conjunto de APIs e ferramentas usadas para controlar o comportamento do proxy em toda a rede de serviço é chamado de "plano de controle". É no plano de controle que os usuários definem políticas e configuram o plano de dados como um todo.
Para implementar uma rede de serviço, são necessários um plano de dados e um plano de controle.
Principais jogadores: Enviado, Linkerd, Istio e Cônsul
O Envoy é um servidor proxy de código aberto desenvolvido pela Lyft. Hoje, ele forma um plano de dados em muitas redes de serviços, incluindo o Istio. O Enviado substituiu rapidamente outros proxies graças à sua API de configuração conveniente, que permite que os aviões de controle ajustem seu comportamento em tempo real.
O Linkerd é um projeto de código aberto suportado pela Buoyant e, ao mesmo tempo, a primeira rede de serviços. Foi originalmente escrito em Scala, como
Finagle , do Twitter, de onde veio, e depois se fundiu com o projeto leve do Conduit e foi reiniciado como
Linkerd 2.0 .
Istio é talvez a rede de serviço mais popular do nosso tempo. Foi lançado em conjunto pelo Google, IBM e Lyft; espera-se que ela entre no projeto da CNC
-Native Cloud Computing Foundation (CNCF). A rigor, o Istio é um plano de controle e, para formar uma rede de serviços, deve ser combinado com o plano de dados. O Istio é normalmente usado com o Envoy e funciona melhor no Kubernetes.
Cônsul é um fenômeno relativamente novo no ecossistema de aviões de controle. Funciona melhor com topologias que abrangem muitos data centers e é especializado em descoberta de serviços. O Consul trabalha com muitos planos de dados e pode ser usado sem envolver outros planos de controle, por exemplo, sem o Istio. Seu apoio é a HashiCorp.
Principais vantagens e diferenças de prioridades
Embora o espaço das redes de serviço continue evoluindo, a maioria dos projetos, aparentemente, já chegou à idéia do conjunto principal de recursos que devem ser suportados em uma rede:
- Descoberta de serviços: descobrindo serviços e mantendo seu registro
- Roteamento : balanceamento de carga inteligente e roteamento de rede, melhores testes de desempenho, padrões de implantação automática, como configurações azul esverdeado e canário
- Estabilidade : novas tentativas, tempos limites e disjuntores
- Segurança : criptografia baseada em TLS, incluindo gerenciamento de chaves
- Telemetria : coletando métricas e identificadores de rastreamento
Além desses recursos (e às vezes com base neles), há também um nível mais rico de funções em que diferenças sérias começam entre diferentes redes de serviço sobre o que pode ser valioso para arquitetos, desenvolvedores e administradores de sistemas de microsserviço. Por exemplo, o Envoy suporta WebSockets, mas o Linkerd 2.0 (ainda não). Enquanto o Istio e o Consul suportam planos de dados diferentes, o Linkerd funciona apenas com seus próprios. O Consul tem seu próprio plano de dados embutido, que pode ser substituído por um mais poderoso quando a questão do desempenho se tornar uma prioridade. O Istio foi projetado como um plano de controle centralizado separado, enquanto o Consul e o Linkerd são totalmente distribuídos. Finalmente, de todas as redes de serviço discutidas acima, apenas o Istio suporta a injeção de falhas. Essas são apenas algumas das principais diferenças a serem consideradas se você estiver pensando em introduzir uma rede desse tipo.
Críticas à rede de serviço
Apesar da popularidade óbvia e dos recursos atraentes e promissores, as redes de serviços não são tão amplamente usadas quanto o esperado. Sem dúvida, isso se deve em parte à sua novidade e ao fato de que toda essa indústria continua a tomar forma. Mas, falando sobre redes de serviço, você não pode ficar sem algumas críticas.
O ceticismo associado às redes de serviço se relaciona principalmente à complexidade adicional que elas trazem, à produtividade relativamente baixa e a algumas lacunas que aparecem ao trabalhar com topologias de vários clusters.
As redes de serviço são plataformas ambíguas, no estágio inicial de implementação, das quais são necessários sérios investimentos na montagem do próprio sistema e de seus equipamentos instrumentais. Pode parecer que adicionar um acompanhante ao contêiner é bastante fácil, no entanto, o manuseio e a tentativa de falha competentes requerem sérios esforços de engenharia. Pode ser difícil justificar esses investimentos ao trabalhar com aplicativos existentes com um ciclo de vida curto ou com aplicativos em rápido desenvolvimento.
Além disso, as redes de serviço podem prejudicar seriamente o desempenho do aplicativo em comparação ao uso de chamadas diretas de rede. Os problemas que surgem nesse caso às vezes são difíceis de diagnosticar e, mais ainda, de eliminar. Como a maioria das redes de serviços tem como objetivo trabalhar com aplicativos de microsserviço independentes, e não em cenários completos de aplicativos relacionados, essas redes geralmente têm pouco suporte implementado para soluções para muitos clusters e regiões diferentes.
Em resumo, as redes de serviços não são uma panacéia para arquitetos e operadores que procuram se adaptar de maneira flexível à operação de uma crescente frota de serviços digitais. Essa rede é uma solução tática, pois representa uma melhoria técnica "fundamental" projetada para resolver problemas relevantes, principalmente para desenvolvedores. No nível comercial, eles não reverterão a situação.
Tecnologia relacionada
As redes de serviço se cruzam com outros componentes da arquitetura, mas, é claro, não são redutíveis a eles. Esses elementos incluem APIs, gateways de aplicativos, balanceadores de carga, controladores de tráfego de entrada e saída (entrada e saída) ou gateways de entrega de aplicativos. O principal objetivo do gateway da API é fornecer serviços com acesso ao mundo externo, enquanto atua como uma única API para fornecer funções de balanceamento de carga, segurança e gerenciamento básico. Os controladores de tráfego de entrada e saída transmitem informações entre endereços não roteáveis na orquestra de contêineres e endereços roteados fora dela. Finalmente, os controladores de entrega de aplicativos são semelhantes aos gateways de API, mas sua especialização é acelerar a entrega de aplicativos da Web, não apenas a API.