Editar

Compartilhar via


Roteamento de eventos de IoT

IoT do Azure
Hub IoT do Azure

Em uma solução de IoT (Internet das Coisas), os dispositivos de IoT enviam eventos (notificações, reconhecimentos, telemetria) para o aplicativo para obter insights. Os aplicativos podem exigir subconjuntos específicos de eventos para processamento ou armazenamento em diferentes pontos de extremidade. Esses eventos também podem precisar ser roteados para serviços diferentes para processamento adicional. À medida que a solução de IoT é escalada horizontalmente, o número de dispositivos, o volume de eventos, a variedade de eventos e os diferentes serviços também variam. Um método flexível, escalonável, consistente e confiável para rotear eventos é necessário para atender a esse padrão.

Possíveis casos de uso

Uma loja de varejo está monitorando os refrigeradores da seção de alimentos congelados:

  • Um alerta é enviado quando a temperatura dos refrigeradores ultrapassa um limite predeterminado. Uma regra de roteamento pode ser criada com a regra de limite para enviar esses eventos específicos para um sistema de alerta.
  • A equipe de ciência de dados está criando um modelo de detecção de anomalias para identificar problemas com os refrigeradores antes que qualquer um deles pare de funcionar. Uma regra de roteamento de mensagens pode enviar todos os dados telemétricos brutos para uma conta de armazenamento especificamente para a equipe de ciência de dados usar para treinamento e modelagem.

Este cenário se aplica aos setores de varejo, energia e meio ambiente.

Arquitetura

Architecture diagram illustrating use of rules to route events to different Azure services.

Baixe um Arquivo Visio dessa arquitetura.

Em uma plataforma de IoT, regras podem ser criadas para roteamento refinado de eventos. Uma ou mais regras podem ser configuradas na plataforma de IoT. As regras serão aplicadas aos eventos de entrada e roteadas para os pontos de extremidade específicos.

Características

Aqui estão algumas considerações ao usar esse padrão.

  • Taxa de transferência dos pontos de extremidade: os pontos de extremidade que recebem eventos devem ser capazes de lidar com a entrada de eventos enviados por roteamento. Certifique-se de que os serviços de ponto de extremidade tenham a capacidade de ingerir e armazenar os dados até que eles sejam consumidos.

  • Formato dos eventos: para que o roteamento seja escalonável e flexível, os eventos devem ter um formato comum para garantir a interoperabilidade entre protocolos.

  • Manipulação de eventos: se um evento corresponder a várias rotas que apontam para o mesmo ponto de extremidade, ele deverá entregar a esse ponto de extremidade apenas uma vez. Também é importante garantir a ordenação das mensagens nessas situações.

  • Duplicação de eventos: para lidar com a duplicação de mensagens, é recomendável carimbar um identificador exclusivo nas propriedades do aplicativo da mensagem no ponto de origem, que geralmente é um dispositivo ou um módulo. O serviço que consome as mensagens pode, então, lidar com mensagens duplicadas usando esse identificador.

  • Rota de fallback: eventos que não correspondem a nenhuma regra devem chegar a uma rota de fallback para que possam ser resolvidos adequadamente e nenhum evento seja perdido.

  • Eventos não relacionados a telemetria: as soluções de IoT têm diferentes tipos de eventos, como alterações de estado do dispositivo e eventos de ciclo de vida do dispositivo. A rota de eventos deve ser capaz de capturar e aplicar regras a tais eventos não relacionados a telemetria para habilitar a automação e o monitoramento.

Quando usar esse padrão:

  • Ao enviar mensagens de telemetria do dispositivo, eventos de ciclo de vida do dispositivo ou eventos de alteração do dispositivo gêmeo para pontos de extremidade específicos determinados pelas regras.

  • Ao filtrar eventos aplicando regras específicas.

Esse padrão não é recomendado para:

  • Roteamento baseado em análise de dados complexa em tempo real dos dados de série temporal. Por exemplo, ao comparar os dados de telemetria médios de 15 minutos. Se a análise de dados em tempo real for necessária, use um serviço de análise em tempo real para os dados de caminho crítico.

Próximas etapas