BT

Armadilhas comuns na integração entre microservices: Bernd Rücker na QCon London

| por Jan Stenberg Seguir 34 Seguidores , traduzido por Diogo Carleto Seguir 40 Seguidores em 23 abr 2018. Tempo estimado de leitura: 4 minutos |

Em uma arquitetura voltada para microservices, cada microservice é uma aplicação separada, com seu próprio banco de dados e comunicação através da rede. Isto cria um ambiente altamente distribuído, e com isso vem alguns desafios. Bernd Rücker explicou em sua apresentação no QCon London 2018, explorando armadilhas comuns na integração entre microservices e soluções que incluem workflow engines, incorporado ou disponível como um serviço.

Comunicação

A comunicação é complexa, e está complexidade não deve ser escondida, pelo contrário, um serviço deve ser projetado para lidar com falhas internamente. Rücker, co-fundador do Camunda, usa um exemplo de sua própria experiência na qual ele tenta realizar o check-in para um voo e espera um cartão de embarque como retorno. Porém o retorno é uma mensagem de erro com informações técnicas sobre o problema solicitando que ele tente realizar a requisição novamente mais tarde. Para ele, este design é ruim e um problema típico no qual o provedor do serviço, ao invés de solicitar uma nova tentativa ao cliente, deveria lidar com o erro e então enviar o cartão de embarque.

O mesmo comportamento pode ser aplicado em uma comunicação entre serviços. Se um serviço pode lidar com falhas internamente, ele deve tentar novamente e retornar de forma assíncrona uma resposta quando estiver disponível. Isto encapsula o tratamento de erros, fazendo com que a API seja mais direta e simples.

Rücker chama isso de stateful retries e em sua experiência uma razão comum para não usar este pattern é a complexidade percebida para manipulação do estado necessária. Frequentemente, o estado é armazenado como uma entidade persistente ou documento, mas um agendador e outros componentes também são necessários para manipular, por exemplo, as requisições. A recomendação é para usar um workflow engine que cuide de todos esses detalhes. Ele diz ainda que mesmo quando novas tentativas devem ser frequentemente utilizadas, pode haver casos de usos em um domínio onde o tratamento de erros deve ser deixado para o cliente.

Comunicação Assíncrona

Para Rücker, existe uma série de vantagens usando comunicação assíncrona, e frequentemente implica no uso de mensagens. Um problema que surge então são os timeouts. Em seu exemplo, aguardando o cartão de embarque, se este processo tivesse sido feito usando mensagens e a mensagem do cartão de embarque nunca tivesse sido criada ou de alguma forma se perdesse, o cliente teria que lidar com a falha. O que é preciso no lado servidor é alguma forma de monitoramento que descobre mensagens perdidas ou atrasadas. Isso é comumente realizado usando um middleware de mensagens, mas Rücker conheceu alguns clientes que implementaram isso usando um workflow engine. Porém isso requer um engine que se comporte como uma fila de mensagens usando o princípio pull.

Transações distribuídas

Em um sistema distribuído, transações ACID não funcionam até que seja configurado o two-phase commits, mas atualmente eles são vistos como muito complicados, e Rücker refere-se a um artigo de Pat Helland, Life Beyond Distributed Transactions: An Apostate's Opinion. Em vez disso, Rücker prefere transações comerciais de longa duração nos casos em que você deve fazer várias atividades em uma semântica de tudo ou nada. Uma solução para isso é o pattern Saga no qual o trabalho é realizado em vários passos, consistência eventual e compensações se algo falha.

Para usar o sagas, cada fornecedor de serviço envolvido deve oferecer atividades de compensação e que também sejam idempotentes. Em uma comunicação em rede existem três cenários de falhas que não é possível diferenciar:

  • A requisição não conseguiu chegar ao servidor;
  • A requisição chegou ao servidor, mas falhou durante o processamento;
  • A requisição foi processada, mas a resposta do fornecedor se perdeu.

Uma solução quando um erro é detectado é perguntar ao fornecedor do serviço sobre a requisição, mas isso significa que é possível distinguí-la de outras requisições. A abordagem comum é repetir a requisição, mas isso significa que deve ser idempotente, e quatro tipos de idempotência são mencionados:

  • Natural, por exemplo, ao definir um estado específico;
  • Negócios, onde você tem um identificador de negócios, como um endereço de e-mail;
  • Unique ID, gerado pelo cliente;
  • Request hash, na qual o serviço reconhece uma requisição através do hash da mensagem.

Rücker observa que um workflow engine incorporado pode implementar o pattern saga, e aponta que em um sistema baseado em microsserviços há geralmente vários mecanismos dentro dos diferentes microsserviços, cada um lidando com diferentes fluxos de trabalho. Ele enfatiza que os engines são incorporados, não existe um engine central para no qual cada workflow deve passar.

Analisando o espaço dos workflow engines e das máquinas de estado, ele observa que existem vários frameworks de código aberto, e que novos frameworks surgiram durante os dois últimos anos. No ambiente serverless, a AWS criou Step Functions e outros fornecedores cloud estão pensando nessa direção.

Rücker publicou código de exemplo implementando suas ideias. Essa apresentação não foi gravada, mas a maioria das apresentações foi, e estarão disponíveis no InfoQ nos próximos meses.

A próxima conferência QCon, QCon.ai, será focado em inteligência artificial e aprendizado de máquina e está agendado para acontecer de 9 à 11 de abril de 2018, em São Francisco. QCon London 2019 está agendado para acontecer entre 4 à 8 de Março de 2019.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT