Arquitetura

Introdução

A seguir será descrita a arquitetura geral do sistema GeoProcess.

O sistema GeoProcess é todo baseado na ideia de Perguntas e Respostas. Esse sistema funciona como uma ferramenta de ciência de dados que gera de forma simples um conjunto de dashboards dos resultados. Os resultados são na verdade as respostas das perguntas que serão exibidas para o usuário final e podem conter Mapas, Gráficos e Tabelas.

O sistema GeoProcess foi todo construído de forma modularizada e sua arquitetura de software possui três módulos principais, que são: PORTAL, GATEWAY e CONSUMERS. A comunicação entre esses módulos utiliza um protocolo específico para comunicação baseada em mensagens, o AMQP (Advanced Message Queuing Protocol).

Objetivo Geral

A plataforma GeoProcess tem por objetivo geral apresentar as seguintes características:

• Requisitos funcionais:
  • Suporta consumidores do tipo pergunta e resposta;
  • Suporta consumidores do tipo pergunta e resposta com alertas;
  • Suporta consumidores do tipo dashboard interativo (painéis).
• Requisitos não funcionais:
  • Ser escalável (horizontalmente e verticalmente);
  • Suportar múltiplos clientes.
  • Suportar múltiplas aplicações diferentes.
• Simples de usar (usuários finais):
  • Atender usuários não especialistas;
  • Possuir conhecimento básico em informática.
• Simples de implementar (programadores):
  • Evitar retrabalho através da reutilização de módulos;
  • Ter uma linguagem de programação acessível;
  • Ser acessível a bolsistas com pouca experiência.
• Facilitar o levantamento de requisitos:
  • Simular perguntas e eventuais respostas junto ao cliente;
  • Prototipação rápida dos dashboards das respostas.

Visão Geral

A figura, mostrada a seguir, dá uma visão geral de como os módulos PORTAL, GATEWAY e CONSUMERS se conectam entre si.

• PORTAL: é um módulo principal de interação do usuário é uma implementação de uma aplicação web desenvolvida usando o framework Django do Python. Esse módulo possui front-end e back-end.

• GATEWAY: é um módulo back-end intermediador (proxy) entre os consumidores e o módulo do portal.

• CONSUMERS: é um módulo back-end consumidor que se comunica com o proxy fazendo requisições para o portal.

Toda a comunicação entre esses módulos ocorre através da troca de mensagens com arquivos JSON. A utilização de arquivos JSON foi definida por ser fácil trocar mensagens e ser um protocolo bem estabelecido nesse tipo de arquitetura.

Tecnologias Utilizadas

A figura abaixo detalha algumas das tecnologias utilizadas na construção desses módulos.

PORTAL: O Portal é o módulo principal da aplicação do GeoProcess e é um projeto desenvolvido em Python com o framework Django (back-end). Ele utiliza o banco de dados PostgreSQL para armazenamento das informações. A parte de front-end é desenvolvida utilizando as linguagens HTML, CSS, Javascript. São utilizadas também as seguintes ferramentas Bootstrap, AdminLTE, Chart.js e OpenLayers. O Bootstrap é um framework para desenvolvimento da interface. O AdminLTE é sistema de painel de controle de dashboard. O Chart.js é uma biblioteca Javascript para desenhar gráficos. O OpenLayers é uma biblioteca Javascript para exibir dados de mapas em navegadores da Web como mapas deslizantes.

GATEWAY: O Gateway é o módulo back-end do GeoProcess e é um projeto desenvolvido em Python com a biblioteca FastAPI. Esse módulo se comunica constantemente com os Consumers através de sistema de mensageria usando o RabbitMQ com o protocolo AMQP. Ele utiliza o servidor web Uvicorn. Ele utiliza o banco de dados PostgreSQL para armazenamento das informações. O Gateway faz a verificação de segurança para acessar os recursos corretos para determinados usuários no sistema. Esse módulo também é o responsável por guardar o histórico das requisições.

CONSUMER: O consumidor é um módulo back-end do GeoProcess e é um projeto desenvolvido em Python. Esse módulo se comunica constantemente com o Gateway através de sistema de mensageria usando o RabbitMQ com o protocolo AMQP. Ele utiliza o banco de dados PostgreSQL para armazenamento das informações. Podemos entender os consumidores do sistema como sendo os respondedores de perguntas. Devido a forma como o sistema foi desenvolvido (sistema distribuído) pode-se ter mais de uma instância do mesmo consumidor permitindo que o sistema consiga escalar.

A comunicação entre os módulos ocorre através da troca de mensagens e utiliza o formato JSON para padronização das mensagens. As mensagens são trafegadas utilizando o sistema de mensageria RabbitMQ.

Fluxo de Informações

A figura abaixo detalha o fluxo de informação que trafega entre esses módulos.

O fluxo de informação geral dos módulos está detalhado abaixo:

a) O usuário acessa o Portal e é automaticamente redirecionado para o sistema de autenticação de usuário Single Sign-On (SSO) configurado.

b) No sistema SSO, o usuário se autentica, então é feito o login desse usuário com seu nível de acesso e suas regras de acesso. Em seguida, o usuário é redirecionado novamente para a plataforma Portal. O resultado final é um token de autenticação no padrão JSON Web Token (JWT).

c₁) O Portal envia o token (JWT) para o Gateway que baseado nas informações do token irá personalizar a interface visualizada pela usuário. A personalização será baseada nas permissões de acesso a projetos daquele usuário.

d₁) O Gateway após receber o token (JWT) envia as informações sobre os projetos visíveis para determinado usuário para o Portal que monta o ambiente personalizado daquele usuário.

c₂) O Portal baseado em um projeto selecionado pelo usuário consulta o Gateway para saber quais são as perguntas daquele projeto.

d₂) O Gateway responde com uma lista de perguntas relacionadas ao projeto selecionado.

c₃) O Portal baseado em uma pergunta selecionada pelo usuário consulta o Gateway para saber quais são os parâmetros daquela pergunta.

d₃) O Gateway responde com uma lista de parâmetros relacionados à pergunta selecionada.

c₄) O Portal baseado na pergunta e nos parâmetros preenchidos pelo usuário consulta o Gateway para saber quais a resposta daquela pergunta.

d₄) O Gateway responde à pergunta efetuada pelo usuário.

c₅) O Portal baseado em uma solicitação do usuário consulta o Gateway para saber quais são as perguntas que o usuário já fez.

d₅) O Gateway responde com uma lista de perguntas (histórico) já realizadas pelo usuário.

e) O Consumidor informa ao Gateway qual é o projeto que ele está vinculado e quais são as perguntas e parâmetros necessários ao seu funcionamento.

f) O Gateway redireciona uma pergunta com seus parâmetros prenchidos pelo usuário (no Portal) para o Consumidor.

g) O Consumidor responde à pergunta solicitada pelo Gateway que irá redirecionar a resposta ao Portal.

Atenção

Os fluxos de comunicação entre o Portal e Gateway e entre o Gateway e Consumidores são fluxos independentes e assíncronos.

Organização do Projeto GeoProcess

Do ponto de vista de código, todos os códigos devem estar dentro de uma pasta chamada geoprocess. Dentro desta pasta deve-se ter todos os projetos que se deseja utilizar. A seguir temos uma visão geral da organização das pastas dos nossos projetos.

.
└── geoprocess
    ├── pgst-portal
    ├── pgst-gateway
    ├── pgst-lib
    ├── pgst-visual-builder
    ├── pgst-consumer-basic
    ├── pgst-consumer-sample
    ├── pgst-consumer-dash-basic
    ├── pgst-consumer-dash-sample
    ├── geoprocess-docs
    └── simplesuggester

Atenção

A organização de código não precisa seguir rigidamente essa estrutura de pastas, mas caso faça dessa maneira os ajustes de configuração serão minimizados.

Escalabilidade da Plataforma

A plataforma GeoProcess suporta a escalabilidade horizontal e vertical. A escabilidade horizontal e vertical são dois conceitos importantes quando se trata de dimensionar e melhorar o desempenho de aplicações web, especialmente em ambientes distribuídos. Esses termos se referem a diferentes abordagens para lidar com a carga de trabalho e garantir que um sistema seja capaz de lidar com um aumento no número de usuários ou demanda.

Escalabilidade Horizontal:

Refere-se à adição de mais máquinas (ou nós) ao sistema para distribuir a carga. Em termos simples, significa aumentar a capacidade de processamento adicionando mais servidores à infraestrutura. Em uma arquitetura horizontalmente escalável, cada máquina adicional contribui para o aumento da capacidade total do sistema.

Vantagens:

• Fácil de adicionar capacidade, basta adicionar mais servidores.
• Maior flexibilidade e tolerância a falhas, já que a carga pode ser distribuída entre vários servidores.

Desvantagens:

• Pode haver um custo adicional de comunicação entre os nós.
• Nem todos os aplicativos são facilmente horizontalmente escaláveis.

Escalabilidade Vertical:

Refere-se à adição de recursos (CPU, RAM, armazenamento, etc.) em uma única máquina para melhorar o desempenho. Isso envolve a atualização ou substituição de hardware para lidar com uma carga maior. Em vez de adicionar mais servidores, você aprimora as características de um servidor existente.

Vantagens:

• Menos complexidade na gestão de múltiplos servidores.
• Pode ser eficaz para aplicativos que têm limitações de escalabilidade horizontal.

Desvantagens:

• Limitado pela capacidade máxima do hardware disponível.
• Pode ser mais caro em termos de custo por desempenho.