O que é o evento e qual a velocidade do tempo real?
Se pensarmos nisso, podemos identificar muitos cenários orientados por eventos. Muitos deles exigem uma reação em tempo real.
O que queremos dizer com tempo real?
Uma reação em tempo real pode ser vista como uma resposta imediata. Vamos dar um exemplo de um caixa de um café que pergunta o que você quer beber.
O caixa espera uma resposta imediata, ou pelo menos uma resposta que seja dada muito em breve. Caso contrário, o caixa pode reformular a pergunta ou suspeitar que você foi rude. Solicita-se uma resposta rápida e também adequada. O tempo para responder pode variar um pouco, mas ainda é visto como sendo "em tempo real". Assim, devolver uma saudação deve acontecer rapidamente, mas não há problema em pensar brevemente no seu pedido para responder à pergunta do caixa.
Se você traduzir esse cenário para sistemas de software, tudo o que lhe importa são os tempos: Tempo de resposta, Tempo de conclusão, Tempo de acesso, Tempos de inicialização e assim por diante. O usuário ou o aplicativo de acesso define esses horários.
Nota
Em tempo real, as tarefas dos sistemas desempenham a sua função dentro dos prazos prescritos.
Você deve estar sempre ciente do que está acontecendo em seu sistema. Portanto, certifique-se de não esquecer o óbvio, que é o registro, monitoramento e medição de seus horários.
Importante
Certifique-se de especificar os prazos e horários com antecedência e configurar uma solução de monitoramento sem bloqueio para check-up.
Em resumo, concordamos que tempo real significa super-rápido, num instante. Quão rápido exatamente é especificado pelo seu determinado cenário.
Aplicações condicionadas por eventos
Se você pensa em um evento de clique, você pensa em outra coisa. As aplicações orientadas para eventos utilizam o princípio do fogo e do esquecimento . O evento é enviado ou disparado para o próximo sistema, que pode ser outro serviço, um hub de eventos, um fluxo ou um agente de mensagens como Kafka. Não esperamos necessariamente por uma resposta do próximo no sistema. O acoplamento frouxo é conseguido pelo preço de uma eventual consistência, que precisa ser cuidada em outro nível.
Para identificar a natureza dos aplicativos orientados a eventos, vamos examinar os principais padrões de arquitetura usando o exemplo de um cliente, chamado Alex, comprando um café e um cappuccino.
Notificação de eventos
A notificação de evento é a notificação de um acontecimento ou evento específico. Cada evento é visto separadamente. O exemplo de um cliente chamado Alex comprando um café e um cappuccino pode ser assim:
1. Evento: Alex compra um café.
2. Evento: Alex compra um cappuccino.
Um barista teria que ouvir atentamente todos os eventos para obter toda a ordem de Alex. Mas dois baristas também podiam preparar e servir as bebidas de forma independente.
Transferência de estado transportada por evento
Com a transferência de estado realizada pelo evento, todas as informações necessárias são armazenadas em um único evento. Isso é útil se um evento se perder ou se o seu serviço não estiver ouvindo todos os eventos. Para o nosso exemplo, os eventos seriam assim:
1. Evento: Alex compra um café.
2. Evento: Alex compra, além do café, um cappuccino.
Com um barista, ouvir apenas o segundo evento pode ser suficiente. Com dois baristas, o segundo teria que olhar para o primeiro. A encomenda poderia ser notificada em conjunto, mas o processo poderia demorar mais tempo do que fazê-lo completamente dissociado.
Origem dos eventos
Com o fornecimento de eventos, o armazenamento de eventos entra em foco. Como você pode ver, os eventos são os mesmos do primeiro exemplo. Mas o barista é importante para este conceito no momento em que o barista recebe um evento e depois pensa em todos os eventos correspondentes para obter o estado atual para todos os pedidos feitos por Alex.
Com o segundo pedido, o barista sabe que o pedido de Alex consiste em um café, lembrando o primeiro pedido, e um cappuccino, porque esta bebida foi apenas pedida. Trabalhar em paralelo com um segundo barista não é tão fácil.
Quando adicionamos um caixa para receber os pedidos e servir as bebidas, os baristas podem trabalhar de forma independente para preparar as bebidas. Eles não precisam saber nada sobre os clientes. O caixa é a chamada loja de eventos, persistindo os eventos, nesse cenário. O fornecimento de eventos adiciona outra camada de complexidade, mas também adiciona dissociação.
1. Evento: Alex compra um café.
Caixa: (Primeira) encomenda (para Alex): Café
2. Evento: Alex compra um cappuccino.
Caixa: (Segunda) ordem (para Alex): Cappuccino
Os dados de telemetria são eventos em tempo real
Há também outros exemplos em que podemos pensar. Imagine o cenário de executar um sistema de refrigeração, por exemplo, para fabricantes de alimentos ou medicamentos. Você precisa de controle constante da temperatura e outros dados relevantes em seu sistema. Conhecer os dados de telemetria e controlá-los automaticamente seria fundamental para o seu sucesso. Medir a telemetria a cada dois segundos e, em seguida, enviá-la para o sistema de controle onde os dados são analisados, processados e manipulados é um sistema controlado por eventos. Além disso, os dados devem ser processados em tempo real, pois é fundamental reagir rapidamente para evitar consequências trágicas para o negócio.