A ideia deste artigo é servir como um guia de boas práticas para construção de uma arquitetura de microservices realmente profissional, seja lá qual tecnologia estiver utilizando. Apesar disso, serão dadas dicas adicionais relacionadas especificamente à plataforma Node.js que lhe serão muito úteis caso use essa tecnologia.
Caso você nunca tenha desenvolvido microservices em Node.js antes, esta série de artigos lhe dará uma boa base, bem como o meu curso onde ensino essa arquitetura em vídeo aulas.
As dicas são:
- Tente alcançar a Glória do REST
- Use um serviço de configuração
- Geração automática do código cliente
- Continuous Delivery
- Monitoramento e Logging
- API Gateway
Vamos lá!
#1 – Tente alcançar a Glória do REST
A imagem abaixo ilustra o modelo de maturidade do Leonard Richardson, um famoso desenvolvedor de APIs que programa desde os 8 anos de idade e tem vários livros publicados.
Neste modelo o objetivo é ir do Pântano do POX (Plain-Old XML) até a Glória do REST que basicamente é ter uma web API RESTful. Quanto mais RESTful for sua web API, mais próxima da Glória ela estará e consequentemente seus microservices estarão melhor desenvolvidos.
Martin Fowler resume este modelo da seguinte forma:
- Nível 0 (POX): aqui usamos HTTP para fazer a comunicação e só. Não aproveitamos nada da natureza da web exceto seu túnel de comunicação, sendo que o envio e recebimento de mensagens baseia-se em XML-RPC ou SOAP (ambos POX).
- Nível 1 (Recursos): aqui evoluímos a API através da segregação dos recursos em diferentes endpoints, ao contrário do nível 0 onde tínhamos apenas um endpoint com tudo dentro, respondendo de maneira diferente conforme os parâmetros no XML de envio.
- Nível 2 (Verbos): aqui finalmente passamos a usar o protocolo HTTP como ele foi projetado, fazendo com que o verbo utilizado na requisição defina o comportamento esperado do recurso. Geralmente 99% das web APIs do mercado param por aqui, como a maioria dos tutoriais de web APIs aqui do blog aliás.
- Nível 3 (Hipermídia): este é o último obstáculo a ser alcançado para alcançar a Glória do REST e envolve a sigla HATEOAS que significa Hypertext As The Engine Of Application State. Aqui, o retorno de uma requisição HTTP traz, além do recurso, controles hipermídia relacionados ao mesmo, permitindo que o requisitante saiba o que fazer em seguida, ajudando principalmente os desenvolvedores clientes.
Embora este modelo não seja uma verdade universal, é um excelente ponto de partida para deixar seus microservices RESTful. E se você usa Java, sugiro usar o Spring HATEOAS para cuidar do último quesito de Hypermedia Controls.
#2 – Use um serviço de configuração
Aqui a dica é usar o Consul, tanto no Java quanto no Node, para lidar com dezenas de microservices, cada um com as suas configurações personalizadas e com as inúmeras variações para cada ambiente (dev, homolog, prod, etc).
O Consul não serve apenas como um repositório de chave-valor para gerenciar configurações de maneira distribuída e real-time (sim, você nunca mais vai ter de fazerd eploy apenas pra mudar um config), mas também para segmentação de serviços (garantindo comunicação segura entre os serviços) e service discovery, um dos maiores desafios de arquiteturas distribuídas em containers.
#3 – Geração automática de código cliente
O código cliente para consumir microservices é sempre algo pouco criativo que faz sempre as mesmas coisas usando as mesmas bibliotecas líderes de mercado, certo?
Sendo assim, a recomendação é usar algum gerador de código client-side como o do Swagger, que inclusive suporta múltiplas linguagens de destino.
#4 – Continuous Delivery
Quando você constrói uma arquitetura com dezenas de micro serviços e quer agilidade no deploy só há uma alternativa recomendada hoje em dia: containerização de serviços.
Usar Docker com Jenkins é a dobradinha mais usada atualmente para ganhar eficiência no pipeline de deploy. Realmente não há como fugir de ao menos conhecer essa dupla e não tem como falar de microservices sem falar de CD.
Pretendo fazer tutoriais no futuro de uso de Jenkins e Docker, uma vez que cada mais estas skills de DevOps tem sido necessários para se manter competitivo no mercado de trabalho hoje em dia, pelo menos em posições de liderança técnica. Sendo assim, aguarde um post futuro sobre Continuous Delivery com Jenkins e Docker.
#5 – Monitoramento e Logging
Quando você tem apenas uma web API para cuidar, é muito simples usar os logs do seu servidor web para saber o que aconteceu com sua aplicação e monitoramentos simples como o PerfMon do Windows ou até um top tosco no console Unix. Monitoramentos web como StatusCake e Pingdom também são bem populares, pingando em endpoints de health-check.
Mas e quando você tem uma ou mais dezenas de microservices? Como gerenciar o monitoramento e o logging de cada um deles, principalmente considerando ambientes dinâmicas como nuvens containerizadas com auto scaling?
A questão é: independente do ‘como’, você terá de dar um jeito de ter uma solução profissional de monitoramento e logging, isso é vital para garantir a disponibilidade da sua arquitetura e responder rapidamente a incidentes. Uma dica importante é ter um bom APM, como o Zipkin, que é uma boa opção open-source.
#6 – API Gateway
Já falei muito disso no artigo em que ensino como criar uma solução em Node.js para API Gateway. Soluções mais profissionais e corporativas como WSO2 e Zuul são mais indicadas nos casos de arquiteturas muito robustas, embora o Netflix tenha criado a sua própria solução em Node.js.
A questão é que você tem de ter uma camada antes dos seus microservices para acesso externo. Não apenas por uma questão de segurança mas para uma questão de agregação dos dados dos diferentes mcroservices que compõem a resposta de uma requisição, garantindo maior performance e usabilidade no lado do cliente.
Estas foram 6 dicas de como tornar sua arquitetura de microserviços mais profissional. Uma sétima dica muito útil diz respeito à como refatorara sua aplicação monolítica em microservices, mas essa era muito grande e resolvi escrever um artigo inteiro sobre o assunto.
Até a próxima!
Curtiu o post? Então clica no banner abaixo e dá uma conferida no meu livro sobre microservices com Node.js!
Olá, tudo bem?
O que você achou deste conteúdo? Conte nos comentários.
Fala Luiz blz?
Cara, eu tenho estudado bastante em construir aplicações com micro serviços e com API gateway. Atualmente uso muito a digital ocean pras minhas aplicações. Porém pelo que vi, esse modelo é muito caro de manter, ainda mais que cada dia que passa os softwares vão ficando mais baratos por causa da concorrência.
Como fazer ms sem aumentar muito o custo comparado a um monolito?
Micro serviço é mais caro pois é mais escalável. Como toda solução para escala, só deve adotar quando fizer sentido escalar, quando for necessário. Caso contrário seu desenvolvimento será mais caro, bem como a infra, desde o primeiro dia de projeto.