Saiba como manter a comunicação integrada em uma arquitetura de microsserviços a fim de obter melhores resultados

A arquitetura orientada a microsserviços promete sistemas mais flexíveis, escaláveis e com manutenção mais simples do que as arquiteturas de sistemas monolíticos. No entanto, com muitos serviços pequenos interagindo para concluir uma única atividade de negócios, a comunicação entre os microsserviços deve ser eficiente. Mas isso pode ser um desafio para os gerentes de sistemas.

O problema pode começar já na passagem de arquitetura monolítica para microsserviços, que gera consequências negativas, como ineficiência do sistema e baixo desempenho. 

Para Everton Oliveira de Almeida, desenvolvedor na Supero Tecnologia, no mundo da arquitetura monolítica, a comunicação entre os componentes pode se dizer que é bastante simples, quando se comparado a uma arquitetura de microsserviços:

Isso acontece porque a aplicação de um monolítico foi construída em um único bloco e não tem dependência de serviços externos. No entanto, se você estiver pensando em ir de uma arquitetura monolítica para uma arquitetura baseada em microsserviços, a comunicação pode ser o maior desafio a ser enfrentado pelo seu time.

Para entender melhor quais os principais desafios na comunicação entre microsserviços e as possíveis soluções para superá-los, continue a leitura deste artigo.

Saiba mais: Microsserviços: conceito, vantagens e desvantagens desse tipo de arquitetura

Comunicação em aplicações monolíticas

Na arquitetura monolítica, executada em um único processo, os componentes interagem entre si usando um método no nível da linguagem ou chamadas de função. Eles poderão ser fortemente acoplados, se o desenvolvedor estiver criando objetos com código, por exemplo, ou poderão ser invocados de forma desacoplada, se estiver usando injeção de dependência referenciando abstrações em vez de instâncias concretas de objeto.

De acordo com Almeida, em um monolito, ao se fazer uma requisição onde é necessário ir até ao banco de dados, por exemplo, um componente chama o outro usando métodos ou funções. 

Essa chamada pode se dar através de uma abstração, se você estiver usando injeção de dependência – baixo acoplamento, ou pode acontecer de forma altamente acoplada, quando você precisa instanciar a classe e utilizar diretamente seus métodos.

Leia também: SOA vs. microsserviços: como determinar qual é a arquitetura ideal?

Passando da arquitetura monolítica para microsserviços: desafios em comunicação

O maior desafio ao passar de um aplicativo monolítico para um aplicativo baseado em microsserviços é alterar o mecanismo de comunicação.

Para Almeida, uma conversão direta das chamadas de método internas em processo em chamadas RPC para os serviços causará uma comunicação muito intensa e ineficiente, que não terá um bom desempenho em ambientes distribuídos. 

Entre os principais desafios da comunicação entre microsserviços, podemos citar:

Resiliência

Em qualquer microsserviço pode haver dezenas ou até mesmo centenas de instâncias. Uma instância pode falhar por vários motivos. Pode haver uma falha no nível de nó, como uma falha de hardware ou uma reinicialização da VM. Uma instância também pode ficar sobrecarregada com solicitações e, assim, impossibilitada de processar solicitações novas. Qualquer um desses eventos pode fazer com que uma chamada de rede falhe.

Balanceamento de carga

Quando um serviço chama outro serviço, a solicitação deve alcançar uma instância em execução. No Kubernetes, o tipo de recurso Service fornece um endereço IP estável para um grupo de pods. O tráfego de rede para o endereço IP do serviço é encaminhado para um pod por meio de regras de iptable. Por padrão, um pod aleatório é escolhido. 

Rastreamento distribuído

Uma única transação pode abranger vários serviços. Isso pode dificultar o monitoramento do desempenho geral e da integridade do sistema. Mesmo que cada serviço gere logs e métricas, sem alguma forma associá-los, eles serão de utilidade limitada. 

Versão do serviço

Quando uma equipe implanta uma nova versão de um serviço, deve-se evitar a interrupção de qualquer outro serviço ou cliente externo que dependa dele. Além disso, se o objetivo é executar várias versões de um serviço lado a lado e rotear solicitações para uma versão específica, isso pode se tornar um problema.

Criptografia de TLS e autenticação de TLS mútua

Por motivos de segurança, não criptografar o tráfego entre os serviços com TLS e usar a autenticação de TLS mútua para autenticar os autores de chamadas pode se tornar um obstáculo decorrente da comunicação entre microsserviços.

Ao que tudo indica, o mercado caminha para uma prevalência dos microsserviços, mesmo diante dos desafios. No entanto, para casos de uso, há soluções possíveis para superá-los.

Veja: Como ter sucesso com microsserviços?

Possíveis soluções para comunicação entre microsserviços

Conforme mencionado, um ponto importante ao criar um aplicativo baseado em microsserviços é a maneira de integrar, ou seja, fazer a comunicação entre os microsserviços. 

O ideal é tentar minimizar a comunicação entre os microsserviços internos. Quanto menos comunicações entre os microsserviços, melhor. 

Mas, em muitos casos, integrar os microsserviços de alguma forma será necessário. Quando isso acontecer, a regra crítica será que a comunicação entre os microsserviços deve ser assíncrona. 

Isso não significa que você precisa usar um protocolo específico (por exemplo, um sistema de mensagens assíncrono em vez de HTTP síncrono), mas que a comunicação entre os microsserviços deve ser feita somente pela propagação de dados de forma assíncrona. 

Nesse caso, não depender de outros microsserviços internos como parte da operação inicial de solicitação/resposta HTTP do serviço. Se possível, nunca dependa da comunicação síncrona entre vários microsserviços, nem mesmo para consultas. 

A natureza de cada microsserviço é ser autônomo e estar disponível para o usuário, mesmo se outros serviços que façam parte do aplicativo de ponta a ponta estiverem inativos ou não íntegros. 

Se há a necessidade de fazer uma chamada de um microsserviço para outros microsserviços (como executar uma solicitação HTTP para uma consulta de dados) para poder fornecer uma resposta a um aplicativo, você tem uma arquitetura que não será resiliente quando alguns microsserviços falharem.

Além disso, as dependências de HTTP entre os microsserviços, como ao criar longos ciclos de solicitação/resposta com cadeias de solicitação HTTP, não permitem que os microsserviços sejam autônomos e também afetam o desempenho dos microsserviços quando um dos serviços nessa cadeia não é executado corretamente.

Quanto mais você adicionar dependências síncronas entre os microsserviços, como solicitações de consulta, pior será o tempo de resposta geral para os aplicativos clientes.

Entenda: Kubernetes vs. Docker: qual a relação entre os dois?

Erros em comunicação entre microsserviços

Um dos maiores erros cometidos por quem realiza a implementação de microsserviços é considerar que a conexão é estável e confiável. Por razões variadas, a comunicação entre microsserviços pode falhar, tanto ao enviar uma requisição quanto ao trazer uma resposta.

Por isso, em relação ao microsserviço que está fazendo uma requisição (cliente) é fundamental implementar estratégias de proteção ao servidor e estratégias de repetição de requisição.

Já em relação ao microsserviço que está atendendo uma requisição (servidor) é indispensável garantir que todas as requisições sejam independentes. Em cenários onde isso não for absolutamente possível, é fundamental garantir que o servidor não seja comprometido.

Confira: Quando você precisa usar microsserviços?

Que tipo de comunicação entre microsserviços escolher?

Existem vários protocolos e opções que podem ser usados para comunicação entre microsserviços, dependendo do tipo de comunicação que se deseja usar. 

Se estiver usando um mecanismo de comunicação baseado em solicitação/resposta síncrona, protocolos como HTTP e REST serão os mais comuns, principalmente se estiver publicando serviços fora do host do Docker ou do cluster de microsserviços. 

No entanto, se estiver acontecendo a comunicação entre serviços internamente (no host do Docker ou no cluster de microsserviços), também será possível usar os mecanismos de comunicação de formato binário (como o WCF usando TCP e o formato binário). Como alternativa, há a possibilidade de usar mecanismos de comunicação assíncrona baseada em mensagem, como o AMQP.

Também há vários formatos de mensagem, como JSON ou XML, ou até mesmo formatos binários, que podem ser mais eficientes. Se o formato binário escolhido não for um padrão, provavelmente, não será uma boa ideia publicar os serviços usando esse formato. 

É possível usar um formato não padrão para a comunicação interna entre os microsserviços. Isso pode ser feito na comunicação entre os microsserviços dentro do host do Docker ou do cluster de microsserviços (por exemplo, orquestradores do Docker) ou para aplicativos cliente do proprietário que se comunicam com os microsserviços.

Almeida afirma que uma outra solução é a comunicação assíncrona baseada em mensagens e de consistência eventual. Este modelo é indicado para quanto é necessário comunicar uma alteração entre diferentes microsserviços.

Este estilo de comunicação funciona com base na troca de mensagens. Quando é necessário enviar uma mensagem, um serviço envia um comando ou uma mensagem e, se o outro serviço precisar responder, ele retornará uma nova mensagem ao cliente. Como essa mensagem poder ser respondida imediatamente ou não – e, então, pode não haver mensagem alguma de retorno -, chamamos este tipo de comunicação de comunicação de consistência eventual.

Lidando com microsserviços

Como vimos, a comunicação pode ser o maior desafio de organizações que estão migrando suas arquiteturas de softwares para microsserviços.

Porém, contar com profissionais experientes em desenvolvimento pode fazer toda a diferença quando o assunto é mitigar erros e encontrar soluções possíveis para essa integração.

Se precisar de um parceiro com expertise em orquestração e comunicação entre microsserviços, a Supero Tecnologia está à disposição.

Com 18 anos no mercado de soluções de TI, sabemos realizar a comunicação entre microsserviços de maneira eficiente, a fim de obter os melhores resultados para o seu negócio.

Entre em contato com um de nossos consultores especializados e entenda como trabalhamos para atender a sua demanda de forma consultiva e personalizada.