O Macro de Microserviços

Desde 2013, quando comecei a estudar Nodejs, conheço o conceito de microserviços e desde então vem se popularizando cada vez mais.

Pelo nome já sabemos a definição, um microserviço é um serviço bem pequeno, pequeno porque o microserviço só deve ter uma responsabilidade e deve ser especialista nesta responsabilidade.

Vamos usar como exemplo a funcionalidade que a maioria dos sistemas tem, a autenticação. Se eu fosse fazer um micro serviço de autenticação, claro a única resposabilidade seria autenticar usuários, e os métodos que criaria para este serviço seria:

  • Cadastro;
  • Login;
  • Verifica sessão;
  • Mudar senha;
  • Logout;
  • Recuperar senha;

Vamos supor que este serviço de autenticação seja usado em um sistema que as pessoas possam preencher seu perfil com mais dados como dados de contato e endereço. Mas observe que a funcionalidade de perfil é diferente de autenticação, então, eu criaria um serviço diferente, especialista em perfil e o único método dele seria “Editar Perfil”. Dentro deste método teria todo tratamento necessário para cada input que o usuário poderia inserir.

Com estes dois microserviços podemos levantar outras dúvidas pertinentes ao assunto:

Como trato sessão com vários microserviços?

Na verdade a interpretação de sessão deixa de ser aquela sessão que criamos no servidor, e passa a ser mais a nível conceitual. Basicamente para microserviços devemos pensar em dois tipos de autenticação, uma autenticação entre microserviços e outra aunteticação entre o front-end e o back-end.

Sabe aquela chave que você gera no Facebook Developers ou no Google Console? É um autenticação entre serviços, geralmente é usado o Oauth2, de uma googada para entender a fundo.

Para front-end, é muito comum a tokenização. Imagine o front-end em Angular ou algo parecido e o back-end com um monte de micro-serviços em restful(apis em JSON). Lembra aquele método do serviço de autenticação chamado verifica sessão, pois bem, todo serviço precisa ser autenticado, como o Perfil, vai precisar fazer uma requisição em Autenticação->Verifica Sessão, e a cada verificação que o token esteja correto o serviço Verifica Sessão deve gerar um novo token para que o anterior seja invalidado e usado apenas uma vez.

Sim o serviço de autenticação é um dependência de outros serviços e precisa ser parrudo neste cenário.

Eles tem dependências entre eles?

O ideal é um microserviço tenha o mínimo de dependência, logo, o ideal é que cada serviço funcione sozinho, mas as vezes não tem como fugir.

Como os serviços vão se comunicar?

Com APIS em restful, tudo foi pensado para manter as apis organizadas e para ter um bom manuseio quando falamos de novas versões de serviços, de manutenção e ciclo de vida de uma api. Então se afundo em restful, os detalhes são importantes.

Cada um tem seu front-end?

Nãooo, nenhum serviço tem front-end, tem apenas apis em restful e um front-end 100% desacoplado de qualquer back-end consome estas apis ok?? É lei.

Como monitoro estes microserviços se precisar rastrear algum bug?

Do mesmo jeito que você monitoraria uma aplicação monolítica. Tem gente que fala é mais difícil, tem gente que fala que é mais fácil, na pratica, na minha opinião, da na mesma, na aplicação monolítica tem milhares de linhas para achar um bug, no microserviço não acontece isto, mas você pode ter vários serviços para vasculhar. Mas independente do microserviço, o que vai te ajudar é ter uma bom software de monitoração como o Newrelic, Dynatrace, e tudo que os serviços de cloud já entregam.

Preciso de rastreabilidade, trilha de auditoria, cada microserviço precisa ter o seu?

Vamos antes só pontuar sobre o log da aplicação, para log da aplicação, claro, cada microserviço vai ter o seu. Agora sobre o log de rasteabilidade, das requisições que ocorreram em cada microserviço, acredito que o melhor seja ter um microserviço somente para log de rastreabilidade, este micro serviço precisa ser parrudo e sugiro usar ele somente em áreas que o usuário precisa estar logado, nas demais talvez não faça tanto sentido. Para todos os microserviços que podem ficar dependente deste microserviço de log, a sugestão é que toda vez que um microserviço for salvar um log neste microserviço de log é seja de maneira assincrona, assim fica ágil.

Um banco de dados para cada microserviço?

Um schema para cada micro serviço sim! Esta não é lei, mas é quase uma lei. Com microserviço, a maneira de pensar muda, geralmente em aplicação monolítica é comum começar a desenvolver pela modelagem do banco, em micro serviço este não é caminho, se não você pode modelar algo relacional, e quando falamos de algo relacional é um mistura de responsabilidades, e com microserviço a ideia principal é exatamente separar as responsabilidades. Não vá pela ideia de criar um schema com tabelas independentes dentro dela, pois o desenvolvedor pode cair, e acontece, cair na tentação de um micro serviço acessar tabelas de outros micro serviços, então evite qualquer vinculo que pode facilitar ma programação orientada a gambiarras.

E quando eu apagar um registro em um microserviço, como fica os dados residuais em outros microserviços?

A boa prática é que seu sistema não apague nada, raras as exceções, a dica que dou é mudar o status do registro ao invés de apagar. Portanto imagine que você precise apagar um usuário e tudo referente a ele, então o mais simples é desativar o usuário, assim você garante que ele não loga mais e fica salvo tudo que aquele usuário fez, pois no futuro você pode precisar destas informações.

By | 2018-03-04T08:21:56+00:00 04/03/2018|Programação|0 Comentários

Sobre o Autor:

Com mais de 20 anos de experiência em internet, consolidou uma plataforma para as imobiliárias se tornarem online, além disso, ele traz aqui aqui as melhores estratégia de marketing para sua imobiliária ter presença na internet.

Comentar Aqui