Compartilhar via

Usar o Azure API Management em uma solução multilocatário

  • Artigo

Azure API Management é um gateway de API abrangente e proxy reverso para APIs. Ele fornece muitos recursos, incluindo cache, simulação de resposta e um portal do desenvolvedor, que são úteis para aplicativos focados em API. Este artigo resume alguns dos recursos principais do API Management que são úteis para soluções multilocatário.

Observação

Este artigo se concentra em como você pode usar o API Management quando tiver seus próprios aplicativos multilocatários que hospedam APIs para uso interno ou externo.

Outra forma de multilocação é fornecer o gateway do API Management como um serviço para outras equipes. Por exemplo, uma organização pode ter uma instância compartilhada do API Management que várias equipes de aplicativos implantam e usam. Este artigo não discute essa forma de multilocação. Pense em usar espaços de trabalho, que ajudam você a compartilhar uma instância do API Management entre várias equipes que podem ter diferentes níveis de acesso.

Modelos de isolamento

O API Management normalmente é implantado como um componente compartilhado com uma única instância que atende a solicitações para vários locatários. No entanto, com base no seu modelo de locação, há muitas maneiras de implantar o API Management. Este artigo pressupõe que você implante sua solução usando carimbos de implantação.

Normalmente, a maneira como você usa o API Management é parecida, independentemente do modelo de isolamento. Esta seção se concentra nas diferenças de custo e complexidade entre os modelos de isolamento e como cada abordagem encaminha solicitações para seus aplicativos de API de back-end.

Consideração Instância compartilhada com back-ends de locatário único Instância compartilhada com back-end multilocatário compartilhado Instância para cada locatário
Número de locatários com suporte Muitos Quase ilimitado Um para cada instância
Custo Inferior Inferior Superior
Complexidade da implantação Baixo: instância única a ser gerenciada para cada carimbo Baixo: instância única a ser gerenciada para cada carimbo Alto: várias instâncias para gerenciar
Complexidade da configuração de roteamento Maior Menor Inferior
Suscetibilidade a problemas de vizinhos com ruído Sim Sim No
Isolamento de rede no nível do locatário Não No Sim
Cenário de exemplo Nomes de domínio personalizados para cada locatário Grande solução multilocatário com uma camada de aplicativo compartilhada Carimbos de implantação específicos do locatário

Modelos de isolamento de instância compartilhada

É comum compartilhar uma instância do API Management entre vários locatários, o que ajuda a reduzir o custo e a complexidade de implantação e gerenciamento. Os detalhes de como você pode compartilhar uma instância do API Management dependem de como você atribui locatários a aplicativos de API de back-end.

Aplicativo de back-end de locatário único

Se você implantar aplicativos de back-end diferentes para cada locatário, poderá implantar uma única instância do API Management e rotear o tráfego para o back-end de locatário correto para cada solicitação. Essa abordagem exige que você configure o API Management com os nomes de host de back-end para cada locatário ou tenha outra maneira de mapear uma solicitação de entrada para o back-end do locatário correto.

Como requer uma pesquisa extra, essa abordagem pode não ser dimensionada para um grande número de locatários que compartilham uma única instância do API Management. Também pode haver alguma sobrecarga de desempenho quando você procura o back-end do locatário. No entanto, o tamanho dessa sobrecarga de desempenho depende de como você projeta essa pesquisa.

Aplicativo de back-end multilocatário compartilhado

Nos cenários em que os locatários compartilham um aplicativo de back-end comum, o processo de roteamento do API Management é simplificado porque você pode encaminhar todas as solicitações para um único back-end. Se você usar domínios curinga ou domínios emitidos pelo provedor, poderá obter uma escala quase ilimitada com essa abordagem. Além disso, como as solicitações não precisam ser mapeadas para o back-end de um locatário, não há impacto no desempenho das decisões de roteamento personalizadas.

Instância para cada locatário

Em algumas situações, você pode implantar uma instância do API Management para cada locatário. Recomendamos essa abordagem somente se você tiver um pequeno número de locatários ou se tiver requisitos de conformidade rígidos que restrinjam o compartilhamento de qualquer infraestrutura entre locatários. Por exemplo, se você implantar uma rede virtual dedicada para cada locatário, provavelmente também precisará implantar uma instância dedicada do API Management para cada locatário.

Dica

Se o único motivo para implantar várias instâncias for oferecer suporte a usuários em diferentes regiões geográficas, convém considerar se o recurso de implantação de várias regiões no API Management satisfaz seus requisitos.

Ao implantar uma instância do API Management, você precisa considerar os limites de serviço, incluindo quaisquer limites que possam ser aplicados ao número de instâncias do API Management em uma assinatura ou região do Azure.

As instâncias de locatário único normalmente têm configuração mínima de roteamento porque você pode rotear todas as solicitações para um único back-end. Esse cenário não requer decisões de roteamento personalizadas e, portanto, não há impacto adicional no desempenho. No entanto, isso normalmente gera um custo de recursos mais alto do que a implantação de uma instância compartilhada. Se você precisar implantar instâncias de locatário único, considere se os gateways auto-hospedados permitem que você reutilize recursos de computação específicos do locatário já implantado.

Recursos do API Management que dão suporte à multilocação

O API Management usa políticas para habilitar a flexibilidade. Você pode personalizar como as solicitações são validadas, encaminhadas e processadas ao usar políticas. E ao projetar uma solução multilocatário com o API Management, você usa políticas para implementar muitos recursos.

Identificar locatários em solicitações de entrada

Considere como você pode identificar o locatário apropriado em cada solicitação de entrada. Em uma solução multilocatário, é importante ter uma compreensão clara de quem está fazendo cada solicitação para que você retorne os dados desse locatário específico e de mais ninguém.

O API Management fornece assinaturas que você pode usar para autenticar solicitações. Essas assinaturas usam uma chave de assinatura exclusiva que ajuda a identificar o assinante que está fazendo a solicitação. Se você optar por usar assinaturas, considere como mapear as assinaturas do API Management para seus próprios identificadores de locatário ou cliente. As assinaturas são totalmente integradas ao portal do desenvolvedor. Para a maioria das soluções, é útil usar assinaturas para identificar locatários.

Como alternativa, você pode identificar o locatário usando outros métodos. Confira alguns exemplos de abordagens que são executadas em uma política personalizada que você define:

  • Use um componente personalizado do URL, como um subdomínio, caminho ou string de consulta. Por exemplo, no URL https://api.contoso.com/tenant1/products, você pode extrair a primeira parte do caminho, tenant1, e tratá-la como um identificador de locatário. Da mesma forma, dado o URL de entrada https://tenant1.contoso.com/products, você pode extrair o subdomínio, tenant1. Para usar essa abordagem, analise o caminho ou a string de consulta da propriedade Context.Request.Url.

  • Use um cabeçalho de solicitação Por exemplo, seus aplicativos cliente podem adicionar um cabeçalho personalizado TenantID às solicitações. Para usar essa abordagem, considere a leitura da coleção Context.Request.Headers.

  • Extraia declarações de um token JSON da Web (JWT). Por exemplo, você pode ter uma declaração personalizada tenantId em um JWT emitido pelo seu provedor de identidade. Para usar essa abordagem, use a política validate-jwt e defina a propriedade output-token-variable-name para que sua definição de política possa ler os valores do token.

  • Pesquise identificadores de locatário dinamicamente. Você pode se comunicar com um banco de dados ou serviço externo enquanto a solicitação está sendo processada. Ao adotar essa abordagem, você pode criar uma lógica de mapeamento de locatário personalizada para mapear um identificador de locatário lógico para um URL específico ou para obter informações adicionais sobre um locatário. Para usar essa abordagem, use a política send-request.

    É provável que essa abordagem aumente a latência das solicitações. Para atenuar esse efeito, é recomendado usar o cache para diminuir o número de chamadas para a API externa. Você pode usar as políticas cache-store-value e cache-lookup-value para implementar uma abordagem de cache. Invalide seu cache com cada locatário adicionado, removido ou movido que afeta a pesquisa de back-end.

Valores nomeados

O API Management dá suporte a valores nomeados, que são opções de configuração personalizadas que você pode usar em todas as suas políticas. Por exemplo, você pode usar um valor nomeado para armazenar o URL de back-end de um locatário e, em seguida, reutilizar esse mesmo valor em vários locais dentro de suas políticas. Se você precisar atualizar o URL, poderá atualizá-lo em um único lugar.

Aviso

Em uma solução multilocatário, é importante ter cuidado ao definir os nomes dos valores nomeados. Se as configurações variarem entre os locatários, inclua o identificador de locatário no nome. Por exemplo, você pode usar um padrão como tenantId-key:value depois de confirmar que tenantId é adequado para a solicitação.

Inclua o identificador para diminuir a chance de se referir acidentalmente ou ser manipulado para se referir ao valor de outro locatário ao processar uma solicitação para outro locatário.

Autenticar solicitações de entrada

As solicitações de API feitas ao gateway do API Management geralmente precisam ser autenticadas. O API Management fornece vários métodos de autenticação de solicitações de entrada para o gateway, incluindo OAuth 2.0 e certificados de cliente. Considere os tipos de credenciais que você deve suportar e onde elas devem ser validadas. Por exemplo, considere se a validação deve ocorrer no API Management, em seus aplicativos de back-end ou nos dois locais.

Para saber mais, confira Autenticação e autorização para APIs no Gerenciamento de API do Azure.

Observação

Se você usar uma chave de assinatura ou chave de API, convém também usar outro método de autenticação.

Uma chave de assinatura por si só não é uma forma forte de autenticação, mas é útil para outros cenários, como para acompanhar o uso da API de um locatário individual.

Encaminhar para back-ends específicos do locatário

Ao usar o API Management como um componente compartilhado, talvez seja necessário encaminhar solicitações de API de entrada para diferentes back-ends específicos do locatário. Esses back-ends podem estar em carimbos de implantação diferentes ou podem ser aplicativos diferentes em um único carimbo. Para personalizar o roteamento em uma definição de política, use a política set-backend-service. Você precisa especificar o novo URL base para o qual a solicitação deve ser redirecionada.

Armazenar em cache respostas ou outros dados

O API Management tem um recurso de cache poderoso que você pode usar para armazenar em cache respostas HTTP inteiras ou quaisquer outros dados. Por exemplo, você pode usar o cache para mapeamentos de locatário se usar lógica personalizada ou se pesquisar o mapeamento de um serviço externo.

Use as políticas cache-store-value e cache-lookup-value para implementar uma abordagem de cache.

Aviso

Em uma solução multilocatário, é importante ter cuidado ao definir suas chaves de cache. Se os dados armazenados em cache puderem variar entre os locatários, inclua o identificador de locatário na chave de cache.

Inclua o identificador para diminuir a chance de se referir acidentalmente ou ser manipulado para se referir ao valor de outro locatário ao processar uma solicitação para outro locatário.

Domínios personalizados

Use o API Management para configurar seus próprios domínios personalizados para o gateway de API e o portal do desenvolvedor. Em algumas camadas, você pode configurar domínios curinga ou vários nomes de domínio totalmente qualificados (FQDNs).

Você também pode usar o API Management junto com um serviço como o Azure Front Door. Nesse tipo de configuração, o Azure Front Door costuma lidar com domínios personalizados e certificados TLS (Transport Layer Security) e se comunica com o API Management usando um único nome de domínio. Se o URL original do cliente incluir informações de locatário que você precisa enviar para a instância do API Management para processamento posterior, considere usar o cabeçalho de solicitação X-Forwarded-Host ou usar as regras do Azure Front Door para transmitir as informações como um cabeçalho HTTP.

Limitações de fluxo

É comum aplicar cotas ou limites de taxa em uma solução multilocatário. Os limites de taxa podem ajudar você a mitigar o problema do vizinho barulhento. Você também pode usar limites de taxa para impor a qualidade do serviço e diferenciar tipos de preços.

Use o API Management para impor limites de taxa específicos do locatário. Se você usar assinaturas específicas do locatário, considere usar a política quota para impor uma cota para cada assinatura. Como alternativa, considere usar a política quota-by-key para impor cotas usando qualquer outra chave de limite de taxa, como um identificador de locatário obtido do URL da solicitação ou um JWT.

Monetização

A documentação do API Management fornece diretrizes abrangentes sobre como monetizar APIs, incluindo um exemplo de implementação. As abordagens de monetização combinam muitos recursos do API Management para que os desenvolvedores possam publicar uma API, gerenciar assinaturas e cobrar com base em diferentes modelos de uso.

Gerenciamento de capacidade

Uma instância do API Management dá suporte a uma determinada quantidade de capacidade, que representa os recursos disponíveis para processar suas solicitações. Ao usar políticas complexas ou implantar mais APIs na instância, você consome mais capacidade. Você pode gerenciar a capacidade de uma instância de várias maneiras, como comprando mais unidades. Você também pode escalar dinamicamente a capacidade da sua instância.

Algumas instâncias multilocatário podem consumir mais capacidade do que instâncias de locatário único, como se você usasse muitas políticas para encaminhar solicitações para back-ends de locatários diferentes. Considere o planejamento de capacidade com cuidado e planeje escalar a capacidade da instância se você perceber que o uso aumenta. Você também deve testar o desempenho de sua solução para entender suas necessidades de capacidade com antecedência.

Para obter mais informações sobre como dimensionar o API Management, consulte Atualizar e dimensionar uma instância do Azure API Management.

Implantações em várias regiões

O API Management dá suporte a implantações de várias regiões, o que significa que você pode implantar um único recurso lógico do API Management em várias regiões do Azure sem precisar replicar a configuração em recursos separados. Esse recurso é especialmente útil quando você distribui ou replica sua solução globalmente. Você pode implantar efetivamente uma frota de instâncias do API Management em várias regiões, o que permite o processamento de solicitações de baixa latência e gerenciá-las como uma única instância lógica.

No entanto, se você precisar de instâncias do API Management totalmente isoladas, também poderá optar por implantar recursos independentes do API Management em regiões diferentes. Essa abordagem separa o plano de gerenciamento para cada instância do API Management.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

Outro colaborador:

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas

Consulte as abordagens de arquitetura para integração em soluções multilocatário.