DEAITOOLS-219 - Realizar estudo sobre micro gateways de APIs

Propósito

Avaliar/Comparar arquiteturas propostas para modelo híbrido (API Manager em Cloud + APIs publicadas na infraestrutura do cliente)

Redirecionamento HTTP

Arquitetura

• Aplicação client faz uma requisição HTTP para o nosso servidor em Cloud
• Essa requisição passa pelo API manager até uma API REST
• Essa API Rest retorna uma resposta de maneira síncrona

Vantagens

• Mais rápido que o modelo de Subscrição de Comandos (246ms)
• API fica acessível de qualquer lugar que possui internet.

Desvantagens

• Mais lento que o modelo MicroGateway
• Obrigatório que o cliente definida regras de permissão de porta de entrada (inbound).

Subscrição de Comandos

Arquitetura

• Aplicação client faz uma requisição HTTP para servidor em Cloud
• Essa requisição passa pelo API manager até uma API responsável por informar a solicitação feita pelo cliente em uma fila de comandos (AMQP 0.9)
• Essa fila de comandos está sendo monitorada por um Command Receiver, que está rodando na Infra do cliente. O modo de comunicação é síncrono
• Esse Command Receiver faz uma requisição para o método responsável pelas regras de negócio, e a mesma retorna uma resposta
• Essa resposta vai até uma fila temporária, na qual o REST da cloud está conectada. A partir daí a resposta volta para a aplicação client.

Vantagens

• Não existe necessidade de regras de permissão de porta de entrada (inbound), apenas saída (outbound) na rede do cliente.
• API fica acessível de qualquer lugar que possui internet.

Desvantagens

• Maior tempo de resposta encontrado nos testes (380ms).
• Custo do desenvolvimento de Command Receiver.

MicroGateway

Arquitetura

• Aplicação client, na rede onPremisse do cliente, faz uma requisição HTTP para um gateway existente no servidor dentro de sua própria rede
• Esse gateway redireciona para API Rest, que retorna uma resposta de maneira síncrona
• De tempos em tempos, o microgateway alimenta o API Manager em Cloud com as informações necessárias

Vantagens

• Menor tempo de resposta encontrado nos testes (126ms).
• Todas as requisições ocorrem sem sair da rede do cliente
  • Segurança
  • Performance
• É possível trabalhar sem regras de permissão de porta de entrada (inbound), apenas saída (outbound) na rede do cliente.

Desvantagens

• API não fica acessível através da internet e se limita a rede à rede interna do cliente. A não ser que esse modelo funcione em conjunto com o de Redirecionamento HTTP, explicado no início do documento.
• TOTVS fica responsável por gerenciar microgateways em todos os clientes que aderirem esse modelo

Detalhes sobre execução do teste

Infraestrutura

Foram criadas duas máquinas no Windows Azure:

TotvsCloudTest

Papel: Simular ambiente de Cloud controlado pela Totvs

• Windows (Windows Server 2008 R2 Datacenter)
• Leste dos EUA
• Aplicações
  • DotNet Core
  • WSO2
  • CloudRestAPI
  • ActiveMQ
• Regras de Saída:
  • AllowInternetOutbound
• Regras de Entrada:
  • WSO2-1: 8280
  • WSO2-2: 8243
  • TesteAPI: 8015
  • AMQP: 8012

TPremiseTest

Papel: Simular ambiente OnPremise do cliente, sem abertura de porta, solicitando atualizações de um nó AMQP disponível em Cloud

• Windows (Windows Server 2008 R2 Datacenter)
• Sul do Brasil
• Aplicações
  • DotNet Core
  • RequestResponseServer
• Regras de Saída:
  • AllowInternetOutbound
• Regras de Entrada: (Nenhuma)

Também foi utilizada uma máquina no OpenStack na rede da Totvs

FerramentasEAI

Papel: Simular ambiente OnPremise do cliente, com abertura de porta, disponibilizando uma API Rest

• Windows (Windows Server 2012 R2)
• Sudeste do Brasil
• Aplicações
  • DotNet Core
  • CloudRestAPI
• Regras de Saída:
  • AllowInternetOutbound
• Regras de Entrada:
  • Portas entre 8000 e 8099

WSO2

Foram publicadas duas APIs:

• BUSINESSRESTAPIHTTPREDIRECT
  • Faz o redirecionamento para um endpoint remoto, fluxo totalmente focado no REST
• BUSINESSRESTAPIQUEUE
  • Faz o redirecionamento para endpoint de API local, responsável por tratar o fluxo de comandos (AMQP)

Repositório

https://totvstfs.visualstudio.com/IntegrationFramework/_git/IntegrationFramework

Pasta: POC-EventBasedArchitecture

Nessa pasta, encontram-se todos os artefatos criados para esse teste, como:

• Projeto CloudRestAPI
• Projeto RequestResponseServer
• Configuração de APIs no WSO2
• Collection com os casos de teste 

Detalhes sobre resultados do teste

https://docs.google.com/spreadsheets/d/17mEMED7fAU14s3iJqNpPeMlcTQ6mWNkG4jK49vZT3ks/edit?usp=sharing

(Tempo de resposta médio em milissegundos)