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 implemenação de cada um deles. Para isso, procure a documentação própria do 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 através de notificações geradas por subscrições;
  • 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 em dojot deve usar. A GUI dojot 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 intermediário de mensagens para distribuição interna. Dessa forma, os dados chegam ao serviço de histórico, 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 canais de dados. Em contraste com o Orion, um intermediador de contexto (context broker) utilizado na versão inicial da plataforma, o Kafka parece mais apropriado para assumir os requisitos arquiteturais da dojot (segregação de responsabilidades, 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-inquilino (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 assinar ou consultar dados com base no contexto. O DataBroker também é 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 (agentes IoT, histórico e gerenciador de subscrição) 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 usuários 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 e HTTP / JSON.

O agente IoT também é responsável por garantir que a sua comunicação com dispositivos seja feita por meio de canais seguros.

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

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 do dojot, possibilitando importar e exportar configurações.

1.1.7. Cron

Cron é um microsserviço de um dojot que permite agendar eventos a serem emitidos para outros microsserviços.

1.1.8. History

O componente History funciona como um condutor de dados e eventos que devemser 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 também podem ser armazenados em base de dados externa à plataforma dojot. Para isto, basta configurar o Logstash para enviar os dados para a base correspondente conforme a estrutura de dados desejada.

1.1.9. Serviço de Registro e Auditoria

Todos os serviços que fazem parte da plataforma dojot podem gerar métricas de uso de seus recursos. Tais métricas podem ser utilizadas por serviços de Registro e Auditoria, que processam esses dados sumarizando-os por usuários e aplicativos.

Os dados consolidados são disponibilizados para outros serviços da própria dojot, permitindo-lhes, por exemplo, expor esses dados através de uma interface gráfica aos usuários, para limitar o uso do sistema baseado no consumo de recursos e cotas associadas a usuários. Ainda pode ser usado por serviços externos de faturamento em função da utilização da plataforma por usuários.

Observação: Componentes atualmente em desenvolvimento.

1.1.10. Kong API Gateway

O Kong API Gateway é utilizado como um ponto de fronteira entre as aplicações e serviços externos e os serviços internos do 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.11. 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.12. Image manager

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

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 componenentes, 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 osquestração, gerenciador de subscrição, agentes IoT e outros. É bem leve e fácil de usar.
  • rabbitMQ: intermediador de mensagens utilizado no serviço de orquestração para implementar fluxos de ações relacionados que podem ser aplicados a mensagens recebidas dos componentes.
  • Banco de dados mongo: solução de banco de dados amplamente utilizada que é fácil de usar e não adiciona esforço de acesso 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 difíceis 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.