Microserviços – conceitos e tecnologias envolvidas neste estilo arquitetural de sistemas – Parte 2

Dando continuidade ao meu artigo anterior vamos continuar falando sobre microserviços, ou pelo menos o que venho aprendendo sobre esse tema em meus estudos. Se por acaso não leu ainda a primeira parte do meu artigo corre lá está disponível neste link.

Como mencionado na primeira parte, vamos falar de alguns temas que rodeiam o conceito de microserviços, no post anterior falamos sobre:

  • Quais são as vantagens e desvantagens em sistema monolíticos;
  • Quais são as vantagens e desvantagens em Microserviços;
  • Devo migrar meus sistemas para Microserviços?

Hoje vamos passar pelos seguintes conceitos:

  • Conceitos sobre Api Gateway;
  • Diferença entre Api Gateway e Api Manager;
  • Como trabalhar com autenticação;
  • Comunicação entre Microserviços;

Conceitos sobre API GATEWAY

Gosto de pensar no Api Gateway como um pattern de desenvolvimento, ele é explicado com detalhes na página do microservices.io. É utilizado no que no mercado é conhecido como BFF – Backends for FrontEnds que consiste basicamente em criar serviços de back-end separados para serem consumidos por aplicativos front-end especificos ou interfaces. Para distribuir serviços será necessário uma ferramenta que implementa Api Gateway.

Um Api Gateway nada mais é do que uma camada antes dos seus microserviços e é responsável por muitos pontos dos quais posso elencar alguns:

  • Ponto único de entrada – suas API’s vão estar centralizadas em um só ponto para serem consumidas pelos clientes;
  • Filtragem de dados na entrada – pode redirecionar a chamada de sua API para o local correto, baseado nos mais diferentes parâmetros de entrada, e, até mesmo ignorar a requisição caso não atenda a alguma regra definida sem aumentar o trafego de sua API. É o sentinela do seu portão;
  • Mecanismo de segurança – pode incluir no seu processo autenticação de usuários e logs de acesso;
  • Limitação de acesso – (Rate Limit) limitar o acesso do usuário a determinado recurso baseado nas mais diversas premissas, como número de requisições no mês ou nos últimos 50 segundos .
  • Balanceamento de carga;
  • Agregações – poderá agregar ou enriquecer o seu request, juntando uma ou varias api´s dentro de um Api Gateway.
image from microsoft url: https://docs.microsoft.com/pt-br/dotnet/architecture/microservices/architect-microservice-container-applications/media/direct-client-to-microservice-communication-versus-the-api-gateway-pattern/custom-service-api-gateway.png

Quais são as ferramentas de Api Gateway que temos no mercado? bom temos muitas ferramentas mas eu destacaria duas:

  • Ocelot Api Gateway que é uma biblioteca para ser utilizada com aplicações .NET, já usei inclusive para o meu TCC é muito bacana e de fácil instalação, possui funcionalidades como agregação, roteamento, autenticação, cache, balanceamento de carga, log, websockets;
  • Netflix Zuul – ferramenta de Api Gateway construida pela equipe do Netflix.

Sua arquitetura de microserviços pode ter um Api Gateway ou vários vai depender de como você quer separar as responsabilidades do seu sistema, vc pode ter um Api Gateway que atende as chamadas de seu aplicativo mobilie e outro Api Gateway que atende as chamadas de suas páginas web.

Diferenças entre API GATEWAY e API MANAGER

Um Api Manager é um produto mais completo e complexo, feito para gerir apis e possui mecanismos de:

  • Ferramentas analíticas– para entender como as pessoas estão utilizando sua API e obter informações relevantes para sua empresa;
  • Deploy– A ferramenta deve ser flexível e oferecer suporte a nuvens públicas ou privadas, implementações locais ou até combinações;
  • Portal de desenvolvedor – cuida da importância de envolver os usuários, desenvolvedores e parceiros de sua API e para essa integração um API MANAGER deve fornecer um portal de desenvolvimento que facilitará significativamente a integração entre esses atores;
  • Gestão de tráfego – gerir todo o trafico de sua API e também tem mecanismos de cache;
  • Segurança– proteger informações expostas por APIS. O API MANAGER deve pelo menos fornecer gerenciamento de identidade e acesso para usuários e desenvolvedores;
  • Disponibilidade – Deve estar disponível, ser escalável e redundante. O ambiente de sua API pode se tornar exigente e o serviço deve ser capaz de lidar com erros, problemas ou picos de trafego.

Uma ferramenta de Api Manager fornece uma camada de gestão para Api Gateway, use um API Manager quando precisar analisar todo seu sistema, geralmente um Api Manager possui um Api Gateway embutido.

image from : https://docs.axway.com/bundle/APIManagementPlus_GettingStartedGuide_allOS_en_HTML5/page/Content/Resources/Images/APIMgmtPlus/APIMGM_plus_cncpt_api_mgmt.png

São exemplos de Api Manager:

Como trabalhar com autenticação

Todos ou quase todos os microserviços deverão realizar a autorização das requisições que são realizadas por usuários ou por outros sistemas.

Porém a autenticação deve ser centralizada e realizada através de um serviço especifico que pode ser um micro serviço implementado de acordo com a necessidade da organização ou através de serviços de terceiros.

O ideal é isolar a autenticação da API, ou melhor ainda é utilizar algo pronto com o Identity Server por exemplo.

O ideal é possuir autorização em nível de serviço utilizando protocolos como por exemplo o OAuth e JWT. Observe a imagem extraída do site da Microsoft onde existe um micro service de autenticação que devolve um security token possivelmente um JWT:

image from : https://docs.microsoft.com/en-us/dotnet/architecture/microservices/secure-net-microservices-web-applications/media/image2.png

Comunicação entre Microserviços

A comunicação entre serviços deverá ser realizada sempre via publicação de eventos e ou exposição de API. Se sua arquitetura possuir um serviço que acessa diretamente o banco de dados de outro serviço algo está errado.

A arquitetura indica que a comunicação entre os microserviços pode ser orientada a eventos de negocio, ou seja um micro serviço poderá gerar um evento contendo informações que podem ser relevantes para outro ou outros micro serviços que por sua vez deverão realizar alguma operação com as informações recebidas.

As mensagens devem ser publicadas em formato JSON pois é estável e amplamente utilizada em transferência de dados.

O desenvolvedor deve ter algum conhecimento sobre o protocolo AMQP( Advanced Message Queuing Protocol) e também conhecer mecanismos de Publish/Subscribe.

Seu sistema de microserviços vais precisar de comunicação? sim é praticamente impossível construir microserviços sem o auxilio de uma ferramentas que provê este tipo de trabalho.

São exemplos de frameworks de fila:

Observe a imagem abaixo o funcionamento de um sistema de filas:

filas implementadas com o RabbitMQ

Com estas definições, fechamos a nossa segunda parte do artigo sobre microserviços, vamos agora para a última parte onde vou tentar explicar um pouco sobre virtualização e descoberta de serviços, resiliência, logs/telemetrias e sobre a importância do DevOps nesta arquitetura.

No próximo artigo vamos também ver um pouco de código para deixar tudo mais claro.

Vou ficando por aqui, se gostou dá um like ou escreve um comentário, qualquer informação ou critica é muito bem vinda!

Leave a Reply

O seu endereço de e-mail não será publicado.