Lyft Envoy e o nascimento do service mesh

01 · CONTEXTO

Da arquitetura monolítica à rede como problema

O Envoy foi construído no Lyft para afastar a arquitetura da empresa de um monólito. Segundo o anúncio da CNCF, Matt Klein liderou a equipe que projetou a tecnologia para abstrair da pessoa desenvolvedora a maior parte da complexidade de rede.

A ideia central do projeto é que a rede deve ser transparente para as aplicações: quando surgem problemas de rede ou de aplicação, deve ser fácil descobrir a origem. A documentação descreve o Envoy como um proxy de camada de aplicação e barramento de comunicação para arquiteturas orientadas a serviços grandes e modernas.

A documentação observa ainda que é cada vez mais comum que essas arquiteturas usem vários frameworks de aplicação e linguagens.

02 · A IDEIA

Um proxy ao lado de cada serviço

O Envoy é um processo autônomo, feito para rodar ao lado de cada servidor de aplicação. Todos os Envoys formam uma malha de comunicação transparente. Cada aplicação envia e recebe mensagens por localhost e não conhece a topologia da rede.

1. O serviço chamador só conhece o proxy que roda ao lado dele e fala com ele por localhost.

2. O proxy do chamador leva a chamada pela rede até o proxy do destino, que faz parte da mesma malha.

3. O proxy do destino entrega a chamada à aplicação local, que também não precisa conhecer a topologia.

4. Os proxies também emitem estatísticas para um coletor.

Segundo a CNCF, o Envoy é escrito em C++ por motivos de desempenho, e sua arquitetura fora do processo serve a qualquer aplicação, em qualquer linguagem ou runtime.

A documentação aponta dois benefícios substanciais dessa arquitetura sobre a abordagem tradicional de biblioteca: ela funciona com qualquer linguagem de aplicação e permite implantar e atualizar rapidamente em toda a infraestrutura.

03 · DESCOBERTA

Descoberta de serviços e configuração dinâmica

O Envoy pode consumir, de forma opcional, um conjunto em camadas de APIs de configuração dinâmica para gestão centralizada. As camadas trazem atualizações sobre os hosts de um cluster de backend, os próprios clusters, o roteamento HTTP, os sockets de escuta e o material criptográfico.

Para uma implantação mais simples, a descoberta de hosts de backend pode ser feita por resolução de DNS. A forma recomendada de montar uma malha, porém, é tratar a descoberta de serviços como um processo eventualmente consistente.

1. A configuração dinâmica chega ao proxy a partir de um serviço de gestão central.

2. Entre as atualizações estão os hosts que compõem cada cluster de backend.

3. O proxy pode checar ativamente a saúde dos clusters upstream.

4. Ele combina o que a descoberta informa com o resultado do health checking para definir os alvos saudáveis do balanceamento.

5. Além da checagem ativa, há health checking passivo, feito por um subsistema de detecção de outliers.

04 · COMPORTAMENTO

O que um proxy único centraliza

Por ser um proxy autônomo e não uma biblioteca, o Envoy implementa técnicas avançadas de balanceamento de carga em um só lugar, acessíveis a qualquer aplicação. A lista do anúncio da CNCF inclui consciência de zona, retentativas, timeouts, circuit breaking, limitação de taxa, shadowing e detecção de outliers.

A documentação também vê benefício substancial em usar o mesmo software na borda. O Envoy tem um subsistema de roteamento que roteia requisições com base em path, authority e tipo de conteúdo, entre outros critérios.

1. O tráfego externo entra por um proxy de borda, o mesmo tipo de software que roda ao lado dos serviços.

2. O proxy de borda roteia a requisição para o serviço de destino.

3. Dali em diante, as chamadas entre serviços seguem pela malha de proxies ao lado de cada serviço.

O objetivo principal é tornar a rede transparente, mas a documentação reconhece que problemas ocorrem tanto no nível da rede quanto no da aplicação. Por isso o Envoy inclui suporte robusto a estatísticas para todos os subsistemas e suporta rastreamento distribuído por provedores de terceiros.

05 · LEGADO

Do Lyft ao ecossistema de service mesh

Segundo a CNCF, service meshes fornecem uma camada de infraestrutura dedicada a tornar a comunicação serviço a serviço segura, rápida e confiável. Klein descreveu o Envoy como um data plane universal, em que a malha funciona onde quer que o código esteja rodando.

O anúncio da CNCF foi publicado em 13 de setembro de 2017 e registra a votação do Envoy como o 11º projeto hospedado. Ele afirma que várias empresas contribuem para o projeto, incluindo Google e IBM, e que o Lyft colabora com Google e IBM para levar o Envoy ao Kubernetes por meio do projeto Istio.