1. Arquitetura

Este documento descreve a arquitetura atual que guia a implementação da dojot, detalhando os componentes que compõem a solução, assim como as suas funcionalidades e como cada um deles contribui para a plataforma como um todo.

Aqui é feita uma breve explicação dos componentes, sendo esta descrição em alto nível e sem o objetivo de explicar os detalhes de implementação de cada um deles. Para isso, procure a documentação própria do componente.

_images/arqui_carate_v04.png

Fig. 1.1 A arquitetura de microsserviço da plataforma dojot.

Uma visão geral de toda a arquitetura é mostrada na figura acima e nas seções a seguir são fornecidos mais detalhes sobre cada componente.

1.1. Componentes

A dojot foi projetada para tornar possível uma prototipagem rápida, fornecendo uma plataforma fácil de usar, escalável e robusta. Sua arquitetura interna faz uso de muitos componentes conhecidos de código aberto, e outros projetados e implementados pela equipe dojot.

Usando a dojot: um usuário configura dispositivos de IoT por meio da GUI ou diretamente usando as APIs REST fornecidas pelo API Gateway. Os fluxos de processamento de dados também podem ser configurados - essas entidades podem executar uma variedade de ações, como gerar notificações quando um atributo de dispositivo específico atingir um determinado limite ou salvar todos os dados gerados por um dispositivo em um banco de dados externo. À medida que os dispositivos começam a enviar suas leituras para dojot, um usuário pode:

  • receber essas leituras em tempo real pelos canais socket.io ou websocket;

  • consolidar todos os dados em dispositivos virtuais;

  • reunir todos os dados do banco de dados histórico e assim por diante.

Esses recursos podem ser usados por meio de APIs REST - esses são os blocos de construção básicos que qualquer aplicativo baseado na dojot deve usar. A GUI (interface gráfica), nossa aplicação exemplo, fornece uma maneira fácil de executar operações de gerenciamento para todas as entidades relacionadas à plataforma (usuários, dispositivos, modelos e fluxos) e também pode ser usada para verificar se tudo está funcionando bem.

O contexto do usuário é isolado e não há compartilhamento de dados, as credenciais de acesso são validadas pelo serviço de autorização para cada operação (solicitação da API). Portanto, um usuário pertencente a um contexto específico (tenant) não pode acessar nenhum dado (incluindo dispositivos, modelos, fluxos ou quaisquer outros dados relacionados a esses recursos) de outros.

Depois que os dispositivos são configurados, o IoT Agent é capaz de mapear os dados recebidos dos dispositivos, encapsulados no MQTT, por exemplo, e enviá-los ao broker de mensagens para distribuição interna. Dessa forma, os dados chegam ao serviço de persistência, por exemplo, para que possam persistir os dados em um banco de dados.

Para maiores informações sobre o que acontece na dojot, você pode conferir os repositórios GitHub do projeto <https://github.com/dojot>. Lá você encontrará todos os componentes utilizados pela plataforma.

Cada um dos componentes que compõem a arquitetura é brevemente descrito nas sessões subsequentes.

1.1.1. Kafka + DataBroker

O Apache Kafka é uma plataforma distribuída de mensageria que pode ser utilizada por aplicações que precisam transmitir dados ou consumir/produzir em canais de dados. Em comparação com outras soluções de mensagens de código aberto, o Kafka parece ser mais apropriado para cumprir os requisitos de arquitetura da dojot (isolamento de responsabilidade, simplicidade e assim por diante).

No Kafka, utiliza-se uma estrutura de tópicos especializada para garantir isolamento de dados de usuários e aplicações, viabilizando uma arquitetura multi-tenant.

O serviço DataBroker utiliza um banco de dados na memória para obter eficiência. Ele adiciona contexto ao Apache Kafka, possibilitando que serviços internos ou externos possam consumir dados em tempo-real com base no contexto. O DataBroker também pode ser um serviço distribuído para evitar que seja um ponto único de falha ou mesmo um gargalo para a arquitetura.

1.1.2. DeviceManager

O DeviceManager é uma entidade central responsável por manter as estruturas de dados de dispositivos e modelos (templates). Também é responsável por publicar quaisquer atualizações para todos os componentes interessados através do Kafka.

O serviço não mantém estados e tem seus dados persistidos em banco de dados, onde suporta isolamento de dados por tenants e aplicações, viabilizando uma arquitetura de middleware com multi-tenancy.

1.1.3. Agente IoT

Um agente IoT é um serviço de adaptação entre dispositivos físicos e componentes principais da dojot. Pode ser entendido como um driver de dispositivo para um conjunto de dispositivos. A plataforma dojot pode ter vários agentes IoT, cada um deles especializado em um protocolo específico, como, por exemplo, MQTT/JSON, CoAP/LWM2M, Lora/ATC, Sigfox/WDN e HTTP/JSON.

A comunicação por meio de canais seguros com dispositivos também é responsabilidade dos agentes IoT.

1.1.4. Serviço de Autorização de Usuários

Serviço que implementa o gerenciamento de perfil de usuários e controle de acesso. Basicamente qualquer chamada de aplicação através do API Gateway é validada por este serviço.

Para ser capaz de atender a um grande volume de chamadas de autorização, faz uso de cache, não mantém estados e pode ser escalado horizontalmente. Seus dados são mantidos em banco de dados clusterizável.

1.1.5. Flowbroker (Construtor de fluxo)

Esse serviço provê mecanismos para construir fluxos de processamento de dados para execução de um conjunto de ações. Os fluxos podem ser estendidos usando um bloco de processamento externo (que pode ser incluído utilizando APIs REST).

1.1.6. Data Manager

Este serviço gerencia a configuração de dados da dojot, possibilitando importar e exportar configurações.

1.1.7. Cron

Cron é um microsserviço da dojot que permite agendar eventos a serem emitidos - ou requisições a serem feitas - para outros microsserviços dentro da plataforma dojot.

1.1.8. Kafka2Ftp

O serviço kafka2ftp permite o encaminhamento de mensagens do Apache Kafka para servidores FTP. Ele se inscreve no tópico tenant.dojot.ftp do Kafka, onde as mensagens devem seguir um esquema específico. As mensagens podem ser redirecionadas para esses tópicos usando um nó específico do flowbroker.

1.1.9. Persister/History

O componente Persister funciona como um condutor de dados e eventos que devem ser persistidos em um banco de dados. Os dados são convertidos em uma estrutura de armazenamento que é enviada para o banco de dados correspondente.

Para armazenamento interno, utiliza-se uma base de dados não-relacional MongoDB que pode ser configurada em modo Sharded Cluster dependendo do caso de uso.

Os dados persistentes podem ser consultados por meio de uma API Rest fornecida pelo microsserviço history.

1.1.10. InfluxDB Storer e Retriever

Os serviços InfluxDB Storer e InfluxDB Retriever trabalham juntos, o InfluxDB Storer é responsável por consumir dados Kafka de dispositivos dojot e gravá-los no InfluxDB, enquanto o InfluxDB Retriever tem a função de obter os dados que foram escritos pelo InfluxDB Storer no InfluxDB via API REST .

1.1.11. Kong API Gateway

O Kong API Gateway é utilizado como um ponto de fronteira (entry point) entre as aplicações e serviços externos e os serviços internos da dojot. Isso resulta em inúmeras vantagens como, por exemplo, ponto único de acesso e facilidade na aplicação de regras sobre as chamadas de APIs como limitação de tráfego e controle de acesso.

1.1.12. GUI

A Interface Gráfica de Usuário (GUI) na dojot é uma aplicação WEB que provê interfaces responsivas para gerenciamento da plataforma, incluindo funcionalidades como:

  • Gerenciamento de perfil de usuários: permite definir perfis e quais APIs podem ou não ser acessadas pelo respectivo perfil

  • Gerenciamento de usuários: permite operações de criação, visualização, edição e remoção

  • Gerenciamento de modelos de dispositivos: operações de criação, visualização, edição e remoção

  • Gerenciamento de dispositivos: operações de criação, visualização (dispositivo e dados em tempo real), edição e remoção

  • Gerenciamento de fluxos de processamento: permite operações de criação, visualização, edição e remoção de fluxos de processamento de dados

  • Notificações: visualiza as notificações do sistema (em tempo real e histórico unificados)

1.1.13. Image manager

Este componente é responsável pelo armazenamento e recuperação de imagens de firmware de dispositivos. Ele é utilizado pelo mecanismo de atualização de firmware.

1.1.14. X.509 Identity Management

Este componente é responsável por atribuir identidades a dispositivos, tais identidades são representadas na forma de certificados x.509. Ele se comporta semelhante a uma Autoridade Certificadora (CA), onde é possível submeter um CSR e receber um certificado de volta. Tendo o certificado sido instalado no dispositivo, é possível se comunicar de forma segura com a plataforma dojot, pois os dados coletados pelo dispositivo são trafegados por um canal seguro (criptografado) e também é possível garantir a integridade dos dados.

1.1.15. Kafka WS

Este componente é responsável por obter dados do Apache Kafka via uma conexão Websocket pura. Foi desenhado para permitir que usuários da dojot possam recuperar dados brutos e/ou processados em tempo real de dispositivos da dojot.

1.2. Infraestrutura

Alguns outros componentes são utilizados na dojot, são eles:

  • postgres: esse banco de dados é utilizado para persistir informações de vários componentes, como do gerenciador de dispositivos.

  • redis: é um banco de dados em memória usado como cache em vários componentes, como o serviço de orquestração, gerenciador de subscrição, agentes IoT e outros. É bem leve e fácil de usar.

  • rabbitMQ: broker de mensagens usado no orquestrador de serviço para implementar fluxos de ação relacionados que devem ser aplicados a mensagens recebidas de componentes.

  • mongo: solução de banco de dados amplamente utilizada, fácil de usar e não adiciona overhead considerável (nos locais onde foi empregado na dojot).

  • zookeeper: mantém sob controle serviços replicados em cluster.

1.3. Comunicação

Todos os componentes se comunicam de duas maneiras:

  • Por meio de requisições HTTP: se um componente necessita recuperar dados de outro, como um agente IoT que precisa a lista de dispositivos configurados do gerenciador de dispositivos, ele pode enviar uma requisição HTTP para o componente apropriado.

  • Por meio de mensagens Kafka: se um componente precisa enviar novas informações sobre um recurso controlado por ele (como novos dispositivos criados no gerenciador de dispositivos), o componente pode publicar esses dados através do Kafka. Utilizando esse mecanismo, qualquer outro componente que esteja interessado em tal informação precisa apenas ouvir um tópico específico para recebê-la. Note que este mecanismo não faz quaisquer associações fixas entre componentes. Por exemplo, o gerenciador de dispositivos não sabe quais componentes precisam de suas informações e um agente IoT não necessita saber qual componente está enviando dados através de um tópico específico.