Um erro imperdoável, na implementação de microsserviços é considerar que a conexão é estável e confiável. Por razões variadas, a rede pode falhar tanto ao enviar uma requisição quanto ao trazer uma resposta.
No lado cliente (microsserviço que está fazendo uma requisição) é fundamental implementar:
- estratégias de proteção ao servidor, como a implementação do padrão Circuit Breaker
- estretégias de repetição de requisição, como a implementação do padrão Retry
No lado servidor (microsserviço que está atendendo uma requisição) é indispensável garantir que todas as requisições sejam idempotentes. Em cenários onde isso não for absolutamente possível, é fundamental garantir que o “estado” do servidor não seja comprometido.
Se tiver interesse em entender mais sobre microsserviços, recomendo que acesse o Guia de Conteúdo para Microsserviços deste site.
O problema com POST
O verbo POST é, por definição, não idempotente.
Considere o seguinte cenário:
MOMENTO 1 – Uma aplicação cliente chama um microsserviço para realizar a inclusão de uma informação. Esta chamada está disponível através de uma operação POST.
MOMENTO 2 – A aplicação servidor recebe a requisição e executa o processamento de forma adequada. Entretanto, a mensagem de resposta acaba se perdendo na rede e, por alguma razão, não chega a aplicação cliente.
MOMENTO 3 – Depois de algum tempo a aplicação cliente identifica um time-out. E, por definição, faz uma nova tentativa de inclusão de informação.
MOMENTO 4 – A aplicação servidor recebe a nova requisição e, inadvertidamente, inclui a mesma informação, uma segunda vez, na base.
Assustador, não acha? Esse é um caso extremamente difícil de detectar e raramente é “pego” em testes de QA.
Uma possível solução
De forma radical, o cenário acima me faz evitar utilizar o verbo post em minhas aplicações. Acabo utilizando um “PUT identificado” (essa solução, aliás vem sendo bastante aplicada estando presente, inclusive em uma aplicação de referência da Microsoft).
[HttpPut]
[ProducesResponseType(typeof(string), (int) HttpStatusCode.OK)]
[ProducesResponseType((int)HttpStatusCode.BadRequest)]
public async Task GetEcho(
[FromBody] EchoCommand command,
[FromHeader(Name = "x-requestid")] string requestId
)
{
if (!Guid.TryParse(requestId, out var guid))
{
return BadRequest();
}
var identifiedCommand = new IdentifiedCommand<EchoCommand, string>(
command,
guid
);
return Ok(await _mediator.Send(identifiedCommand));
}
O caminho que venho adotando é pedir, em operações que mudam o estado do servidor, um identificador da requisição. Este identificador é então ligado ao comando.
A aplicação cliente precisará adicionar um header para identificar a requisição.
Um handler global para comandos identificados checa se o identificador está associado a um comando já executado. Caso esteja, gera um erro.
public class IdentifiedCommandHandler<TCommand, TResult>
: IRequestHandler<IdentifiedCommand<TCommand, TResult>, TResult>
where TCommand : IRequest
{
private readonly IMediator _mediator;
private readonly IRequestManager _requestManager;
public IdentifiedCommandHandler(IMediator mediator, IRequestManager requestManager)
{
_mediator = mediator;
_requestManager = requestManager;
}
public async Task Handle(
IdentifiedCommand<TCommand, TResult> message,
CancellationToken cancellationToken = default(CancellationToken)
)
{
if (message.Id == Guid.Empty)
{
ThrowMediatrPipelineException.IdentifiedCommandWithoutId();
}
if (message.Command == null)
{
ThrowMediatrPipelineException.IdentifiedCommandWithoutInnerCommand();
}
var alreadyRegistered = await _requestManager.IsRegistered(message.Id, cancellationToken);
if (alreadyRegistered)
{
ThrowMediatrPipelineException.CommandWasAlreadyExecuted();
}
await _requestManager.Register(message.Id, cancellationToken);
var result = await _mediator.Send(message.Command, cancellationToken);
return result;
}
}
Todas as exceptions relacionadas a uma falha por duplicidade são mapeadas adequadamente para um Bad Request.
public class HttpGlobalExceptionFilter : IExceptionFilter
{
private readonly IHostingEnvironment _env;
private readonly ILogger _logger;
public HttpGlobalExceptionFilter(
IHostingEnvironment env,
ILogger logger
)
{
_env = env;
_logger = logger;
}
public void OnException(ExceptionContext context)
{
_logger.LogError(new EventId(context.Exception.HResult),
context.Exception,
context.Exception.Message);
if (context.Exception.GetType() == typeof(MediatrPipelineException))
{
var validationException = context.Exception.InnerException as ValidationException;
if (validationException != null)
{
var json = new JsonErrorResponse
{
Messages = validationException.Errors
.Select(e => e.ErrorMessage)
.ToArray()
};
context.Result = new BadRequestObjectResult(json);
}
context.HttpContext.Response.StatusCode = (int)HttpStatusCode.BadRequest;
}
else
{
var json = new JsonErrorResponse
{
Messages = new[]
{
"Internal Error. Try again later.",
context.Exception.GetType().ToString(),
context.Exception.Message
}
};
context.Result = new ObjectResult(json) { StatusCode = 500 };
context.HttpContext.Response.StatusCode = (int)HttpStatusCode.InternalServerError;
}
context.ExceptionHandled = true;
}
public class JsonErrorResponse
{
public string[] Messages { get; set; }
}
}
Que geram um Bad Request para o cliente.
Concluindo
A solução perfeita entregaria idempotência. Mas, para isso, eu precisaria armazenar a resposta do servidor e isso poderia conduzir a erros de interpretação. Aqui, opto por deixar claro o que houve de errado.
Mais uma vez, é importante ressaltar que, implementando microsserviços, é fundamental estar preparado para instabilidades de conexão. A questão não é se ocorrerá uma falha, mas quando essa falha irá ocorrer.
O código fonte desse exemplo está disponível no github.
Créditos da imagem da capa para Park Troopers
