Spring Boot: Como desenvolver microservices seguros

Spring Boot: Como desenvolver microservices seguros

Veja neste artigo algumas das opções disponíveis para isso e como garantir a segurança de microsserviços através de autenticação.

Por que eu devo ler este artigo: Cenário: Este artigo apresenta uma maneira simplificada de adicionar autenticação em microserviços baseados no Spring Boot.

Os microserviços são aplicações autônomas que normalmente utilizam um servidor web embarcado e disponibilizam uma interface REST para interação com sistemas externos. Com esse novo estilo arquitetural, torna-se crucial a adição de componentes que realizem a segurança e só permitam o acesso de clientes (aplicações ou usuários) que tenham autorização para executar determinada ação.

Lembre-se que independentemente do tipo de aplicação, é de suma importância a proteção contra requisições indevidas e isso se torna ainda mais crítico quando se trata de microserviços baseados em REST, visto que toda forma de comunicação ocorre sobre o protocolo HTTP, podendo ser acessado por qualquer usuário na web. Com base nisso, este artigo busca explorar as opções que possibilitam construir microserviços mais seguros.”

Até poucos anos atrás, grande parte dos desenvolvedores Java desenvolviam aplicações corporativas organizadas como sistemas monolíticos, contendo um ou mais módulos, implantados como um único pacote (WAR ou EAR) em um servidor de aplicações (ex.: GlassFish, JBoss AS). Esse conceito ainda é amplamente adotado no mercado, mas uma alternativa promissora começa a ganhar espaço: a arquitetura baseada em microserviços.

Com a demanda pelo desenvolvimento de sistemas cada vez mais complexos e o consequente aumento no número de dependências e linhas de código, a rotina de um desenvolvedor que precisa trabalhar com aplicações monolíticas tornou-se cada vez mais difícil.

Além do grande número de módulos, componentes, pacotes e classes, que vão agregando funcionalidades que visam contemplar a cadeia completa do modelo de negócio em questão, o desenvolvedor precisa reimplantar a sua aplicação em um servidor de aplicações a cada modificação.

Para lidar com isso algumas estratégias foram desenvolvidas como, por exemplo, o plugin do JRebel, que realiza o hot-deploy (implantação instantânea, sem necessidade de reiniciar o serviço) da aplicação no servidor. No entanto, qualquer modificação mais complexa, como a criação de novos componentes de negócio, demanda um comando de reinicialização completo, o que pode levar alguns minutos.

Fora a queda de produtividade devido à demanda de implantação de um pacote no servidor a cada modificação, o desenvolvedor de aplicações monolíticas ainda precisa lidar com outros problemas clássicos de aplicações altamente acopladas, como a impossibilidade de manter módulos funcionando de maneira independente, a dificuldade da escalabilidade de um serviço específico (que demande mais processamento), o alto risco de inserção de efeitos colaterais após uma modificação e a dificuldade de integração com sistemas externos, visto que uma interface única de acesso normalmente é enorme e bastante suscetível a mudanças.

Como se torna difícil manter um padrão, ou acabam-se criando interfaces especializadas para determinados clientes, o que gera ainda mais acoplamento entre os sistemas, ou o cliente precisará estar constantemente atualizando a sua interface de comunicação com o servidor.

Então, como pensar em uma arquitetura viável para este cenário? Que tal pensarmos em aplicações com o escopo reduzido e focadas em um serviço específico, que possam ser distribuídas pela nuvem e não dependam da implantação em um servidor externo? Esse é o conceito-chave por trás dos microserviços.

Neste cenário, ao invés de um grande pacote EAR implantado em um servidor de aplicações, vamos ter um conjunto de aplicações empacotadas cada uma como um simples JAR, que não precisam ser implantados em nenhum servidor. Basta executar a aplicação via java –jar que ela estará pronta para ser acessada através de qualquer cliente HTTP.

De maneira mais prática, é como se desmembrássemos um sistema monolítico em vários sistemas menores, que executam de maneira independente.

Considerando como exemplo um sistema de loja on-line, poderíamos elencar vários microserviços, tais como: controle de logística, visualização de produtos, mala direta, emissão de notas fiscais, promoções, entre tantos outros; ou seja, são inúmeras as possibilidades.

Com esse desmembramento, torna-se possível atualizar versões de quaisquer serviços sem ter de parar toda a infraestrutura, organizar o armazenamento de cada microserviço adotando uma tecnologia mais adequada para aquele propósito (ex.: NoSQL, In-memoryDB) ou até mesmo, se for o caso, desenvolver cada um em uma linguagem de programação diferente. Enfim, essa nova solução nos dá a liberdade total para desenvolver cada parte do negócio e ainda força o desenvolvedor a pensar em sua aplicação com uma visão mais focada.

Dentro desse ambiente tão livre, surge um novo requisito, que até então não havia nas aplicações monolíticas: a necessidade de uma camada de segurança nos microserviços. Considerando o exemplo do sistema de loja on-line, não seria adequado que um usuário sem a devida autorização consiga alterar o preço de um produto.

Portanto, apesar de sua característica autônoma, cada microserviço precisa se adequar a um escopo de segurança, de forma que cada requisição realizada seja tratada adequadamente e só após a confirmação das credenciais válidas, que o acesso deve ser liberado.

Fonte: DevMedia
https://www.devmedia.com.br/
https://www.devmedia.com.br/spring-boot-como-desenvolver-microservices-seguros/34101

Sensor de Presença Integrado Com Bot do Telegram

Sensor de Presença Integrado Com Bot do Telegram

ÍNDICE DE CONTEÚDO

  • Telegram
  • Criação do Bot do Telegram
  • ESP32/8266 + Arduino IDE
  • Sensor de Presença
  • Diagrama das Conexões
  • Firmware
    • Bibliotecas
    • Código
  • Saiba mais

Neste artigo iremos utilizar uma biblioteca, compatível com Arduino, que possibilita a comunicação de maneira fácil e rápida de um microcontrolador(no caso deste artigo o ESP32) com um robô(ou bot) criado com o aplicativo de mensagens Telegram. A ideia é utilizar um sensor de presença que através de uma interrupção configurado no ESP32, informa ao microcontrolador a detecção de movimento e o mesmo comunica-se, por uma conexão com a internet, com o bot e a mensagem pode ser visualizada pelo usuário.

Telegram

O Telegram é um aplicativo de mensagens disponível para Android e IOS. Para prosseguir, você pode baixar o aplicativo na loja de aplicativos do seu sistema operacional e criar uma conta. Uma funcionalidade bastante interessante presente no Telegram é a possibilidade de criação e programação de Bots que podem realizar diversas tarefas como: informar valor de algum ativo na bolsa de valores, enviar lembretes, Tweetar mensagens e etc…

O Bot utilizado neste artigo apenas replicará a mensagem recebida pelo microcontrolador. A seguir apresentaremos o procedimento para a criação e configuração do Bot utilizado.

Criação do Bot do Telegram

Os Bots são criados a partir de uma ferramenta chamada botfather. Após abrir o aplicativo, utilize a ferramenta de busca para encontrar o “@BotFather”.

Busca pelo bot

Figura 1: Busca pelo @botfather no aplicativo do telegram.

A seguir envie o comando “/newbot”, na próxima mensagem forneça o nome do Bot e depois escolha um username para o bot(este nome deve necessariamente terminar com “bot”).

Configurando bot

Figura 2: Configurando um nome e um “username” para o bot.

Após a criação um token será disponibilizado, salve-o, pois ele será necessário para a inicialização da biblioteca que fará a comunicação com o Bot. A figura a seguir ilustra onde localizar o Token gerado.

Token

Figura 3: Token do bot.

Pronto! Seu Bot já está criado e pronto para ser utilizado. A seguir apresentaremos o microcontrolador utilizado para a comunicação com o Bot.

ESP32/8266 + Arduino IDE

A biblioteca utilizada para a comunicação com o Bot é compatível com o Arduino IDE e foi desenvolvida para microcontroladores das famílias ESP32 e ESP8266. Para que seja possível a programação dessas famílias de microcontroladores pelo ambiente Arduino, algumas configurações são necessárias, para isto basta seguir a sessão “Instalação do pacote ESP32 para Arduino” deste artigo do Embarcados: https://www.embarcados.com.br/franzininho-wifi-primeiros-passo-na-arduino-ide/.

Para este tutorial utilizaremos a placa de desenvolvimento DO IT DEVKIT WROOVER.

Módulo ESP32

Figura 4: Módulo ESP32 utilizado.

Sensor de Presença

Para a detecção de movimento utilizaremos o módulo HC-SR501 que utiliza um sensor PIR, capaz de detectar a variação de emissão de luz infravermelha emitida por um corpo.

Sensor de movimento

Figura 5: Módulo sensor de movimento(HC-SR501) utilizado

O módulo pode ser alimentado com 5V e gera uma saída em 3V3, portanto compatível com o nível lógico utilizado pelo ESP32/ESP8266(3V3).

Diagrama das Conexões

O circuito utilizado é relativamente simples, a placa de desenvolvimento será alimentada pela USB(5V) e o pino “Vin” irá alimentar o módulo HC-SR501 e sua saída será ligada ao pino 27 da placa que será configurado como interrupção.

Diagrama de conexões

Figura 6: Esquema de conexões entre o Sensor de presença e o módulo ESP32.

Firmware

A seguir serão descritas as bibliotecas necessárias para o correto funcionamento do código e o próprio código explicado linha a linha.

Bibliotecas

A biblioteca utilizada para o gerenciamento do Bot pode ser baixada pelo link https://github.com/shurillu/CTBot ou pelo gerenciador de bibliotecas da própria Arduino IDE, como indicado na próxima imagem.

biblioteca

Figura 7: Download da biblioteca CTBot pelo gerenciador de bibliotecas da Arduino IDE.

Outra biblioteca necessária para o correto funcionamento da aplicação é a ArduinoJson que pode ser baixada pelo link https://github.com/bblanchon/ArduinoJson ou pelo gerenciador de bibliotecas da Arduino IDE. Neste tutorial está sendo utilizada a versão 5.13.5 desta biblioteca, mas como indicado na descrição da biblioteca “CTBot” ela possui suporte tanto para a versão 5 quanto para a versão 6 da ArduinoJson.

biblioteca

Figura 8: Download da biblioteca JSon pelo gerenciador de bibliotecas da Arduino IDE.

Código

Em linhas gerais o código apresentado envia mensagens ao Bot quando uma interrupção é detectada, indicando a presença ou movimento no cômodo. O código-fonte completo segue abaixo, leia com atenção os comentários para o completo entendimento do mesmo.

/*
Descrição: Sensor de presença informando presença em determinado cômodo a um Bot do Telegram.
Autor: Paulo Fernando.
*/
//Biblioteca para gerenciar comunicação com o Bot
#include "CTBot.h"
//Pino de interrupção utilizado com o módulo HC-SR501
#define PIR 27
//Inicializa objeto da biblioteca
CTBot myBot;
//Flag que será tratada na rotina de interrupção
bool pir_presence_flag = false;
//Função responsável pelo envia de mensagens ao Bot
void msgTelegramBot(void);
//Substituir pelo SSID de sua rede WiFi
String ssid = "";
//Substituir pela senha de sua rede WiFi
String pass = "";
//Substituir pelo Token do Bot criado.Este valor é recebido após a criação do Bot com o "@BotFather"
String token = "";
//Função chamada quando há interrupção,manter mais curta o possível
void IRAM_ATTR ISR_0(){
pir_presence_flag = true;
}
//SetUp
void setup(){
     //Pino de interrupção incializado em Pull Down
     pinMode(PIR, INPUT_PULLDOWN);
     //Seta o pino como entrada, associa a interrupção a borda de subida e indica o nome da função que irá tratar a interrupção
     attachInterrupt(PIR, ISR_0, RISING);
     //Inicializa a porta serial para debug
     Serial.begin(115200);
     Serial.println("Iniciando TelegramBot...");
     //Inicia conexão com WiFi
     myBot.wifiConnect(ssid, pass);
     //Configura o Token do Bot
     myBot.setTelegramToken(token);
     //Testa conexão com o Bot
     if(myBot.testConnection())
          Serial.println("\nTeste de Conexão OK");
     else
          Serial.println("\nTeste de Conexão NOK");
          delay(500);
          //Inicia
          msgTelegramBot();
     }

void loop(){
     //Nada a fazer
}
//Verifica conexão com o Bot.Sai dessa função apenas quando a conexão é estabelecida.
bool reconnectTelgramBot(){
     while(!myBot.testConnection()){
          Serial.println("");
          //Tenta conexão com WiFi
          if(myBot.wifiConnect(ssid, pass)){
               Serial.println("Conexão estabelecida");
          }
          else{
               Serial.println("");
          }
     }
     return true;
}
void msgTelegramBot(){
     //Variable para armazenar mensagens vinda do Bot
     TBMessage msg;
     while(1){
          //Verifica se chegou alguma mensagem - Uma primeira mensagem é necessária ser enviada para iniciar o Bot
          if(CTBotMessageText == myBot.getNewMessage(msg)){
               //Envia mensagem de volta ao Bot
               myBot.sendMessage(msg.sender.id, msg.text);
               //Quando a primeira mensagem é recebida o MCU começa a monitorar o sensor de presença para enviar mensagens ao Bot
               while(1){
                    //Movimento detectado
                    if(pir_presence_flag){
                         //Sinaliza que ocorreu a interrupção
                         Serial.println("FLAG!");
                         //Reseta o valor da Flag
                         pir_presence_flag = false;
                         //Envia mensagem ao Bot
                         if(!myBot.sendMessage(msg.sender.id, "Presença Detectada!")){
                              //Falha no envio da mensagem
                              Serial.println("Falha no envio da mensagem.");
                              //Verifica a conexão com o Bot
                              while(!reconnectTelgramBot()){
                                   delay(10);
                              }
                         }
                         //Aguarda 10 segundos para verificar novamente se a flag mudou de valor.
                         delay(10000);
                    }
                    delay(10);
               }
          }
          delay(10);
     }
}

Fonte:
https://www.embarcados.com.br
https://www.embarcados.com.br/sensor-de-presenca-integrado-com-bot-do-telegram/

 

Introdução à arquitetura de microservices com Spring Boot

Introdução à arquitetura de microservices com Spring Boot

Aprenda neste artigo os principais conceitos e desenvolva um microsserviço para distribuição de pacotes de viagens a diferentes clientes de um portal.


Por que eu devo ler este artigo: Este artigo apresenta de forma prática um dos assuntos que vem ganhando mais destaque entre arquitetos e desenvolvedores de software: o padrão de arquitetura microsserviços (ou microservices). Para isso, exploraremos aqui os principais conceitos, vantagens e desvantagens, assim como um caso de uso. A partir do conteúdo exposto o leitor será capaz de dar os primeiros passos na construção de sistemas baseados nessa arquitetura na plataforma Java utilizando o Spring Boot.

Uma das funções mais importantes e desafiadoras de um arquiteto de software é a definição da arquitetura para o sistema a ser desenvolvido. Iniciada entre as primeiras fases do projeto, esta etapa é fundamental para o bom andamento do mesmo. Para se ter uma noção mais precisa, uma decisão incorreta pode ocasionar atrasos na entrega do sistema, comprometer a qualidade, a segurança ou até mesmo inviabilizar o desenvolvimento.

Dada a importância dessa fase para a fundação do sistema, inúmeros padrões de desenvolvimento, frameworks e modelos arquiteturais são elaborados para resolver problemas comuns utilizando as melhores práticas. Neste cenário, um dos padrões arquiteturas que mais tem se destacado é a arquitetura de microservices, justamente pelos benefícios adquiridos ao adotar esta solução. Antes de discutirmos mais detalhes sobre essa arquitetura, no entanto, precisamos entender outro padrão arquitetural muito utilizado, talvez o mais comum deles: a arquitetura monolítica.

Portanto, no decorrer do artigo iremos debater sobre os conceitos introdutórios dos padrões de arquitetura monolítica e de microservice e, de forma prática, iremos aplicar esses conceitos para solucionar um problema elaborado para o caso de uso do artigo, que fará uso do Spring Boot como base.

Aplicações Monolíticas

Sistemas construídos sobre o padrão arquitetural monolítico são compostos basicamente por módulos ou funcionalidades agrupadas que, juntas, compõem o software. Como exemplos de aplicações que fazem uso do modelo monolítico, podemos citar os sistemas ERP (Enterprise Resource Planning), como o SAP ou Protheus. Estes possuem, normalmente, módulos para controle do setor financeiro, contábil, compras, entre outros, agrupados numa única solução que acessa o banco de dados.

Na Figura 1 podemos verificar um exemplo de ERP construído com base numa arquitetura monolítica.

Sistema ERP

Figura 1. Exemplo de Arquitetura Monolítica.

Introduzida a mais tempo que o padrão de microservices, a arquitetura monolítica também é comumente utilizada no desenvolvimento de aplicações web. No entanto, assim como qualquer solução, ele provê vantagens e desvantagens.

Dentre as vantagens, podemos citar:

  • Implantar a aplicação é relativamente simples, uma vez que basta fazer o deploy de um único WAR ou EAR no servidor de aplicação;
  • Simples de monitorar e manter;
  • Ambiente de desenvolvimento mais simples, onde uma tecnologia core é utilizada em todo o projeto.

Dentre as desvantagens, podemos citar:

  • Uma mudança feita em uma pequena parte da aplicação exige que todo o sistema seja reconstruído e implantado;
  • Escalar a aplicação exige escalar todo o aplicativo, em vez de apenas partes que precisam de maior demanda;
  • Alta curva de aprendizado para novos desenvolvedores que entram no time de desenvolvimento, uma vez o desenvolvedor deve entender o contexto de todos os módulos do projeto;
  • Necessidade de reimplantar tudo para alterar um único componente. Sendo assim, o risco de falhas aumenta e consequentemente um ciclo maior de testes deve ser aplicado.

Microservices

Em suma, o estilo arquitetural de microservices consiste no desenvolvimento de uma aplicação como um conjunto de pequenos serviços, cada um executando em seu próprio processo. Os serviços podem ser construídos de forma modular, com base na capacidade de negócio da organização em questão.

Pelo fato dos serviços serem construídos de forma independente, a implantação e a escalabilidade podem ser tratadas de acordo com a demanda. Essa independência também permite que os serviços sejam escritos em diferentes linguagens de programação e diferentes tecnologias, visando atender a necessidades específicas da melhor maneira. Outro ponto importante é que cada serviço pode ser gerenciado por diferentes times de desenvolvimento, possibilitando a formação de equipes especializadas.

Para termos uma melhor noção de onde podemos aplicar este conceito, listamos a seguir algumas vantagens e desvantagens.

Dentre as vantagens, podemos citar:

  • Fácil entendimento e desenvolvimento do projeto;
  • Fácil e rápida implantação (build e deploy);
  • Redução do tempo de startup, pois os microservices são menores que aplicações monolíticas em termos de código;
  • Possibilidade de aplicar a melhor ferramenta para um determinado trabalho.

Dentre as desvantagens, podemos citar:

  • Dificuldade em implantar e operar sistemas distribuídos;
  • Como cada microservice geralmente tem sua própria base de dados, o gerenciamento de transação se torna mais difícil (múltiplas bases de dados);
  • Implantar uma alteração em um serviço utilizado por muitos sistemas demanda coordenação e cautela.

Organizando os microservices com a API Gateway

Depois de conhecermos os conceitos por traz dos microservices, uma das primeiras perguntas que nos vem à cabeça é: meus clientes ou consumidores (sistemas terceiros) precisam conhecer todos os microservices para se comunicar? Neste caso sim (ou teríamos que desenvolver um conjunto de microservices apenas para possibilitar a comunicação), e isso não é bom!

Como exemplo para melhorar o entendimento, vamos utilizar o caso do ERP citado anteriormente e decompor aquela arquitetura monolítica em serviços. Isso nos daria, por exemplo, um serviço específico para o módulo compras, outro para o financeiro, outro para o contábil e assim por diante.

Uma vez que os microservices estejam prontos para uso, imagine que nosso cliente seja uma aplicação web responsável apenas pela camada de apresentação do ERP, e que esta deva se comunicar com todos os módulos (serviços). Sendo assim, para evitar que essa aplicação conheça o endereço de cada um dos serviços, devemos incluir uma camada de abstração, pois seria muito complexo para o cliente se encarregar de manter estes endereços atualizados, por exemplo.

Para resolver este problema, um padrão foi criado: a API Gateway. Com o gateway os clientes terão um únic …


Fonte:
www.devmedia.com.br

https://www.devmedia.com.br/introducao-a-arquitetura-de-microservices-com-spring-boot/33703