Uma arquitetura condicionada por eventos é constituída por produtores de eventos que geram um fluxo de eventos e por consumidores de eventos que escutam a existência de eventos.
Os eventos são entregues quase em tempo real, pelo que os consumidores podem responder imediatamente aos eventos à medida que estes ocorrem. Os produtores estão dissociados dos consumidores – um produtor não sabe quais os consumidores que estão a ouvir. Os consumidores também estão desassociados uns dos outros e cada consumidor vê todos os eventos. Isto difere de um padrão Consumidores Concorrentes, no qual os consumidores extraem as mensagens de uma fila e uma mensagem é processada apenas uma vez (partindo do princípio de que não existem erros). Em alguns sistemas, como IoT, os eventos têm de ser ingeridos em volumes muito elevados.
Uma arquitetura orientada a eventos pode usar um modelo de publicação/assinatura (também chamado de pub/sub) ou um modelo de fluxo de eventos.
Publicação/subscrição: a infraestrutura de mensagens mantém um registo das subscrições. Quando um evento é publicado, envia o evento para cada subscritor. Depois que um evento é recebido, ele não pode ser repetido e os novos assinantes não veem o evento.
Transmissão em fluxo de eventos: os eventos são escritos num registo. Os eventos estão criteriosamente ordenados (dentro de uma partição) e são duráveis. Os clientes não subscrevem o fluxo, em vez disso, um cliente pode ler a partir de qualquer ponto do fluxo. O cliente é responsável pela progressão da respetiva posição no fluxo. Isto significa que um cliente não só pode efetuar a adesão em qualquer altura como pode reproduzir eventos.
No lado do consumidor, existem algumas variações comuns:
Processamento de eventos simples. Um evento aciona imediatamente uma ação no consumidor. Por exemplo, pode utilizar as Funções do Azure com um acionador do Service Bus, de modo a que uma função seja executada sempre que é publicada uma mensagem num tópico do Service Bus.
Correlação básica de eventos. Um consumidor precisa processar um pequeno número de eventos comerciais discretos, geralmente correlacionados por algum identificador, persistindo algumas informações de eventos anteriores para usar ao processar eventos posteriores. Esse padrão é suportado por bibliotecas como NServiceBus e MassTransit.
Processamento de eventos complexos. Um consumidor processa uma série de eventos, procurando padrões nos dados do evento, usando uma tecnologia como o Azure Stream Analytics. Por exemplo, pode agregar as leituras de um dispositivo incorporado ao longo de um certo período de tempo e gerar uma notificação caso a média móvel ultrapasse um determinado limiar.
Processamento de fluxos de eventos. Utilize uma plataforma de transmissão em fluxo de dados, como o Hub IoT do Azure ou o Apache Kafka, como um pipeline para ingerir eventos e fornecê-los aos processadores de fluxos. Os processadores de fluxos entram em ação para processar ou transformar o fluxo. Podem existir vários processadores de fluxos para diferentes subsistemas da aplicação. Esta abordagem é uma boa opção para as cargas de trabalho de IoT.
A origem dos eventos pode ser externa ao sistema como, por exemplo, dispositivos físicos numa solução de IoT. Nesse caso, o sistema tem de ser capaz de ingerir os dados com o volume e o débito de que a origem de dados precisa.
No diagrama lógico acima, cada tipo de consumidor é mostrado como uma única caixa. Na prática, é comum ter várias instâncias de um consumidor, para evitar que o consumidor se transforme num ponto de falha único no sistema. Também poderão ser necessárias várias instâncias para processar o volume e a frequência dos eventos. Além disso, um único consumidor pode processar eventos de vários threads. Isso pode criar desafios se os eventos precisarem ser processados em ordem ou exigirem semântica exata uma vez. Veja Minimizar a Coordenação.
Quando utilizar esta arquitetura
- Vários subsistemas têm de processar os mesmos eventos.
- Processamento em tempo real com um hiato de tempo mínimo.
- Processamento de eventos complexos, como a agregação ou correspondência de padrões ao longo de períodos de tempo.
- Volume e velocidade de dados elevados, como IoT.
Benefícios
- Os produtores e os consumidores estão desassociados.
- Sem integrações ponto-a-ponto. É fácil adicionar novos consumidores ao sistema.
- Os consumidores podem responder de imediato aos eventos, à medida que estes são recebidos.
- Altamente dimensionável e distribuída.
- Os subsistemas têm vistas independentes do fluxo de eventos.
Desafios
- Entrega garantida. Em alguns sistemas, especialmente em cenários de IoT, é fundamental garantir que os eventos são entregues.
- Processamento de eventos por uma ordem ou exatamente uma vez. Normalmente, cada tipo de consumidor é executado em várias instâncias, por uma questão de resiliência e escalabilidade. Isso pode criar um desafio se os eventos tiverem de ser processados em ordem (dentro de um tipo de consumidor) ou se a lógica de processamento de mensagens idempotente não for implementada.
- Coordenação de mensagens entre serviços. Os processos de negócios geralmente envolvem vários serviços, publicação e assinatura de mensagens para alcançar um resultado consistente em toda uma carga de trabalho. Padrões de fluxo de trabalho, como o padrão Coreográfico e a Orquestração Saga, podem ser usados para gerenciar de forma confiável os fluxos de mensagens em vários serviços.
Considerações adicionais
- A quantidade de dados a serem incluídos em um evento pode ser uma consideração significativa que afeta o desempenho e o custo. Colocar todas as informações relevantes necessárias para o processamento no próprio evento pode simplificar o código de processamento e salvar pesquisas adicionais. Colocar a quantidade mínima de informações em um evento, como apenas alguns identificadores, reduzirá o tempo e o custo de transporte, mas exige que o código de processamento procure qualquer informação adicional necessária. Para obter mais informações sobre isso, dê uma olhada nesta postagem do blog.
- Embora uma solicitação só seja visível para o componente de tratamento de solicitações, os eventos geralmente são visíveis para vários componentes em uma carga de trabalho, mesmo que esses componentes não os consumam ou não se destinem a consumi-los. Operando com uma mentalidade de "assumir violação", esteja atento às informações que você inclui em eventos para evitar a exposição não intencional de informações.
Recursos relacionados
- Vídeo de discussão da comunidade sobre as considerações de escolher entre coreografia e orquestração.