Entendendo o Modelo de API Gateway


Cenário

Vamos imaginar que você esteja construindo um portal online de estudantes de cursos de graduação de uma universidade, que use o padrão de arquitetura Microserviços e que esteja implementando a página de informações gerais dos detalhes do semestre atual. Você precisa desenvolver várias versões da interface do usuário de detalhes do curso:

  • Interface baseada em HTML5 / JavaScript para navegadores de desktop e dispositivos móveis – o HTML é gerado por um aplicativo da Web do lado do servidor
  • Clientes nativos de Android e iPhone – esses clientes interagem com o servidor por meio de APIs REST

Além disso, o portal deve expor inumeras informações de detalhes do curso por meio de uma API REST para uso por aplicativos de terceiros que necessitam integrar como portais de disciplinas online, central de atendimento integrado a URA de Telefonia para o Call Center, sistemas de Chat Bot entre outros.

Uma interface do usuário de detalhes do curso, contendo informações relevantes pode exibir muitas informações sobre um semestre de um determinado curso. página de informações do com POJOs in Action exibe:

  • Informações sobre disciplinas, notas, provas agendadas, calendário de aulas e etc.
  • Seu histórico escolar por semestre, por ano, por curso;
  • Atividades Complementares;
  • Informações sobre a situação financeira, acordos e boletos de pagamentos;
  • Outros cursos extras curriculares frequentado pelo aluno
  • Avaliações de provas;

Como a portal on-line usa o padrão de arquitetura Microservice, os dados de detalhes do produto são distribuídos por vários serviços. Por exemplo,

  • Serviço de Informações do curso – informações básicas sobre o disciplinas, faltas, notas..
  • Serviço de Agendamento – Agendamento de Provas
  • Solicitações de Auto serviço – histórico de Solicitações de Atendimento
  • Serviço Financeiro – disponibilidade do Boletos, Pagamentos e Acordos
  • Serviço de Estágio – Uploads de Documentos Comprobatórios…

Consequentemente, o código de identificação do aluno precisa buscar informações de todos esses serviços.

Problema

Como os alunos de um aplicativo baseado em Microservices acessam os serviços individuais?

Os Benefícios

  • A granularidade das APIs fornecidas pelos microserviços é frequentemente diferente do que um aluno precisa. Os microserviços geralmente fornecem APIs refinadas, o que significa que os alunos precisam interagir com vários serviços. Por exemplo, conforme descrito acima, um aluno que precisa dos do curso e precisa buscar dados de vários serviços.
  • Alunos diferentes precisam de dados diferentes. Por exemplo, a versão do navegador da área de trabalho de uma de página de detalhes financeiros é geralmente mais elaborada do que a versão para dispositivos móveis.
  • O desempenho da rede é diferente para diferentes tipos de alunos. Por exemplo, uma rede móvel é normalmente muito mais lenta e tem latência muito maior do que uma rede não móvel. E, claro, qualquer WAN é muito mais lenta que uma LAN. Isso significa que um cliente móvel nativo usa uma rede que possui características de desempenho muito diferentes de uma LAN usada por um aplicativo da Web do lado do servidor. O aplicativo da Web do lado do servidor pode fazer várias solicitações para serviços de back-end sem afetar a experiência do usuário, pois um cliente móvel pode fazer apenas alguns.
  • O número de instâncias de serviço e suas localizações (host + porta) muda dinamicamente
  • O particionamento em serviços pode mudar ao longo do tempo e deve ser escondido dos alunos
  • Os serviços podem usar um conjunto diversificado de protocolos, alguns dos quais podem não ser amigáveis para a web

Solução

Implemente um gateway de API que seja o único ponto de entrada para todos os alunos. O gateway de API manipula solicitações de duas maneiras. Algumas solicitações são simplesmente intermediadas por proxy / roteadas para o serviço apropriado. Ele lida com outras solicitações por meio de vários serviços.[/vc_column_text]

Em vez de fornecer uma API de estilo de tamanho único, o gateway de API pode expor uma API diferente para cada aluno. Por exemplo, o gateway da API Netflix executa código do adaptador específico do cliente que fornece a cada cliente uma API mais adequada aos seus requisitos.

O gateway da API também pode implementar a segurança, por exemplo, verificar se o cliente está autorizado a executar a solicitação.

Usando um gateway de API tem os seguintes benefícios:

  • Isola os clientes de como o aplicativo é particionado em microserviços
  • Isola os clientes do problema de determinar os locais das instâncias de serviço
  • Fornece a API ideal para cada cliente
  • Reduz o número de pedidos / roundtrips. Por exemplo, o gateway da API permite que os clientes recuperem dados de vários serviços com uma única viagem de ida e volta. Menos pedidos também significam menos sobrecarga e melhoram a experiência do usuário. Um gateway de API é essencial para aplicativos móveis.
  • Simplifica o cliente movendo a lógica para chamar vários serviços do cliente para o gateway de API
  • Traduz de um protocolo API público “padrão” para todos os protocolos usados ​​internamente

O padrão de gateway da API tem algumas desvantagens:

  • Maior complexidade – o gateway da API é mais uma parte móvel que deve ser desenvolvida, implantada e gerenciada
  • Maior tempo de resposta devido ao salto de rede adicional através do gateway da API – no entanto, para a maioria das aplicações, o custo de uma viagem extra de ida e volta é insignificante.

Problemas:

  • Como implementar o gateway da API? Uma abordagem orientada a eventos / reativa é melhor se ela precisar ser dimensionada para dimensionar para lidar com cargas altas. Na JVM, as bibliotecas baseadas em NIO, como Netty, Spring Reactor etc., fazem sentido. O NodeJS é outra opção.