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.