Opa! Tudo certinho?

Segue uma lista de tópicos que acho que são interessantes para trabalhar em uma arquitetura de microserviços.

1. Entendendo HTTP por baixo dos panos

É sempre bom começar pelas bases!

HTTP é um dos protocolos que é usado para buscar recursos em uma rede numa relação de cliente-servidor, essa rede pode ser a própria internet como também a rede interna onde os microserviços estão hospedados.

É bem provável que os microserviços de uma solução usem HTTP para comunicar entre sí, se você tiver um bom conhecimento de como o protocolo funciona vai te dar clareza ao dar manutenção em APIs já existentes e também para desenvolver novas.

Tem uma grande riqueza de informação na internet sobre esse assunto, gosto do guia da MDN(link). Mas se preferir na plaforma Alura tem um curso só sobre isso(link).

2. Aprendendo SpringBoot

Spring é de longe o framework de desenvolvimento web mais popular do Java, tem uma infidade de módulos de extensão para quase qualquer tipo de solução que você queira desenvolver. Por ser muito extenso, aconselho a focar nos módulos que tem a maior chance de você encontrar no dia-a-dia.

Essa é como é dividida a o framework base do spring, ou seja, sem extensões, a lista a seguir são os itens mais provaveis de encontrar em qualquer projeto que use spring:

• Web (MVC/Remoting) (Construindo APIs)
  • Web
  • Servlet
• Data Access/Integration (Persistência de dados)
  • JDBC
  • ORM
  • Transactions
• Core Container (Utilidades e padrões de projetos)
  • Beans
  • Core

De novo, na Alura, tem muitos cursos de Spring e em geral são bem rápidos, e se seguir os exercícios certinho você vai implementar um projetinho usando o que é ensinado durante as aulas.

Mas a documentação oficial é mais eficiente para te ensinar e o melhor - de graça.

3. Cache

Ir no banco de dados buscar as algum dado toda vez que alguém faz uma requisição na sua API pode ser bem ineficiente, especialmente se for um dado que muda pouco.

Ai que entram estratégias de cache usando soluções como o Redis e Memcached onde é possível guardar esses dados que mudam pouco e entregar numa velocidade muito superior que o um banco dados entregaria.

Quase toda solução respeitável usa cache em algum nível, seja distribuido ou local.

4. Mensageria

HTTP não é o único caminho para realizar a comunicação entre microserviços, na verdade, dependendo do caso de uso, não é nem adequado.

Para nossa infelicidade, esses casos de uso são bem comuns, normalmente são operações assíncronas que demoram bastante tempo(do ponto de vista computacional) para ser concluídas.

Ex.1: Processamento de um pagamento em ecommerce
Ex.2: Processamento de arquivos grandes (pense em todo o processamento de um vídeo depois do upload no youtube!)

Tem outros casos de uso, talvez até melhores que esse que usei de exemplo, mas foi o que me veio na cabeça xD

Nesses exemplos que citei, um sistema de mensageria ajudaria a reportar o estado dessas operações assíncronas pesadas, possibilitando as informar as partes interessadas sem precisar pendurar uma ou muitas conexões HTTP nos servidores.

Não só isso, poderíamos controlar o fluxo dessas operações caras e demoradas para não consumir muitos recursos dos nossos servidores, e em tempo, processar todas elas sem prejudicar a performance e responsividade da nossa solução.

Há várias ferramenta de mercado que ajudam a construir esse tipo de arquitetura baseada em eventos, acredito que as mais populares delas sejam o Apache Kafka e RabbitMQ, ambas disponíveis na AWS junto com os serviços SQS e SNS que tem funcionalidades similares.

Acho que para um visão geral é isso, espero que ajude!