O potencial uso de service mesh na comunicação orientada a eventos

O service mesh está se tornando cada vez mais popular como uma tecnologia essencial e um padrão arquitetural para se ter como base em microservices e arquiteturas cloud-native. Um service mesh é primariamente um componente de infraestrutura de rede que permite que a lógica de comunicação com a rede seja removida da aplicação, de forma a permitir que a aplicação foque apenas na lógica de negócio do serviço.

Um service mesh é construído em torno do conceito de um proxy, que é disponibilizado juntamente com o serviço como um sidecar. Embora seja dito frequentemente que um service mesh serve como uma plataforma para qualquer aplicação cloud-native, as implementações populares de service mesh (Istio/Envoy/Linkerd/etc) atualmente apenas proveem o estilo request-response de comunicação síncrona entre os microservices. Entretanto, na maioria dos casos de uso de microservices, a comunicação entre os serviços acontece em variados padrões, como request-response (HTTP, gRPC, GraphQL) e mensageria (NATS, Kafka, AMQP). Como as implementações de service mesh não suportam a comunicação orientada a eventos, a maioria das funcionalidades que os service meshes oferecem são apenas disponíveis para os serviços síncronos de request-response - microservices orientados a eventos devem suportar essas funcionalidades como parte do código do serviço, o que contradiz o objetivo principal da arquitetura de service mesh.

É crítico que o service mesh suporte a comunicação orientada a eventos. Este artigo descreve os aspectos chaves para o suporte à arquitetura orientada a eventos em um service mesh e como as tecnologias existentes de service mesh estão tentando atender a essas necessidades.

Implementando mensageria orientada a eventos.

Em um cenário típico de troca de mensagens síncronas, há um serviço e um consumidor do serviço. O data plane do service mesh atua como um intermediário entre o cliente e o serviço. Na comunicação orientada a eventos, o padrão de comunicação é drasticamente diferente. Um produtor de eventos assincronamente envia os eventos a um broker, sem canal direto de comunicação entre o produtor e consumidor. O estilo de comunicação pode ser pub-sub (com múltiplos consumidores) ou baseado em filas (com consumidor único) e, dependendo do estilo, o produtor pode enviar mensagens para um tópico ou uma fila, respectivamente.

O consumidor decide assinar um tópico ou uma fila que reside no event broker, que é totalmente desacoplado do produtor. Quando há novas mensagens disponíveis para o tópico ou fila, o broker envia as mensagens ao consumidor.

Existem algumas maneiras para usar o service mesh como abstração à comunicação orientada a eventos.

Protocol-proxy sidecar

O pattern protocol-proxy é construído em torno do conceito de que toda comunicação orientada a eventos deve passar através do data plane do service mesh (por exemplo, o proxy sidecar). Para suportar os protocolos de comunicação orientada a eventos como NATS, Kafka ou AMQP, é necessário construir um handler/filter do protocolo, específico ao protocolo de comunicação e adicioná-lo ao sidecar proxy. A figura 1 mostra o padrão de comunicação típico de comunicação orientada a eventos em um service mesh.

[Clique na imagem para expandi-la]

Figura 1: Comunicação orientada a eventos com um service mesh

Como a maioria do protocolos de comunicação orientada a eventos são implementados em cima do TCP, o sidecar proxy pode ter handlers/filters de protocolos construídos em cima do TCP para especificamente suportar as abstrações necessárias para cada um dos vários protocolos de mensageria.

O microservice produtor (microservice A) envia mensagens ao sidecar através do protocolo de mensageria específico (Kafka, NATS, AMQP, etc) utilizando o código mais simples para o produtor, enquanto o sidecar controla a maior parte das complexidades relacionadas com o protocolo. De forma similar, a lógica do serviço consumidor (microservice B) também é bem simples, enquanto a complexidade fica no sidecar. As abstrações providas pelo service mesh podem mudar de acordo com o protocolo.

A equipe do Envoy está atualmente trabalhando na implementação do suporte ao Kafka para o proxy Envoy, com base no padrão acima. Ainda é um trabalho em progresso mas é possível acompanhar o progresso através do GitHub.

HTTP-bridge sidecar

Ao invés de utilizar um proxy para os protocolos de mensageria, é possível construir uma ponte HTTP que traduz as mensagens de/para um protocolo de mensageria necessário. Uma das principais motivações para a criação deste padrão é que a maioria dos brokers de eventos oferecem uma API REST (por exemplo, API REST do Kafka) para consumir e produzir mensagens. Como mostrado na figura 2, os microservices existentes podem consumir os brokers de eventos de forma transparente, simplesmente controlando o sidecar que une os dois protocolos. O sidecar é responsável por receber uma requisição HTTP e traduzi-lá em mensagens Kafka/NATS/AMQP e vice versa.

Clique na imagem para expandi-la

Figura 2: O HTTP bridge permite que os serviços se comuniquem com o broker de eventos via HTTP.

De forma similar, é possível utilizar o HTTP bridge para permitir que microservices baseados no Kafka/NATS/AMQP se comuniquem diretamente com microservices HTTP (ou outro protocolo de mensageria request-response) como é demonstrado na imagem 3. Neste caso, o sidecar recebe requisições Kafka/NATS/AMQP, redireciona as mesmas por HTTP, e traduz as respostas HTTP de volta ao protocolo de mensageria. Há alguns esforços em andamento para adicionar o suporte a este padrão no Envoy e NATS (por exemplo, AMQP/HTTP Bridge e NATS/HTTP bridge, ambos para o Envoy)

Clique na imagem para expandi-la

Figura 3: O HTTP Bridge permite que os serviços baseados em protocolos de comunicação orientada a eventos consumam serviços HTTP

Embora o pattern HTTP-bridge funcione para certos casos, não é recomendado para servir como padrão no suporte a comunicação orientada a eventos na arquitetura de service-mesh, pois sempre há limitações na tradução entre os protocolos de mensageria e os protocolos de request-response. O pattern é quase um improviso que pode funcionar para alguns casos de uso.

Principais capacidades de um service mesh orientado a eventos.

As capacidades de um service mesh convencional baseadas no estilo request-response são de alguma forma diferentes das capacidades de um service mesh que suporta os paradigmas de mensageria. Aqui estão algumas das capacidades únicas que um service mesh que suporta mensageria oferece:

• Abstrações de consumidores e produtores - Na maioria dos sistemas de mensageria, como o Kafka, o broker é simples e abstrato (uma simples parte no contexto de microservices) e seus serviços são as partes com inteligência (a maior parte da inteligência vive no código do produtor ou consumidor). Isto significa que os produtores ou consumidores devem ter muito código específico do protocolo de mensageria junto com o código de negócio. Com a introdução de um service mesh, é possível remover essa inteligência (por exemplo: rebalanceamento de partição no Kafka) relacionadas aos protocolos de mensageria para o sidecar e focar exclusivamente na lógica de negócio do microservice;
• Semântica da entrega de mensagens - Há muitas semânticas na entrega de mensagens como "no máximo uma vez", "pelo menos uma vez", "exatamente uma vez", etc. Dependendo do que o sistema de mensageria suporta, essa inteligência pode ser realocada para o service mesh (isto é análogo ao suporte a circuit breakers, timeouts, etc, no paradigma de request-response);
• Semânticas de subscrição - É possível utilizar a camada de service mesh para controlar as semânticas de subscrição, como uma subscrição duradoura na lógica do consumidor;
• Throttling - É possível controlar os limites de consumo de mensagens baseado em vários parâmetros, como o número de mensagens, tamanho das mensagens, etc;
• Service discovery (descoberta de broker, tópicos e filas) - O sidecar do service mesh possibilita a descoberta da localização do broker, dos tópicos ou dos nomes das filas durante a produção e consumo de mensagens. Isto envolve o tratamento de diferentes hierarquias de tópicos e wildcards;
• Validação de Mensagem - A validação de mensagens utilizada na comunicação orientadas a eventos está se tornando importante porque a maioria dos protocolos de mensageria como o Kafka, NATS, etc, são agnósticos de protocolo. Por isso, a validação de mensagens é parte da implementação de consumidores e produtores. O service mesh pode prover esta abstração de modo que consumidores e produtores não precisem se preocupar com a validação de mensagens. Por exemplo, se você usa o Kafka com o Avro para validação de schema, é possível utilizar o sidecar para fazer a validação (por exemplo: buscar o schema de um registro externo, como o Confluent, e validar a mensagem de acordo com o schema). É possível utilizar essa validação também para verificar conteúdo malicioso;
• Compressão de Mensagem - Alguns protocolos de mensageria, como o Kafka, permitem que os dados sejam comprimidos pelo produtor, escritos no formato comprimido para o servidor e descomprimidos pelo consumidor. É possível implementar facilmente essas capacidades no nível do proxy do sidecar e controlar-los no control plane do service mesh;
• Segurança - É possível garantir a comunicação entre o broker e os consumidores/produtores habilitando TLS no nível do sidecar do service mesh, então as implementações dos produtores e consumidores não precisam se preocupar com a segurança da comunicação e podem se comunicar com o sidecar em texto simples;
• Observability - Como todas as comunicações acontecem através do data plane do service mesh, é possível entregar métricas, tracing e logging de forma transparente para todos os sistemas que utilizam mensageria.

Sobre o Autor

Kasun Indrasiri é diretor de Arquitetura de Integração na WSO2 e é autor/evangelista de arquitetura de microservices e arquitetura de integração de sistemas corporativos. Escreveu os livros Microservices for Enterprise (Apress) e Beginning WSO2 ESB (Apress). Ele é um commiter da Apache e trabalhou como gerente de produtos e arquiteto no WSO2 Enterprise Integrator. Esteve presente nas conferências de Arquitetura de Software da O'Reilly, GOTO Chicago 2019 e a maioria das conferências da WSO2. Está presente na maioria dos meetups sobre microservices na região da Baía de São Francisco. Fundou o meetup Microservices, APIs e Integrações do Vale do Silício, um meetup sobre microservices na região de Baía de São Francisco.