Microsserviços: padrões de projeto

Conhecendo a arquitetura - Apresentação

Boas-vindas à Alura! Sou Vinícius Dias e vou guiar vocês neste curso sobre padrões de projeto quando conversamos sobre arquitetura de microsserviços.

Audiodescrição: Vinicius Dias é uma pessoa de pele clara, olhos escuros e cabelos pretos. Usa bigode e cavanhaque e tem cabelo curto. Está com uma camiseta azul-marinho escrito "Caelum". Está sentado em uma cadeira preta.

O que vamos aprender?

Neste curso, vamos começar entendendo o básico: como a web funciona e o que é o protocolo HTTP. A partir disso, vamos conhecer o modelo de aplicações e arquitetura de aplicações monolíticas. E, a partir disso, vamos entender algumas desvantagens de aplicações monolíticas.

Em seguida, começamos a abordar sobre o que são microsserviços, quais as vantagens de microsserviços e suas desvantagens. Só então, a partir dessa ideia, abordamos os padrões.

Vamos abordar a separação de microsserviços, a integração entre eles, a gestão de dados pelos microsserviços e as operações relacionadas a eles. Além disso, discutiremos a importância dos logs e métricas, bem como aspectos arquiteturais da infraestrutura, do código e das operações, tornando a conversa bastante interessante.

Esse curso foca em conceitos, então não envolverá a escrita de código nem atividades práticas como em um laboratório de projeto. Em vez disso, será uma exploração teórica com apresentação de slides, discussão de conceitos e exercícios para reforçar o aprendizado.

Caso surjam dúvidas durante o processo ou algo não fique claro, haverá um fórum disponível para você abrir questões. Faremos o possível para responder individualmente, mas também contamos com uma comunidade ampla de estudantes, moderadores e instrutores que podem oferecer auxílio.

Conclusão

Portanto, aguardamos sua participação na próxima aula, onde entenderemos o universo da web e nos aprofundaremos na arquitetura de microsserviços.

Conhecendo a arquitetura - Como a Web funciona

Olá, pessoal! Como mencionado anteriormente, abordaremos os padrões de projeto para a arquitetura de microsserviços, explicando como devemos dividir nossos microsserviços, entre outras considerações.

Como funciona a web

No entanto, é fundamental compreender o que são microsserviços na prática antes de discutirmos isso. Para isso, é necessário retroceder e entender o funcionamento da web. Como seria o processo sem microsserviços? Como as tarefas seriam realizadas com ou sem sua utilização? Assim, vamos explorar o funcionamento da web.

HTTP

A internet opera por meio do protocolo HTTP.

Recomendamos especialmente o curso sobre HTTP disponível na Alura para aprofundar nesse tema. Simplificando, o conceito básico por trás do HTTP é que, por meio de um cliente como um navegador, um dispositivo móvel ou qualquer outro dispositivo conectado à internet, é possível acessar diferentes recursos online.

Digamos que abrimos nosso navegador e digitamos alura.com.br na barra de endereços. Quando pressionamos "Enter", nosso navegador atua como cliente e envia uma solicitação para um servidor.

O servidor da Alura, localizado na imagem, recebe e processa essa solicitação, também chamada de requisição. Ele realiza uma série de ações, como verificar se a pessoa usuária está logada, carregar os cursos disponíveis, verificar possíveis promoções e exibir as últimas novidades, entre outras tarefas.

Ele utilizará essa lógica para criar uma resposta, que geralmente estará em HTML se estivermos discutindo a web. Posteriormente, o servidor formatará essa resposta em HTML e a enviará de volta. Quando o cliente a receber, o navegador, por entender HTML, a apresentará de forma organizada como uma página da web. Portanto, resumindo, assim é o funcionamento básico da web.

Aplicações monolíticas

Quanto à construção de aplicações para a web e à programação para ela, é comum lidarmos com diversos clientes, como diferentes navegadores, e até mesmo dispositivos móveis. As requisições desses clientes chegam até nós de diversas formas, muitas vezes por meio de um balanceador de carga, também conhecido como load balancer.

Um servidor web recebe a requisição e a distribui para diferentes servidores, gerenciando a carga conforme necessário. No entanto, para nosso propósito atual, esse é um detalhe secundário, pois o foco está na aplicação em si. Nesse sentido, a aplicação executa uma série de tarefas diversas.

Por exemplo, na Alura, uma aplicação monolítica centralizada poderia lidar com atividades como o cadastro de estudantes e cursos, a gestão de pontos por meio de gamificação na plataforma, o processamento de pagamentos na área financeira, a disponibilização de conteúdos além dos cursos principais, entre outras funcionalidades, tudo integrado em uma única e abrangente aplicação.

Nesse exemplo da imagem, temos uma loja e nessa aplicação da loja, temos, por exemplo, um módulo, um pedaço de código, uma classe, o que for, que cuida do catálogo (Catalog Service) e isso lida com produtos (Product). Temos uma outra parte que lida com pedidos (Order Service). Então, temos aqui o pedido e tem um serviço, tem um módulo, tem uma classe, um pedaço de código que lida com pagamentos (Payment Service).

Então, temos vários módulos (partes ou pedaços de código) que lidam com dados diferentes. E tudo isso é armazenado em um banco de dados. Assim, criamos aplicações monolíticas. Normalmente, é assim que aprendemos a desenvolver aplicações.

Alguns Problemas

• Demoras no deploy;
• falhas podem derrubar o sistema todo;
• 1 projeto = 1 tecnologia.

Porém, essa abordagem tem alguns problemas. Para começar, o deploy disso tudo pode ser demorado. Imagine se o Facebook fosse todo uma aplicação só. E aí, precisamos alterar a forma como as notificações são exibidas. Alteramos.

Agora, todo o deploy de construir o mural, de mostrar sugestões de amizades, tudo isso vai ter que ser reconstruído, passar por todo o processo de deploy, de build, de fazer testes, para só então conseguirmos ter a aplicação em produção.

Essa situação pode resultar em atrasos significativos. Considere o seguinte exemplo na Alura: se o departamento financeiro está integrado ao departamento acadêmico, à gamificação e às promoções, todos dentro de uma única aplicação, qualquer modificação nas regras de pontos da Alura pode potencialmente introduzir um bug que comprometa todo o sistema.

Assim, devido a um problema relacionado à pontuação, que pode ser considerado menos importante, podemos acabar impedindo alguém de adquirir um plano na Alura ou de assistir a um curso. Em um sistema monolítico como esse, uma falha pode ter impacto em todo o sistema, afetando até mesmo áreas não relacionadas à origem da falha. Essa é outra grande desvantagem dessa abordagem.

Um outro ponto é que, normalmente, se temos um sistema monolítico, temos um projeto, então temos uma tecnologia. Claro que existem formas de contornar isso, mas normalmente em uma aplicação monolítica somos presos a uma tecnologia só. E nem sempre a mesma tecnologia vai resolver bem todos os problemas que temos.

Se temos na mesma aplicação uma parte de consultar em tempo real os dados da bolsa de valores, e temos também a geração muito simples de um HTML, vamos ter que fazer essas duas tarefas completamente diferentes com a mesma tecnologia? Sabemos que acessar dados de mercado em tempo real é muito comum o uso de C++, por exemplo.

Já gerar uma simples página da web podemos fazer de forma estática ou usar PHP para buscar alguns dados dinâmicos, enfim, ou várias outras linguagens dinâmicas mais leves, mais simples. Poderíamos escolher tecnologias específicas para cada problema, mas se temos um projeto só, isso se torna muito mais difícil. De novo, claro que existem formas de contornar, mas normalmente somos presos a uma única tecnologia.

Conclusão

Portanto, o processo habitual de desenvolvimento de soluções para a web apresenta algumas falhas. É precisamente quando essas falhas se tornam evidentes que buscamos a solução na arquitetura de microsserviços.

Nesse ponto, já temos uma compreensão do funcionamento da web e das limitações de uma aplicação monolítica. Agora, vamos explorar o conceito de microsserviços, mas isso será abordado no próximo vídeo.

Conhecendo a arquitetura - O que são microsserviços?

Olá, pessoal! Já entendemos como funciona a web, o que é uma aplicação monolítica e alguns dos problemas dessa abordagem. Agora, vamos entender sobre a arquitetura de microsserviços. Entenderemos o que é microsserviços.

O que são microsserviços?

Imaginem aquele mesmo exemplo que vimos de uma aplicação monolítica, onde temos uma loja e nela temos o serviço de catálogo, pedidos, pagamento e podemos ter várias outras coisas. Em uma arquitetura de microsserviços, o que temos é cada uma dessas partes, cada pedaço desse nosso sistema de loja, sendo uma aplicação diferente.

Essa aplicação diferente é o que chamamos de um serviço. A ideia de microsserviços é ter vários microsserviços, ou seja, vários desses serviços muito pequenos que tenham uma responsabilidade muito bem definida, que saibamos exatamente o que cada um dos serviços vai fazer.

Naquele exemplo da loja, podemos ter uma situação em que a loja oferece um serviço de catálogo. Esse catálogo, responsável por lidar com produtos, inclui funcionalidades como cadastro, exibição de produtos e organização dos mesmos. Essas operações são realizadas em um banco de dados dedicado exclusivamente ao catálogo, que abrange produtos, categorias, taxonomia e outros aspectos relacionados à lógica dos produtos.

Por outro lado, para o processo de realização de pedidos, temos um serviço separado especificamente para essa finalidade. Os pedidos são registrados em um banco de dados distinto daquele utilizado para os produtos. Portanto, os dados dos produtos estão em um banco de dados, enquanto os pedidos são gerenciados em outro banco de dados separado.

Caso o sistema de pedidos apresente alguma falha, ainda conseguimos acessar o catálogo de produtos, navegar nas páginas e visualizar o que desejamos comprar. Embora não possamos concluir a compra, podemos continuar navegando. Durante esse período, é possível que o usuário não perceba o problema e tenhamos tempo para resolver a questão.

Às vezes, o serviço do carrinho de compras não está operacional, mas ainda é possível finalizar a compra efetuando um pagamento direto sem adicionar itens ao carrinho.

Assim, podemos ignorar essa etapa se o serviço estiver inoperante, o que nos oferece mais flexibilidade. Este é o ponto que queremos destacar.

A definição formal, que talvez já tenha sido mencionada em alguma aula minha, é algo que gosto de apresentar e analisar mais detalhadamente. No entanto, a definição atual é interessante e faz sentido. Posso lê-la rapidamente para você.

Microsserviços são uma abordagem arquitetônica e organizacional do desenvolvimento de software, na qual o software consiste em pequenos serviços independentes que se comunicam usando APIs bem definidas. Esses serviços pertencem a pequenas equipes autossuficientes.

Aqui temos alguns pontos interessantes para considerar. Primeiramente, é natural pensar em como efetuar um pedido e armazená-lo em um banco de dados se não possuímos todos os detalhes dos produtos sendo comprados. Essa é a questão central. Os microsserviços, para construir uma aplicação completa, precisam estar interconectados.

Dessa forma, o microsserviço responsável pelos pedidos precisa estar ciente do microsserviço do catálogo de produtos. Ele não precisa conhecer todos os detalhes do banco de dados, a lógica completa ou a taxonomia dos produtos. Entretanto, ele precisa saber como acessar o endpoint para obter os detalhes de um produto ou pelo menos uma identificação para armazenamento.

Quando precisamos recuperar os dados desse pedido, teremos as informações necessárias sobre o produto para consultar no catálogo. Assim, os serviços se comunicam entre si.

Essa comunicação pode se dar de várias maneiras. Por exemplo, utilizando o protocolo HTTP. Um serviço pode enviar solicitações para outro por meio do HTTP ou utilizando APIs REST, ou até mesmo protocolos mais complexos e específicos para esse propósito, como o GRPC ou similares. Portanto, a comunicação entre os microsserviços é importante e ocorre com frequência, sendo necessário estabelecer essa comunicação.

Outro ponto mencionado nessa definição formal é que esses serviços são operados por equipes autossuficientes. Isso significa que é possível ter tranquilamente uma equipe dedicada ao serviço de produto, com sua própria tecnologia, conjunto de ferramentas, gestão e metodologia ágil, enquanto outra equipe cuida do projeto de pagamentos, utilizando uma tecnologia e metodologia diferentes.

Conclusão e Próximos Passos

Essa abordagem proporciona grande flexibilidade ao nosso projeto por meio dos microsserviços. Entretanto, é importante discutir as vantagens e desvantagens, o que faremos no próximo vídeo.

Sobre o curso Microsserviços: padrões de projeto

O curso Microsserviços: padrões de projeto possui 81 minutos de vídeos, em um total de 38 atividades. Gostou? Conheça nossos outros cursos de Arquitetura em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Conhecendo a arquitetura
• Separando serviços
• Integrando serviços
• Lidando com dados
• Operações