Olá! Meu nome é Jacqueline Oliveira, sou engenheira de software e instrutora aqui na Alura.
Audiodescrição: Jaqueline é uma mulher de cabelos loiros, pele branca, e está usando uma blusa azul. Ela está em um escritório com iluminação azul ao fundo.
Hoje, vamos falar sobre arquitetura de microsserviços. Esta é uma técnica de design amplamente utilizada no mercado atualmente para solucionar alguns desafios que surgem ao longo de nossa jornada como pessoas desenvolvedoras, onde precisamos tomar decisões para a melhoria do projeto.
Vamos entender juntos quais são os principais conceitos envolvidos nessa arquitetura.
Para trabalharmos e estudarmos sobre arquitetura de microsserviços, utilizaremos o projeto TechTaste. O TechTaste é um aplicativo de delivery. Portanto, vamos considerá-lo em relação aos pedidos, restaurantes, pagamentos e usuários.
Vamos explorar os desafios de utilizar uma aplicação em formato de microsserviços, em vez de um monolito, onde todos os serviços estão dentro da mesma aplicação. Vamos dividir essa aplicação e estruturá-la em microsserviços, onde cada serviço possui seu próprio banco de dados e suas regras. Compreenderemos a arquitetura de microsserviços, suas vantagens e desvantagens no momento de utilização.
Dentro desses conceitos, abordaremos diversos pontos importantes, como o API gateway, os tipos de comunicação (síncrona ou assíncrona), o serviço de descoberta e registro, a parte de config server, message broker, circuit breaker, fallback, entre outros conceitos que são fundamentais nesse tipo de arquitetura.
Te espero no próximo vídeo!
Se você já trabalha como pessoas desenvolvedora, provavelmente já se deparou com códigos enormes, especialmente quando lidamos com código legado, que já está grande e cheio de funcionalidades.
No entanto, geralmente, não é assim que uma aplicação começa. Quando iniciamos nossa jornada desenvolvendo uma aplicação, ela tende a começar pequena, devido a prazos, custos e aceitação. Criamos nosso primeiro MVP, que é o produto mínimo viável. Uma vez que esse produto é testado e aceito no mercado ou pelo nosso público-alvo e homologado, começamos a expandir essa aplicação.
Uma aplicação que inicialmente era pequena, com um serviço ou funcionalidade, passa a ter mais funcionalidades e requisitos.
Com isso, se inicialmente tínhamos uma pessoa desenvolvedora, podemos passar a ter duas, três, e nosso time cresce significativamente.
O que acontece então? Com muitas pessoas e funcionalidades trabalhando na mesma base de código, buscando informações nos bancos de dados, alterando e fazendo deploy, nossa aplicação começa a se tornar complexa. Enfrentamos dificuldades de manutenção, problemas de colaboração, e questões de escalabilidade, pois o custo aumenta se temos uma grande aplicação para escalar.
Essas dificuldades precisam ser superadas. Nosso deploy se torna demorado, especialmente se trabalharmos de acordo com arquiteturas consolidadas, como MVC, Clean Architecture ou até hexagonal, que exigem testes automatizados. Tudo isso torna o processo complexo. Realizar um deploy por conta de uma pequena modificação pode ser um transtorno, e começamos a enfrentar dificuldades.
Qual é uma estratégia comum que costumamos utilizar? Geralmente, deixamos de usar nosso monolito, que é uma aplicação onde tudo está integrado, com todas as regras. Por exemplo, na aplicação TechTaste, que abordaremos no curso, uma aplicação de delivery de comida, temos várias funcionalidades, como perfil, restaurantes e pedidos.
Em vez de ter um grande monolito com todas essas funcionalidades, o que fazemos para superar esses problemas? Optamos por criar pequenos serviços, adotando a arquitetura de microsserviços.
A ideia é ter uma aplicação focada em administração, outra em restaurantes, outra em pedidos, outra em pagamentos e entregas. Assim, criamos nossa arquitetura de microsserviços, onde dividimos a aplicação em outras aplicações que precisam se comunicar entre si para funcionar.
Primeiramente, temos facilidade de mudança ou manutenção, pois cada aplicação é direcionada a uma regra de negócio específica. Se houver um erro ou uma nova funcionalidade na parte de pagamentos, como aceitar PIX, focamos apenas na aplicação de pagamentos para implementar a modificação. No momento do deploy, realizamos apenas o deploy da parte de pagamentos, enquanto o restante da aplicação continua funcionando com seus testes realizados.
Outra vantagem é a possibilidade de ter times menores e autônomos. Uma única pessoa não precisa entender todas as regras e funcionalidades.
Em um monolito, por exemplo, orientado a objetos, podemos ter quase 3 mil classes diferentes, o que torna o entendimento e a modificação complexos. Com um escopo menor e uma aplicação reduzida, conseguimos formar times menores e autônomos.
Além disso, podemos reutilizar componentes. O trecho de pagamentos utilizado em uma aplicação pode ser reaproveitado em outra aplicação que venhamos a desenvolver. Com a aplicação isolada, é fácil replicar. Essa abordagem é bastante interessante, pois permite diversidade tecnológica.
Por que isso é importante? Porque podemos focar apenas em uma parte específica de entregas e mudar a tecnologia, trabalhar com outra linguagem, outra tecnologia, ou hospedar em outro local, como na nuvem.
Assim, conseguimos realizar experimentações que, em um projeto grande, não seriam possíveis. Seria necessário modificar todo o projeto para ter essa diversidade e modificação tecnológica, o que não é interessante.
Além disso, temos maior isolamento de falhas. Por exemplo, se estivermos trabalhando na parte de avaliações e ocorrer um erro, todo o restante do projeto continuará funcionando. O cliente poderá fazer pedidos, efetuar pagamentos e acompanhar o status do pedido, como se está em preparação ou já saiu para entrega. Apenas a avaliação não estará disponível. Assim, conseguimos isolar as falhas e evitar falhas em cascata.
Por fim, alcançamos escalabilidade independente e flexível. Se houver uma sobrecarga de pedidos, podemos escalar apenas o serviço de pedidos, sem precisar escalar toda a aplicação. Podemos escalar somente a parte necessária. Esse conjunto de vantagens nos leva, em alguns cenários, a optar por esse tipo de arquitetura. Como sempre mencionamos, não é uma solução universal e não resolve todos os problemas.
O próprio Martin Fowler, renomado e influente na área de tecnologia, orienta que devemos começar com um monolito e, se necessário, migrar para microsserviços. Algumas pessoas já iniciam com microsserviços, mas isso depende de cada situação.
É uma excelente abordagem e tem sido cada vez mais utilizada no mercado. Portanto, é fundamental que, ao estudar e trabalhar como pessoa desenvolvedora, saibamos usar essas técnicas, identificar o melhor cenário, as vantagens e desvantagens, para trabalhar com mais segurança ao optar por esse tipo de arquitetura.
Vamos também discutir um pouco sobre as desvantagens.
Quando começamos a trabalhar com arquitetura de microsserviços, podemos enfrentar mais dificuldades no desenvolvimento, gerenciamento e planejamento da infraestrutura. Porque todos esses serviços funcionam separadamente, mas, para o usuário, parece ser uma única aplicação. Esses serviços, geralmente independentes e com seus próprios bancos de dados, precisam se comunicar.
Devemos prestar atenção em como será essa comunicação e como esses serviços vão interagir e buscar informações uns dos outros. O desenvolvimento, gerenciamento e infraestrutura são preocupações que precisamos considerar ao desenvolver.
A parte de depuração também é um desafio. Em um monolito, é fácil identificar onde está o erro, mas, com vários serviços individualizados que se comunicam, pode ser mais difícil depurar e localizar o erro.
A comunicação é um desafio: qual tipo de comunicação usar? Síncrona ou assíncrona? Como controlar se o microsserviço recebeu a mensagem e está executando o que foi solicitado? Isso é outra preocupação.
A questão de segurança também é importante, com dados trafegando constantemente entre serviços. É necessário um sistema rigoroso de autenticação e autorização. Todas essas vantagens e desvantagens devem ser analisadas ao trabalhar com microsserviços.
Ao decidir por uma arquitetura de microsserviços, é necessário considerar todas as vantagens e desvantagens para avaliar se os pontos positivos superam os negativos, considerando todos os desafios para implementar a arquitetura.
Ao longo do curso, vamos aprender a implementar um projeto em uma arquitetura de microsserviços e conhecer os principais conceitos para garantir segurança e comunicação, e fazer a arquitetura funcionar da forma mais adequada possível.
Para direcionarmos nossos estudos na arquitetura de microsserviços, vamos trabalhar com um projeto chamado TechTaste.
O TechTaste é um aplicativo para delivery de comida. Inicialmente, vamos focar apenas em comida, com funcionalidades como login, várias opções categorizadas de comida (japonesa, massas, saladas), descrição dos pratos e valores.
Trata-se de um sistema comum de delivery de comida. É uma aplicação comum e com a qual estamos acostumados a interagir.
Quais são os objetivos e desafios dessa aplicação?
Por que devemos considerar dividir nossa aplicação monolítica em microsserviços? Se começarmos a analisar, poderíamos dividi-la ainda mais. Existem muitos desafios.
Por exemplo, na parte de administração. Podemos ter vários endereços para entrega, que influenciam diretamente nos restaurantes que aparecem quando buscamos um delivery. Há diversos meios de pagamento, como cartão, Pix, dinheiro, pagamento antecipado ou na entrega. Podemos cadastrar várias formas de pagamento.
Além disso, há notificações de chat para comunicação com restaurantes, entregadores ou com a própria empresa TechTaste, que atua como intermediária entre o cliente e os restaurantes.
Podemos implementar um programa de fidelidade, onde, após um certo número de compras em um restaurante específico, o cliente tem direito a um valor. Também há a parte de cupons. Apenas a parte de administração já é bastante extensa.
Ao observarmos todas essas partes que dividimos, percebemos que há muitas regras envolvidas. Por exemplo, nos restaurantes, precisamos considerar a distância para entrega com base no CEP selecionado, os meios de pagamento aceitos, os itens fornecidos, os valores, os tipos de entrega disponíveis, o tempo de entrega e a classificação do restaurante.
Na parte de pedidos, se o pagamento for antecipado, é necessário confirmar que o pagamento foi realizado antes de prosseguir com o pedido para a loja. Precisamos informar que o pedido foi aceito, preparar, indicar que saiu para entrega, controlar toda a comunicação com a parte de entrega, com o entregador, registrar a conclusão do pedido e oferecer suporte caso haja algum problema.
Nos pagamentos, há vários tipos, como dinheiro, cartão, cartão corporativo, PIX e doação.
A entrega pode ser própria ou de parceiros. Muitas vezes, é necessário gerenciar o repasse para o entregador, a gratificação, o código de rastreio e o código que a pessoa deve informar ao receber a refeição para que o entregador registre a entrega.
Por fim, há a parte de avaliações, onde podemos avaliar o aplicativo, o restaurante, o pedido e o entregador.
Repare que toda a aplicação, cada parte em que a dividimos, exige muita reflexão. Por isso, esse caso é um forte candidato ao uso da arquitetura de microsserviços.
Seria extremamente complexo gerenciar uma aplicação tão grande com todos esses códigos.
Imagine, ao trabalhar com orientação a objetos, uma aplicação desse porte com todas essas funcionalidades; poderíamos ter mais de 3 mil classes para contemplá-la. Isso tornaria o processo complexo e pesado, até mesmo ao abrir essa aplicação em uma IDE, realizar o build e o deploy.
Nosso desafio é separar essa aplicação em microsserviços. Teremos uma parte prática para treinar como utilizar esses microsserviços a nosso favor.
Nossas aplicações poderão ser acessadas via navegador ou dispositivos móveis, por exemplo. Teremos um API Gateway que receberá essas informações de forma centralizada.
Na parte prática, trabalharemos com três microsserviços: o de usuários, com seu próprio banco de dados; o de pedidos, também com seu próprio banco de dados; e o de pagamentos, igualmente com seu próprio banco de dados.
Esses três microsserviços se comunicarão entre si. Por exemplo, a parte de pedidos terá comunicações, e o Gateway centralizará as requisições. Entre pedidos e pagamentos, trabalharemos com comunicação síncrona.
A comunicação síncrona é necessária porque só podemos prosseguir com o pedido se o pagamento estiver confirmado. Suponha que um restaurante exija pagamento antecipado; precisamos que o pagamento esteja confirmado para prosseguir. Portanto, entre esses microsserviços, a comunicação será síncrona.
Também abordaremos a resiliência, tratando falhas caso o serviço de pagamento não esteja operando, por meio de um circuit breaker. Todos esses conceitos serão compreendidos e trabalhados.
Além disso, entre pedidos e usuários, para comunicações como "pedido aceito", "pagamento aceito", "loja preparando", "saiu para entrega", utilizaremos comunicação assíncrona. O microsserviço de pedidos enviará essa informação para uma fila, e o microsserviço de usuários, que monitorará essa fila por meio de um message broker, detectará a mensagem e realizará o envio.
No curso, exploraremos essa arquitetura de microsserviços, compreendendo cada ponto: a parte do gateway, os microsserviços individualmente, as comunicações síncrona e assíncrona, o service registry e o service discovery, para entender como registrar esses serviços e permitir que se comuniquem entre si, além de localizar um ao outro. Também abordaremos o config server para centralizar nossas configurações.
Teremos uma experiência enriquecedora sobre o que é necessário fazer, e poderemos avaliar as vantagens, desvantagens e desafios ao utilizar a arquitetura de microsserviços.
Este é um projeto completo e interessante, e esperamos que você curta desenvolvê-lo.
Começaremos na próxima aula!
O curso Microsserviços com Java: construa soluções escaláveis possui 65 minutos de vídeos, em um total de 50 atividades. Gostou? Conheça nossos outros cursos de Java em Programação, ou leia nossos artigos de Programação.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
Impulsione a sua carreira com os melhores cursos e faça parte da maior comunidade tech.
1 ano de Alura
Assine o PLUS e garanta:
Formações com mais de 1500 cursos atualizados e novos lançamentos semanais, em Programação, Inteligência Artificial, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.
A cada curso ou formação concluído, um novo certificado para turbinar seu currículo e LinkedIn.
No Discord, você tem acesso a eventos exclusivos, grupos de estudos e mentorias com especialistas de diferentes áreas.
Faça parte da maior comunidade Dev do país e crie conexões com mais de 120 mil pessoas no Discord.
Acesso ilimitado ao catálogo de Imersões da Alura para praticar conhecimentos em diferentes áreas.
Explore um universo de possibilidades na palma da sua mão. Baixe as aulas para assistir offline, onde e quando quiser.
Acelere o seu aprendizado com a IA da Alura e prepare-se para o mercado internacional.
1 ano de Alura
Todos os benefícios do PLUS e mais vantagens exclusivas:
Luri é nossa inteligência artificial que tira dúvidas, dá exemplos práticos, corrige exercícios e ajuda a mergulhar ainda mais durante as aulas. Você pode conversar com a Luri até 100 mensagens por semana.
Aprenda um novo idioma e expanda seus horizontes profissionais. Cursos de Inglês, Espanhol e Inglês para Devs, 100% focado em tecnologia.
Transforme a sua jornada com benefícios exclusivos e evolua ainda mais na sua carreira.
1 ano de Alura
Todos os benefícios do PRO e mais vantagens exclusivas:
Mensagens ilimitadas para estudar com a Luri, a IA da Alura, disponível 24hs para tirar suas dúvidas, dar exemplos práticos, corrigir exercícios e impulsionar seus estudos.
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais.
Escolha os ebooks da Casa do Código, a editora da Alura, que apoiarão a sua jornada de aprendizado para sempre.