Publique e assine mensagens MQTT usando o broker MQTT

O broker MQTT possui um broker MQTT de nível empresarial e compatível com os padrões que é escalável, altamente disponível e nativo do Kubernetes. Ele fornece o plano de mensagens para o Azure IoT Operations Preview, permite a comunicação bidirecional de borda/nuvem e alimenta aplicativos orientados a eventos na borda.

Compatível com MQTT

O broker MQTT possui um broker MQTT compatível com padrões que suporta MQTT v3.1.1 e MQTT v5.

O Transporte de Telemetria da Fila de Mensagens (MQTT) surgiu como a língua franca entre os protocolos no espaço IoT. O design simples do MQTT permite que um único corretor atenda dezenas de milhares de clientes simultaneamente, com uma leve criação e gerenciamento de tópicos de publicação-assinatura. Muitos dispositivos IoT suportam MQTT nativamente pronto para uso, com a cauda longa de protocolos IoT sendo racionalizada em MQTT por gateways de tradução downstream.

O broker MQTT usa o protocolo MQTT como base para a camada de mensagens. Para obter mais informações sobre os recursos MQTT suportados, consulte Suporte a recursos MQTT no broker MQTT.

Altamente disponível e dimensionável

O Kubernetes pode dimensionar horizontalmente cargas de trabalho para execução em várias instâncias. Essa redundância significa capacidade adicional para atender solicitações e confiabilidade no caso de qualquer instância cair. O Kubernetes tem a autorrecuperação integrada e as instâncias são recuperadas automaticamente.

Além do Kubernetes ser uma tecnologia de escalonamento elástico, também é um padrão para DevOps. Se MQTT é a língua franca entre os protocolos IoT, o Kubernetes é a língua franca para a camada de infraestrutura de computação. Ao adotar o Kubernetes, você pode usar o mesmo pipeline de CI/CD, ferramentas, monitoramento, empacotamento de aplicativos, qualificação de funcionários em todos os lugares. O resultado é um único sistema de ponta a ponta de computação em nuvem, servidores locais e gateways IoT menores no chão de fábrica. Você pode gastar menos tempo lidando com infraestrutura ou DevOps e se concentrar em seu negócio.

O broker MQTT se concentra no valor exclusivo do plano de dados nativo de borda que ele pode fornecer ao ecossistema do Kubernetes enquanto se encaixa perfeitamente nele. Ele traz um plano de plataforma de mensagens escalável e de alto desempenho criado em torno do MQTT e integração perfeita com outras cargas de trabalho escaláveis do Kubernetes e do Azure.

Seguro por padrão

O corretor MQTT se baseia em conceitos de identidade e segurança nativos do Azure e do Kubernetes testados em batalha, tornando-o altamente seguro e utilizável. Ele suporta vários mecanismos de autenticação para flexibilidade, juntamente com mecanismos granulares de controle de acesso até o nível de tópico MQTT individual.

Integração do Azure Arc

A plataforma híbrida da Microsoft está ancorada em torno do Kubernetes com o Azure Arc como um único plano de controle. Ele fornece um plano de gerenciamento que projeta recursos existentes fora do Azure, locais ou de outra nuvem no Gerenciador de Recursos do Azure. O resultado é um único painel de controle para gerenciar máquinas virtuais, clusters Kubernetes e bancos de dados que não estão em execução nos data centers do Azure.

O agente MQTT é implantado como uma extensão do Azure Arc for Kubernetes e pode ser gerenciado por meio de um provedor de recursos (RP) completo do Azure - microsoft/IoTOperationsMQ. Isso significa que você pode gerenciá-lo da mesma forma que os recursos de nuvem nativos do Azure, como Máquinas Virtuais, Armazenamento, etc.

A tecnologia Azure Arc permite que as alterações entrem em vigor nos serviços de agente MQTT executados no cluster Kubernetes local. Opcionalmente, se você preferir uma abordagem totalmente nativa do Kubernetes, poderá gerenciar o broker MQTT com definições de recursos personalizados (CRDs) do Kubernetes localmente ou usando tecnologias GitOps como o Flux.

Conectores na nuvem

Você pode ter diferentes requisitos de mensagens para seu cenário de nuvem. Por exemplo, um caminho rápido bidirecional na nuvem/borda para dados de alta prioridade ou para alimentar painéis de nuvem quase em tempo real e um caminho lento de baixo custo para dados menos críticos que podem ser atualizados em lotes.

Para fornecer flexibilidade, o agente MQTT fornece conectores do Azure internos para Hubs de Eventos (com ponto de extremidade Kafka), o recurso de agente MQTT da Grade de Eventos, Microsoft Fabric e Armazenamento de Blob. O broker MQTT é extensível para que você possa escolher sua solução preferida de mensagens na nuvem que funcione com sua solução.

Construir sobre o Azure Arc permite que os conectores sejam configurados para usar o Azure Managed Identity para acessar os serviços de nuvem com o poderoso RBAC (Controle de Acesso baseado em Função) do Azure. Não é necessário um gerenciamento de credenciais manual, inseguro e complicado.

Modelo de programação Dapr

O Dapr simplifica o encanamento entre aplicativos distribuídos expondo recursos comuns de aplicativos distribuídos, como gerenciamento de estado, invocação de serviço a serviço e mensagens de publicação-assinatura. Os componentes do Dapr estão abaixo dos blocos de construção e fornecem a implementação concreta para cada capacidade. Você pode se concentrar na lógica de negócios e deixar o Dapr lidar com detalhes de aplicativos distribuídos.

O corretor MQTT fornece blocos de construção conectáveis Dapr publish-subscribe e state store, tornando o desenvolvimento e a implantação de aplicativos orientados a eventos na borda fáceis e agnósticos em relação à tecnologia.

Arquitetura

O broker MQTT tem três camadas:

• Camada front-end sem estado que lida com solicitações de clientes
• Balanceador de carga que roteia solicitações e conecta o broker a outras pessoas
• Camada de back-end fragmentada e com monitoração de estado que armazena e processa dados

A camada de back-end particiona dados por chaves diferentes, como ID do cliente para sessões de cliente e nome do tópico para mensagens de tópico. Ele usa replicação em cadeia para replicar dados dentro de cada partição. Para dados compartilhados por todas as partições, ele usa uma única cadeia que abrange todas as partições.

Os objetivos da arquitetura são:

• Tolerância a falhas e isolamento: A publicação de mensagens continua se os nós back-end falharem e impedir que as falhas se propaguem para o resto do sistema
• Recuperação de falhas: Recuperação automática de falhas sem intervenção do operador
• Sem perda de mensagens: entrega de mensagens se pelo menos um nó front-end e um nó back-end estiverem em execução
• Elastic scaling: dimensionamento horizontal da taxa de transferência de publicação e assinatura para dar suporte a implantações de borda e nuvem
• Desempenho consistente em escala: limite a sobrecarga de latência de mensagens devido à replicação em cadeia
• Simplicidade operacional: dependência mínima de componentes externos para simplificar a manutenção e a complexidade

Próximos passos

Implantar o Azure IoT Operations Preview em um cluster Kubernetes habilitado para Arc