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