Microsserviços: explorando os conceitos

Arquitetando microsserviços - Apresentação

Olá, pessoal! Sejam muito bem-vindos à Alura! Eu sou o Vinicius Dias e vou guiar vocês neste treinamento sobre microsserviços.

Neste treinamento nós vamos nos aprofundar um pouco mais, visto que você já deu uma olhada no nosso treinamento de padrões de microsserviços. Lá nós já entendemos um pouco da arquitetura de microsserviços e o que são microsserviços. Neste treinamento, nós vamos mergulhar um pouco em cada uma das áreas que cobrimos lá.

Então vamos nos aprofundar neste assunto, começando pela parte de arquitetar microsserviços em si. Nós vamos entender quais são os componentes que compõem realmente cada um dos microsserviços.

Depois vamos falar sobre o contrato que os microsserviços expõem, as famosas APIs. Nós também vamos entender e revisar um pouco sobre como identificar quando acaba um microsserviço e começa outro e como separar microsserviços.

Eu acho que antes de continuar falando sobre o que vamos conversar neste treinamento, é importante citar que por várias vezes eu vou dizer que programação é uma pequena parte do desenvolvimento de uma arquitetura de microsserviços. Se você sabe criar APIs e lidar com sua linguagem de programação de alguma outra forma, você já está pronto para codificar para microsserviços.

Os problemas que uma arquitetura de microsserviço traz não estão diretamente relacionadas com programação. A parte de infraestrutura está muito ligada com a arquitetura de microsserviços.

Você precisa entender, bem como separar esses serviços em contêineres diferentes e vamos falar sobre contêiner. Você precisa entender pelo menos o que é um load balancer e o que é um proxy, para lidarmos com algumas técnicas como cache, circuit breaker e service discovery. Você precisa entender o que é DNS.

Então, repare que eu já falei vários nomes aqui, todos relacionados à infraestrutura de alguma forma. Então durante o treinamento eu também vou citar outros cursos aqui da Alura para você se aprofundar em cada uma das partes na prática.

Então esse treinamento vai ter bastante bate-papo, nós vamos trocar bastante ideias na teoria, para você entender princípios.

Depois de entendermos da parte de como arquitetar, nós vamos falar do processo de criação de serviços. O que precisamos pensar antes de criarmos? E na hora de realmente criarmos, como podemos fazer de forma um pouco mais ágil? O que pode facilitar nossa vida?

E depois que criamos um ou vários microsserviços, como eles podem se comunicar? O que é a tal de comunicação síncrona e assíncrona? Quando usaremos cada uma? Quais os problemas elas geram e como resolver cada um dos problemas?

Depois, nós vamos falar bastante sobre segurança. Aí nós vamos falar de segurança como um todo, no geral - segurança em transporte, security at rest, ou segurança em repouso, no destino; como você preferir traduzir. Nós vamos falar sobre autenticação e autorização, vamos falar de segurança em rede. Vamos conversar sobre defense in depth, que é a segurança, a defesa, em profundidade.

No final, nós vamos bater um papo sobre como lidar com entrega, como fazer o nosso deploy e como distribuir os nossos microsserviços por aí - tanto em ambientes de desenvolvimento, staging, homologação, produção e onde mais for.

Então vai ser um conteúdo bastante rico. Eu espero que você aproveite. Caso você fique com alguma dúvida, não hesite: você pode abrir uma dúvida lá no fórum! Eu tento responder pessoalmente sempre que possível, mas quando não consigo responder, nós temos uma vasta comunidade de alunos, moderadores e instrutores. Com certeza alguém vai conseguir te ajudar.

Mais uma vez, seja muito bem-vindo! E chega de falação, vamos para o próximo vídeo para começarmos a conversar sobre como arquitetarmos microsserviços!

Arquitetando microsserviços - Componentes de um microsserviço

E aí, pessoal! Bem-vindos de volta! Então vamos nos aprofundar neste assunto de microsserviços. Vamos bater um papo sobre microsserviços de forma um pouco mais aprofundada do que o que conversamos nos padrões de microsserviços.

Então, vamos lá! Nós já sabemos o que é um microsserviço, mas neste capítulo nós vamos começar a falar sobre como arquitetar microsserviços. Então vamos conversar um pouco sobre esse processo de arquitetar microsserviços - e como eu comentei, nós já sabemos o que é um microsserviço.

Nós sabemos que um microsserviço é alguma aplicação ou algo parecido com uma aplicação que tenha acesso a determinados dados. É um serviço pequeno que se comunica com outros etc.

Sem falarmos de definições formais aqui, só que pensando nessa definição de um microsserviço, o que compõe? O que eu preciso ter dentro de um único microsserviço para que ele seja realmente funcional, usual e utilizável? Então, vamos conversar sobre o que compõe um microsserviço, o que um microsserviço tem dentro dele.

Nós sabemos que um microsserviço é dono de determinados dados e ele é responsável pelo processamento desses dados ou informações. Então o questionamento é: será que um microsserviço pode ser visto como um único processo rodando em único servidor?

Essa terminologia de processo é bastante conhecida por quem já testou os The Twelve Factor App, a metodologia de aplicação de doze fatores. Mas assim, sem pensarmos muito nesse conceito também, um microsserviço é uma única aplicação rodando em um servidor só? Será que isso já compõe um microsserviço?

Vamos pegar um exemplo partindo do mais simples e indo incrementando um pouco devagar. Então nós temos uma aplicação, e essa aplicação precisa se comunicar com algum banco de dados. É comum que microsserviços acessem dados. Então nós já começamos tendo mais do que um único processo, uma única aplicação.

A nossa API, vamos chamar assim, a nossa aplicação principal, precisa se comunicar com um servidor de banco de dados - e via de regra, esses dois já estão em servidores diferentes.

Então deixe-me pegar aqui o apontador. Eu tenho o meu código em um servidor e o meu banco de dados em outro servidor. Até porque eles precisam ser otimizados para coisas diferentes.

Talvez o meu banco de dados precise de muita memória, já a minha aplicação precisa de mais processamento e não tanta RAM. Enfim, o meu servidor de banco de dados com certeza vai precisar de discos rígidos mais otimizados. Então nós separamos em servidores diferentes - mas não para por aqui, nós já temos dois servidores, mas isso ainda pode ser incrementado.

Por exemplo: se eu precisar replicar minha aplicação. Imagine que este ponto de entrada do meu microsserviço, ou seja, a minha API, a minha interface com o mundo externo, receba muitas requisições.

Então, eu preciso dividir o trabalho em vários servidores, em várias máquinas, e isso vai ser controlado por um load balancer. De novo, fazendo analogia com os cursos que temos aqui na Alura, com Nginx nós podemos criar load balancers e distribuir a carga entre várias APIs.

Então, dessa forma, nós já temos aqui só nesse cenário simples quatro servidores dentro do mesmo microsserviço. Três servidores de aplicação, rodando a nossa API e um servidor de banco de dados, que vai conter os nossos dados.

Mas e se eu também precisar replicar os meus bancos de dados? Ou fazer particionamento deles? E se eu precisar ter um banco de dados muito otimizado para escrita e outro muito otimizado para leitura? Talvez a minha aplicação tenha muita leitura, eu recupere muitos dados e não escreva tanto.

Então eu posso separar essas operações, ou simplesmente fazer réplicas mesmo para back-up etc., para manter a segurança. Então aqui eu já tenho cinco servidores: dois de banco de dados e três de aplicações.

Só que também não para por aí! O microsserviço pode realizar tarefas além do que a sua interface pública permite e além do que serviços externos podem solicitar para ele fazer.

Ele pode ter, por exemplo, tarefas agendadas, um processamento. Imagine que no final de todos os dias você pega todas as imagens que foram enviadas e faz uma otimização nelas - que é um processo demorado.

Ou acontece algum evento na sua aplicação e você precisa ter algum consumidor ou um processador de mensagens que vai pegar esse evento. Quando ele encontrar esse evento, que não precisa ser na hora que o evento aconteceu, ele vai pegar isso e fazer o processamento necessário.

Então existem vários componentes em um microsserviço. Só que neste nosso exemplo simples, nós temos sete servidores. Nós temos dois de banco de dados, nós temos três de aplicação, nós temos um de tarefas agendadas e um processador de mensagens. Então repare que muitas coisas podem compor um microsserviço.

É importante citar que microsserviços são muito mais que só programação, porque se você estuda aqui na Alura, você muito provavelmente já sabe criar APIs. Também tem cursos aqui para você gerenciar bancos de dados. Existem cursos para você trabalhar com sistemas operacionais, agendar tarefas, existem cursos de mensageria e de serviços de stream para você saber consumir esses dados e publicar esses dados.

E quando você trabalha com microsserviços, você une todos esses conhecimentos para aplicar em uma arquitetura um pouco mais complexa, que tem as vantagens e desvantagens que nós já falamos.

Então vamos dar uma olhada rápida em um exemplo da vida real. Essa aplicação, eShopOnContainers, é uma aplicação de e-commerce fictícia que está disponível na internet justamente para o estudo de microsserviços. Então eles disponibilizam essa imagem, essa arquitetura aqui. Isso é constantemente atualizado com novas tecnologias etc.

Então, aqui eles mostram tecnologias usadas principalmente em aplicações Microsoft, então tem .NET, tem o TypeScript, tem C#, enfim. Aqui nós temos diversos microsserviços fazendo tarefas diferentes.

O nosso microsserviço de pedidos tem uma API, ou seja, ele tem aqui um processo rodando a API - que pode ter, na verdade, vários servidores e nós não sabemos - e tem um outro processo, que são de tarefas de plano de fundo, algo que você não precisa executar na hora que seu microsserviço é chamado.

Então repare que esses dois se comunicam com o banco de dados, e esse banco de dados também pode estar replicado. Então, aqui nós já temos uma visão um pouco mais real de como seria um microsserviço com mais componentes.

Nós vamos passar por essa imagem em outros momentos para falarmos um pouco mais dela, mas basicamente nós já começamos a entender que um microsserviço é composto de vários componentes.

Está entendida esta parte? Agora vamos falar um pouco sobre o contrato entre vários microsserviços, mas no próximo vídeo!

Arquitetando microsserviços - Contratos de microsserviços

E aí, pessoal! Bem-vindos de volta! Nós já nos aprofundamos um pouco falando sobre componentes de um microsserviço. Nós sabemos que um microsserviço isolado não é uma aplicação muito utilizável para o usuário final, não é uma aplicação completa que tenha tanto valor assim.

Um microsserviço, por via de regra, é uma parte de uma aplicação maior, ele é uma micro parte de uma aplicação maior. Então nós precisamos ter comunicação entre microsserviços, de alguma forma.

E nós vamos falar bastante sobre comunicação em um capítulo posterior. Só que aqui, quando estamos arquitetando microsserviços, quando estamos pensando em quais microsserviços vão existir e o que cada um vai ter, nós já temos que ter em mente que existem contratos entre microsserviços.

Quando um microsserviço expõe uma API, quando ele expõe uma interface pública de comunicação com a sua aplicação, ele está assinando um contrato. Ele está dizendo: “olhe só, cliente que vai acessar a minha API, eu estou me comprometendo a te fornecer estas funcionalidades desta forma aqui”.

E isso pode ser a partir de uma documentação, de testes automatizados entregue ao usuário ou testes de usuário em si. Enfim, de alguma forma ele vai expor isso. Com esse contrato exposto, nós temos uma responsabilidade. Eu preciso manter isso funcionando independentemente do que eu precise fazer aqui dentro.

Se eu vou mudar de linguagem de programação, se eu vou mudar de banco de dados que eu estou utilizando ou se eu vou trocar de servidor próprio para um servidor em cloud, isso não importa. Nós temos que manter o nosso contrato. Nossa interface tem que continuar funcionando com o cliente.

Mas como eu vou manter a minha API sempre atualizada, com novas funcionalidades? O meu projeto precisa de atualizações de tecnologia, ou atualizações de negócio. Como que eu vou manter essas atualizações constantes, se eu não posso quebrar esse contrato? Se a minha API não pode ser modificada?

Aqui nós temos algumas formas de mantermos esse contrato e algumas técnicas de mantermos esse contrato e a evolução.

Primeiro, as técnicas óbvias que eu nem coloquei no slide são: se você vai ter alguma atualização técnica no seu sistema ou uma atualização tecnológica, não sei nem se o termo correto seria esse - mas imagine que você vai atualizar para uma nova versão da linguagem, do framework, de alguma biblioteca. Isso, naturalmente, com microsserviços ou não, já deve ser transparente para a sua API, para o seu cliente externo.

Isso, naturalmente, não deveria afetar o funcionamento. Se você atualiza uma dependência sua, você precisa fazer com que a sua API continue funcionando com essa nova versão de dependência. Isso aqui é o mínimo que nós esperamos.

Agora, algumas outras coisas que podemos fazer é termos apenas modificações aditivas. O que isso quer dizer? Somente adicionarmos funcionalidades, nunca modificarmos como uma funcionalidade é feita ou consumida e nunca removermos funcionalidades.

Essa é uma abordagem válida e muito utilizada. Embora pareça um pouco restritiva. Você me diz: “Poxa, Vinicius, quer dizer que eu nunca posso remover um endpoint?” É uma abordagem um pouco restritiva, mas é bastante válida!

Então você sempre vai criar novos endpoints. Como assim? Além de você fazer um pedido, agora você vai poder também consultar o status desse pedido. Então, ao fazer o pedido você não vai devolver direto o status dele, modificando o contrato de retorno com uma resposta que chegou desta API. O que você vai fazer é criar um novo endpoint.

Nós também podemos adicionar novos campos em cada recurso. Então meu pedido precisava de uma identificação do cliente, o valor do produto, a quantidade do produto e a identificação do produto em si. Mas agora, eu quero enviar também o desconto.

Esse campo precisa ser opcional, porque alguns podem não passar esse campo, já que o seu contrato original não fornecia esse campo. Então você pode, por exemplo, assumir que ao não passar esse campo, não tem desconto.

Então novos campos podem ser adicionados, só que de forma opcional. Até porque se você recebe um campo a mais, não é grande problema. Se você manda um campo a mais para o seu cliente, não é um grande problema. Mas se você passa a esperar algo que não chega do cliente, aí nós temos um problema.

Então, campos opcionais não são um problema, são uma funcionalidade aditiva. Uma modificação aditiva.

Nós também podemos ter versionamento de APIs - isso eu acredito que seja a técnica mais comum. Como funciona o versionamento de APIs? Imagine que você tem algo para fazer pedidos. Você tem uma API RESTful para fazer pedidos e quando você faz o post para /pedidos, você cria um novo pedido.

Ao invés de ser /pedidos, você vai criar /v1/pedidos. E aí quando a interface, quando o contrato de criar um pedido for modificado, for algo que você não pode fazer só uma modificação aditiva, for algo vai realmente mudar nesse contrato - você vai criar um novo endpoint /v2/pedidos. E neste v2 você pode, inclusive, ter uma aplicação nova em outro servidor, com outra tecnologia - e o seu cliente não precisa saber disso.

Caso ele escolha utilizar essa nova versão, ele vai consultar a nova documentação e vai se adequar. Só que a primeira versão, aquela /v1/pedidos, precisa continuar funcionando exatamente igual, sem nenhuma quebra nela. Então você vai ter duas APIs sendo mantidas ao mesmo tempo.

“Vinicius, parece bastante trabalhoso!” E realmente é, pode trazer problemas de manutenibilidade! Às vezes você adiciona, tem uma modificação aditiva em uma e você tem que replicar para outra. É trabalhoso, mas é algo fácil para o cliente.

O cliente decide se vai se atualizar ou não. Você pode dar um aviso para o cliente falando: “olhe só, estamos lançando essa nova versão, você tem um ano para se atualizar”. Durante um ano nós vamos manter essa versão 1 ainda de pé e funcionando.

E é muito comum que quando temos que fazer alguma modificação, principalmente quando trabalhamos com uma equipe com todos os microsserviços, nós modificamos um microsserviço.

Para testarmos rapidamente, nós vamos no cliente deste microsserviço, ou seja, o serviço que utiliza ele e modificamos a chamada também, para fazer funcionar e para garantirmos que está tudo OK.

Nisso, nós não mandamos a modificação desse microsserviço para o cliente, nós fazemos a alteração só no microsserviço que está fornecendo essa API. Quando isso vai para produção, quando acontece um deploy, o microsserviço do cliente não foi atualizado e nós temos nossa aplicação quebrada.

Então, para evitar esse tipo de coisa é bastante comum, principalmente em empresas maiores, que nós tenhamos equipes específicas para cada microsserviço. Então o microsserviço de pedido vai ser feito por uma equipe, o de carrinho vai ser feito por outra equipe e o de catálogo vai ser feito por outra equipe.

E assim, se eu com um microsserviço de catálogo preciso, por algum motivo, de uma nova funcionalidade no microsserviço de carrinho, eu preciso adicionar temporariamente ao carrinho a partir do meu catálogo. Eu vou solicitar formalmente para equipe de carrinho para que eles desenvolvam essa funcionalidade e, a partir disso, eu poder fazer a chamada no meu catálogo.

Então não ocorre esse risco de modificar um microsserviço e esquecer de modificar algum cliente dele e assim em diante.

Então, essas são algumas técnicas para tornarmos nossos microsserviços realmente independentes. Um microsserviço precisa ser independente. Nós temos que poder atualizar ele sem nenhum problema, nós temos que poder modificar a tecnologia dele sem nenhum problema.

Nós temos que poder fazer o deploy dele individualmente sem problema. Ele realmente precisa ser independente. Só que, tornando-o independente, nós precisamos ainda assim manter os nossos contratos.

Falando agora um pouco ainda sobre essa parte de comunicação e de vários microsserviços, como podemos identificar a barreira entre um microsserviço e outro? Quando acaba um microsserviço e começa outro?

Nós já batemos um papo legal sobre isso no treinamento de padrões de microsserviços, mas como recordar é viver, vamos falar um pouco desse assunto e dessas técnicas, no próximo vídeo.

Sobre o curso Microsserviços: explorando os conceitos

O curso Microsserviços: explorando os conceitos possui 119 minutos de vídeos, em um total de 43 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:

• Arquitetando microsserviços
• Criação de serviços
• Como se comunicar
• Segurança de serviços
• Lidando com o deploy