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.

Table of Contents

Componentes
Infraestrutura
Comunicação

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. Essa arquitetura está descrita na figura abaixo.

Fig. 1 Arquitetura Atual

O uso da dojot pode ser resumido assim: um usuário configura dispositivos IoT por meio da Interface Gráfica de Usuário (GUI) ou diretamente pela API REST fornecida pelo Kong API Gateway. Fluxos de processamento de dados também podem ser configurados dessas duas maneiras e suportam a execução de várias ações, como notificações geradas quando um determinado atributo de um dispositivo ultrapassa um certo limite, ou como a persistência de todos os dados gerados por um dispositivo em um banco de dados externo. Assim que os dispositivos começam a enviar seus dados para a dojot, o usuário pode ter interesse em receber esses dados via notificações (subscrição de notificações), em consolidar todos os dados em dispositivos virtuais, em reunir todos os dados do banco de dados histórico e assim por diante. Tais recursos podem ser utilizados por meio de APIs REST. Esses são os blocos básicos de construção que qualquer aplicação em cima da dojot poderia se valer. A Interface Gráfica de Usuário da 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 pode também ser utilizada para verificar se tudo está funcionando bem.

Os contextos de usuários são isolados 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 de API). Depois que os dispositivos são configurados, o agente IoT é capaz de traduzir os dados recebidos dos dispositivos, encapsulados no MQTT ou outro protocolo, e enviá-los ao intermediador de contexto para distribuição interna, atingindo, por exemplo, o serviço de histórico, a fim de que ele possa persistir as informações no banco de dados. Se determinadas condições forem satisfeitas quando regras estão sendo processadas, um novo evento é gerado e enviado para o serviço de distribuição que repassa aos serviços interessados.

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.

Kafka + data-broker + NGSI ¶

Apache Kafka is a distributed messaging platform that can be used by applications which need to stream data or consume/produce data pipelines. In comparison with other open-source messaging solutions, Kafka seems to be more appropriate to fulfil dojot’s architectural requirements (responsibility isolation, simplicity, and so on).

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 de gerenciamento de subscrições faz uso de um banco de dados em memória para ser eficiente. Ele agrega contextos ao Apache Kafka, permitindo que serviços internos ou até mesmo externos, se subscrevam ou consultem dados baseados em contexto. O gerenciador de subscrição também é um componente distribuído para não ser um gargalo ou ainda um ponto único de falha na arquitetura.

A fim de se manter um certo nível de compatibilidade com componentes do tipo NGSI (Next Generation Service Interfaces), é possível construir um elemento que ofereça uma interface NGSI para tais componentes.

Gerenciador de Dispositivos ¶

O Gerenciador de Dispositivos é 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.

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.

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.

Orchestrador ¶

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).

Histórico ¶

O componente histórico 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.

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.

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.

Interface Gráfica de Usuário ¶

A Interface Gráfica de Usuário 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.
Applications Management: Creation, Visualization, Edition and Deletion Operations
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.

Controlador de Serviços Elástico ¶

Serviço especializado para ambientes de nuvem que monitora a utilização da plataforma, diminuindo ou aumentando a sua capacidade de processamento e armazenamento de maneira automática e dinâmica de forma a se adaptar a variação da demanda.

Este controlador depende que os serviços que compõem o dojot possam ser escalados horizontalmente, assim como, que os bancos de dados utilizados sejam clusterizáveis, que é o caso da arquitetura adotada.

Este componente está programado para entrar em desenvolvimento.

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.

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.