Esse texto visa reunir informações sobre eventos e arquitetura de software orientada a eles. O café é apenas para beber enquanto ler isso.
Como de costume, vou direto ao ponto.
O que são eventos?
Eventos podem ser entendidos como sendo gatilhos disparados internamente numa aplicação devido a alguma alteração no estado de alguma entidade.
Essa entidade pode ter sido criada, alterada, deletada etc. Se liga nesse exemplo:
“Quando receber meu salário, vou à praia.”
Qual é o evento aqui?
Se perguntarem para qualquer pessoa o evento é a ida a tal praia. Mas se perguntarem para algum dev ele dirá que o evento é o recebimento do salário.
Trazendo para um tipo de negócio existente e muito utilizado pela maioria das pessoas: compras online.
Imagine que o evento “pagamento aprovado” foi lançado, por causa desse evento outras ações poderão ser executadas. Exemplos: separar mercadoria no estoque, gerar nota fiscal e atualizar status do pedido.
A principal tarefa aqui é informar a todo o sistema, que é composto por n micro serviços, que um determinado evento aconteceu para que outras ações possam ser executadas em reação a isso.
Drake, até aqui ok?
Então dale.
Já que o conceito de evento está definido, é hora de pensar em uma arquitetura orientada a eventos.
Arquitetura orientada a eventos
“A arquitetura orientada a eventos é um modelo de arquitetura de software para o design de aplicações. Em um sistema orientado a eventos, os componentes de captura, comunicação, processamento e persistência de eventos formam a estrutura básica da solução. Isso é diferente do modelo tradicional orientado a solicitações.” [trecho retirado do site da Red Hat, link]
Esse tipo de arquitetura possui algumas vantagens, por exemplo:
- Baixo acoplamento entre os componentes de um sistema, isso ocorre porque o produtor de um evento não se importa com quem está esperando esse evento.
- Pode ser usada em qualquer linguagem de programação;
- Maior resistência a quebras. Como cada componente tem tudo que precisa para o seu funcionamento, pode continuar funcionando mesmo que a comunicação com o mundo externo seja perdida;
- Novos serviços podem ser adicionados a solução sem a necessidade que os serviços já existentes os conheçam, basta que os novos serviços conheçam os eventos que estão sento transmitidos.
Num contexto onde existem n micro serviços, podemos ter um desenho parecido com esse:
Se trata de um rascunho que não detalha muita coisa sobre como a produção e a recepção desses eventos funcionaria na prática.
O ideal para essa arquitetura seria que um middleware fosse usado e neste exemplo vou usar o kafka.
Esse desenho muda um pouco quando coloco um middleware, dá pra ver como o acoplamento ficou baixo, além de perceber que é possível colocar novos sistemas na solução com baixo impacto devido a essa característica, se liga:
Coisas interessantes:
- Esse não é um fluxo completo, apenas parte dele. Mas já pode dar uma ideia legal do tema;
- Caso surja a necessidade de executar algo além do processo antifraude, basta criar o micro serviço e escutar os eventos. Não é necessário fazer nada no serviço que cria os eventos de compras efetuadas;
- O acoplamento entre os serviços é baixíssimo, uma das poucas coisas que gera manutenção em mais de um serviço de uma vez é o formato da mensagem que representa o evento criado;
- Caso a idempotência seja bem utilizada, não deve haver riscos de duplicidade pois os consumidores de eventos estarão preparados para lidar com eventuais duplicações;
Problemas que podem acontecer:
- Duplicidade no processamento de eventos. Imagine cobrar duas vezes o mesmo cliente? A idempotência nos auxilia muito nisso.
- Cascata de eventos (mais fácil procurar por Event Cascade no Google). Ocorre quando uma sequência de eventos aciona outros eventos, formando uma conexão que pode ser representada de uma forma simples: Evento A → gera o evento B → gera o evento C → gera o evento D. É ok entender que um evento pode ser consequência do outro, mas imagine que algum programador está trabalhando apenas no consumo do evento C, o grande problema aqui é que ele deve se preocupar com a geração do evento A e isso é ruim, pois pode gerar um comportamento imprevisto. O ideal é garantir que o serviço seja independente, só altere uma entidade quando tiver que reagir a publicação de algum evento relacionado a essa entidade;
Pontos a serem evitados:
- Evitar ao máximo o uso de eventos genéricos. Estamos tratando de entidades que devem ter significado bem definido em um contexto de negócio. Colocar como responsabilidade do consumidor interpretar o tipo pode gerar muita dor de cabeça no futuro;
- Esperar resposta de um consumidor;
- Deixar de usar headers. Os headers carregam informações preciosas para o processamento de eventos como o tipo de evento, id, id de correlação, timestamp etc;
- Esquecer de implementar idempotência;
Existem outros pontos, mas agora só me lembro destes.
É isso.
Flw. Vlw.
