Partilhar via

Usar o Gerenciamento de API do Azure em uma solução multilocatária

  • Artigo

O Gerenciamento de API do Azure é 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 principais recursos do Gerenciamento de API que são úteis para soluções multilocatário.

Nota

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

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

Modelos de isolamento

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

Normalmente, a maneira como você usa o Gerenciamento de API é semelhante, 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 roteia solicitações para seus aplicativos de API 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 inquilinos suportados Muitos Quase ilimitado Um para cada instância
Custo Lower Lower Mais alto
Complexidade da implantação Baixo: instância única para gerenciar para cada carimbo Baixo: instância única para gerenciar para cada carimbo Alto: várias instâncias para gerenciar
Complexidade da configuração de roteamento Mais alto Lower Lower
Suscetibilidade a problemas de vizinhos ruidosos Sim Sim No
Isolamento de rede no nível do locatário No No Sim
Cenário de exemplo Nomes de domínio personalizados para cada locatário Solução multilocatária grande 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 de Gerenciamento de API entre vários locatários, o que ajuda a reduzir o custo e a complexidade da implantação e do gerenciamento. Os detalhes de como você pode compartilhar uma instância de Gerenciamento de API dependem de como você atribui locatários a aplicativos de API back-end.

Aplicativo back-end de locatário único

Se você implantar aplicativos back-end distintos para cada locatário, poderá implantar uma única instância de Gerenciamento de API e rotear o tráfego para o back-end de locatário correto para cada solicitação. Essa abordagem requer que você configure o Gerenciamento de API com os nomes de host 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 de Gerenciamento de API. 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 back-end multilocatário compartilhado

Em cenários em que seus locatários compartilham um aplicativo back-end comum, o processo de roteamento do Gerenciamento de API é simplificado porque você pode rotear todas as solicitações para um único back-end. Se você usar domínios curinga ou domínios emitidos pelo provedor, poderá alcançar 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 de decisões de roteamento personalizadas.

Instância para cada locatário

Em algumas situações, você pode implantar uma instância de Gerenciamento de API para cada locatário. Recomendamos essa abordagem somente se você tiver um pequeno número de locatários ou se tiver requisitos de conformidade rigorosos que o restrinjam de compartilhar 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 de Gerenciamento de API dedicada para cada locatário.

Gorjeta

Se o seu ú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 Gerenciamento de API atende às suas necessidades.

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

As instâncias de locatário único geralmente têm uma configuração de roteamento mínima, pois você pode rotear todas as solicitações para um único back-end. Esse cenário não requer decisões de roteamento personalizadas, portanto, não há impacto adicional no desempenho. No entanto, você normalmente incorre em um custo de recursos mais alto do que se implantar 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 que você já implanta.

Recursos de gerenciamento de API que suportam multilocação

O Gerenciamento de API usa políticas para permitir a flexibilidade. Você pode personalizar como as solicitações são validadas, roteadas e processadas quando você usa políticas. E quando você projeta uma solução multilocatária com o Gerenciamento de API, usa políticas para implementar muitos de seus 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 para esse locatário específico e mais ninguém.

O Gerenciamento de API 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 Gerenciamento de API para seus próprios identificadores de locatário ou cliente. As subscrições estão totalmente integradas no portal do programador. Para a maioria das soluções, é uma boa prática usar assinaturas para identificar locatários.

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

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

  • 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 Context.Request.Headers leitura da coleção.

  • Extraia declarações de um token da Web JSON (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 output-token-variable-name propriedade para que sua definição de política possa ler os valores do token.

  • Procure 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. Adotando essa abordagem, você pode criar uma lógica de mapeamento de locatário personalizada para mapear um identificador de locatário lógico para uma URL específica ou para obter informações adicionais sobre um locatário. Para usar essa abordagem, use a política de solicitação de envio.

    É provável que essa abordagem aumente a latência de suas solicitações. Para atenuar esse efeito, é recomendável usar o cache para reduzir 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. Certifique-se de invalidar seu cache com cada locatário adicionado, removido ou movido que afete a pesquisa de back-end.

Valores com nome

O Gerenciamento de API oferece suporte a valores nomeados, que são definições de configuração personalizadas que você pode usar em todas as políticas. Por exemplo, você pode usar um valor nomeado para armazenar a 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 precisar atualizar o URL, você pode 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 locatários, certifique-se de incluir 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 reduzir a chance de se referir acidentalmente ou ser manipulado para se referir ao valor de outro locatário quando você processa uma solicitação para outro locatário.

Autenticar solicitações de entrada

As solicitações de API feitas ao gateway de Gerenciamento de API geralmente precisam ser autenticadas. O Gerenciamento de API 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 oferecer suporte e onde elas devem ser validadas. Por exemplo, considere se a validação deve acontecer no Gerenciamento de API, em seus aplicativos back-end ou em ambos os locais.

Para obter mais informações, consulte Autenticação e autorização para APIs no Gerenciamento de API do Azure.

Nota

Se você usa uma chave de assinatura ou chave de API, é uma boa prática usar também 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 rastrear o uso da API de um locatário individual.

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

Ao usar o Gerenciamento de API como um componente compartilhado, talvez seja necessário rotear 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 dentro de um único carimbo. Para personalizar o roteamento em uma definição de política, use a política set-backend-service . Você precisa especificar a nova URL base para a qual a solicitação deve ser redirecionada.

Respostas em cache ou outros dados

O Gerenciamento de API tem um poderoso recurso de cache 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 procurar 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 locatários, certifique-se de incluir o identificador de locatário na chave de cache.

Inclua o identificador para reduzir a chance de se referir acidentalmente a ser manipulado para se referir ao valor de outro locatário quando você processa uma solicitação para outro locatário.

Domínios personalizados

Use o Gerenciamento de API 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 FQDNs (nomes de domínio totalmente qualificados).

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

Limites de taxa

É comum aplicar cotas ou limites de taxa em uma solução multilocatário. Os limites de taxa podem ajudá-lo a mitigar o problema do vizinho barulhento. Você também pode usar limites de taxa para impor a qualidade do serviço e diferenciar entre diferentes níveis de preço.

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

Rentabilização

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

Gestão da capacidade

Uma instância de Gerenciamento de API oferece suporte a uma certa quantidade de capacidade, que representa os recursos disponíveis para processar suas solicitações. Quando você usa políticas complexas ou implanta mais APIs na instância, consome mais capacidade. Você pode gerenciar a capacidade de uma instância de várias maneiras, como comprando mais unidades. Você também pode dimensionar dinamicamente a capacidade de sua instância.

Algumas instâncias multilocatárias podem consumir mais capacidade do que instâncias de locatário único, como se você usar muitas políticas para rotear solicitações para back-ends de locatários diferentes. Considere cuidadosamente o planejamento de capacidade e planeje dimensionar a capacidade de sua instância se você ver seu uso aumentar. 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 Gerenciamento de API, consulte Atualizar e dimensionar uma instância de Gerenciamento de API do Azure.

Implantações multirregionais

O Gerenciamento de API dá suporte a implantações em várias regiões, o que significa que você pode implantar um único recurso lógico de Gerenciamento de API em várias regiões do Azure sem precisar replicar sua 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 de Gerenciamento de API 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 de Gerenciamento de API totalmente isoladas, também poderá optar por implantar recursos independentes de Gerenciamento de API em regiões diferentes. Essa abordagem separa o plano de gerenciamento para cada instância de Gerenciamento de API.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

  • John Downs - Brasil | Engenheiro de Software Principal
  • Daniel Scott-Raynsford - Brasil | Estrategista de Tecnologia de Parceiros, Soluções de Parceiros Globais

Outros contribuidores:

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

Próximos passos

Analise as abordagens arquitetônicas para integração em soluções multilocatário.