Essa arquitetura de referência usa o Azure Integration Services para orquestrar chamadas para sistemas de back-end corporativos. Os sistemas de back-end podem incluir sistemas SaaS (software como serviço), serviços do Azure e serviços Web existentes na sua empresa.
Arquitetura
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de trabalho
Sistemas de back-end. O lado direito do diagrama mostra os vários sistemas de back-end que a empresa implantou ou confia. Esses sistemas podem incluir sistemas SaaS, outros serviços do Azure ou serviços Web que expõem pontos de extremidade REST ou SOAP.
Aplicativos Lógicos do Azure. Nessa arquitetura, os aplicativos lógicos são acionados por solicitações HTTP. Você também pode aninhar fluxos de trabalho para orquestração mais complexa. Os Aplicativos Lógicos usam conectores para integração com serviços comumente usados. O Logic Apps oferece centenas de conectores e você pode criar conectores personalizados.
Gerenciamento de API do Azure. O Gerenciamento de API consiste em dois componentes relacionados:
API gateway. O gateway de API aceita chamadas HTTP e as roteia para o back-end.
Portal do desenvolvedor. Cada instância do Gerenciamento de API do Azure fornece acesso a um portal do desenvolvedor. Este portal dá aos seus desenvolvedores acesso à documentação e exemplos de código para chamar as APIs. Você também pode testar APIs no portal do desenvolvedor.
DNS do Azure. O DNS do Azure oferece resolução de nomes através da infraestrutura do Azure. Ao hospedar seus domínios no Azure, você pode gerenciar seus registros DNS usando as mesmas credenciais, APIs, ferramentas e cobrança que você usa para seus outros serviços do Azure. Para usar um nome de domínio personalizado, como contoso.com, crie registros DNS que mapeiam o nome de domínio personalizado para o endereço IP. Para obter mais informações, consulte Configurar um nome de domínio personalizado no Gerenciamento de API.
ID do Microsoft Entra. Use o Microsoft Entra ID para autenticar clientes que chamam o gateway de API. O Microsoft Entra ID suporta o protocolo OpenID Connect (OIDC). Os clientes obtêm um token de acesso do Microsoft Entra ID e o API Gateway valida o token para autorizar a solicitação. Se você usar a camada Standard ou Premium do Gerenciamento de API, a ID do Microsoft Entra também poderá ajudar a proteger o acesso ao portal do desenvolvedor.
Componentes
- O Integration Services é uma coleção de serviços que você pode usar para integrar aplicativos, dados e processos.
- O Logic Apps é uma plataforma sem servidor para criar fluxos de trabalho corporativos que integram aplicativos, dados e serviços.
- O Gerenciamento de API é um serviço gerenciado para publicação de catálogos de APIs HTTP. Você pode usá-lo para promover a reutilização e a capacidade de descoberta de suas APIs e para implantar um gateway de API para solicitações de API de proxy.
- O DNS do Azure é um serviço de alojamento para domínios DNS.
- O Microsoft Entra ID é um serviço de gerenciamento de identidade e acesso baseado em nuvem. Os funcionários da empresa podem usar o Microsoft Entra ID para acessar recursos externos e internos.
Detalhes do cenário
O Integration Services é uma coleção de serviços que você pode usar para integrar aplicativos, dados e processos para sua empresa. Essa arquitetura usa dois desses serviços: Aplicativos lógicos para orquestrar fluxos de trabalho e Gerenciamento de API para criar catálogos de APIs.
Nessa arquitetura, as APIs compostas são criadas importando aplicativos lógicos como APIs. Você também pode importar serviços Web existentes importando especificações OpenAPI (Swagger) ou importando APIs SOAP de especificações WSDL.
O gateway de API ajuda a separar os clientes front-end do back-end. Por exemplo, ele pode reescrever URLs ou transformar solicitações antes que elas cheguem ao back-end. Ele também lida com muitas preocupações transversais, como autenticação, suporte a compartilhamento de recursos entre origens (CORS) e cache de resposta.
Potenciais casos de utilização
Essa arquitetura é suficiente para cenários de integração básica nos quais o fluxo de trabalho é acionado por chamadas síncronas para serviços de back-end. Uma arquitetura mais sofisticada usando filas e eventos se baseia nessa arquitetura básica.
Recomendações
Seus requisitos específicos podem diferir da arquitetura genérica mostrada aqui. Utilize as recomendações nesta secção como um ponto de partida.
Gestão de API
Use as camadas Basic, Standard ou Premium do Gerenciamento de API. Essas camadas oferecem um contrato de nível de serviço (SLA) de produção e oferecem suporte à expansão dentro da região do Azure. A capacidade de taxa de transferência para o Gerenciamento de API é medida em unidades. Cada nível de preço tem uma expansão máxima. A camada Premium também oferece suporte à expansão em várias regiões do Azure. Escolha sua camada com base no conjunto de recursos e no nível de taxa de transferência necessária. Para obter mais informações, consulte Preços do Gerenciamento de API e Capacidade de uma instância de Gerenciamento de API do Azure.
Cada instância de Gerenciamento de API do Azure tem um nome de domínio padrão, que é um subdomínio de azure-api.net, por exemplo, contoso.azure-api.net. Considere configurar um domínio personalizado para sua organização.
Aplicações Lógicas
Os Aplicativos Lógicos funcionam melhor em cenários que não exigem baixa latência para uma resposta, como chamadas de API assíncronas ou de execução semilonga. Se for necessária baixa latência, por exemplo, em uma chamada que bloqueia uma interface do usuário, use uma tecnologia diferente. Por exemplo, use o Azure Functions ou uma API Web implantada no Serviço de Aplicativo do Azure. Use o Gerenciamento de API para direcionar a API para seus consumidores de API.
Região
Para minimizar a latência da rede, coloque o Gerenciamento de API e os Aplicativos Lógicos na mesma região. Em geral, escolha a região mais próxima de seus usuários (ou mais próxima de seus serviços de back-end).
Considerações
Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que você pode usar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.
Fiabilidade
A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte Visão geral do pilar de confiabilidade.
Analise o SLA de cada serviço:
Se você implantar o Gerenciamento de API em duas ou mais regiões com o nível Premium, ele estará qualificado para um SLA mais alto. Consulte Preços de gerenciamento de API.
Cópias de Segurança
Faça backup regularmente de sua configuração de Gerenciamento de API. Armazene seus arquivos de backup em um local ou região do Azure diferente da região onde o serviço é implantado. Com base no seu RTO, escolha uma estratégia de recuperação de desastres:
Em um evento de recuperação de desastre, provisione uma nova instância de Gerenciamento de API, restaure o backup para a nova instância e reaponte os registros DNS.
Mantenha uma instância passiva do serviço de Gerenciamento de API em outra região do Azure. Restaure regularmente os backups para essa instância, para mantê-la sincronizada com o serviço ativo. Para restaurar o serviço durante um evento de recuperação de desastre, você só precisa reapontar os registros DNS. Essa abordagem incorre em custos adicionais porque você paga pela instância passiva, mas reduz o tempo de recuperação.
Para aplicativos lógicos, recomendamos uma abordagem de configuração como código para fazer backup e restaurar. Como os aplicativos lógicos não têm servidor, você pode recriá-los rapidamente a partir de modelos do Azure Resource Manager. Salve os modelos no controle do código-fonte, integre os modelos com seu processo de integração contínua/implantação contínua (CI/CD). Em um evento de recuperação de desastre, implante o modelo em uma nova região.
Se você implantar um aplicativo lógico em uma região diferente, atualize a configuração no Gerenciamento de API. Você pode atualizar a propriedade Backend da API usando um script básico do PowerShell.
Segurança
A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.
Embora esta lista não descreva completamente todas as práticas recomendadas de segurança, aqui estão algumas considerações de segurança que se aplicam especificamente a essa arquitetura:
O serviço de Gerenciamento de API do Azure tem um endereço IP público fixo. Restrinja o acesso para chamar pontos de extremidade do Logic Apps apenas ao endereço IP do Gerenciamento de API. Para obter mais informações, consulte Restringir endereços IP de entrada.
Para garantir que os usuários tenham níveis de acesso apropriados, use o controle de acesso baseado em função do Azure (Azure RBAC).
Proteja pontos de extremidade de API públicos no Gerenciamento de API usando OAuth ou OpenID Connect. Para proteger pontos de extremidade de API públicos, configure um provedor de identidade e adicione uma política de validação de JSON Web Token (JWT). Para obter mais informações, consulte Proteger uma API usando o OAuth 2.0 com o Microsoft Entra ID e o Gerenciamento de API.
Conecte-se a serviços back-end do Gerenciamento de API usando certificados mútuos.
Imponha HTTPS nas APIs de gerenciamento de API.
Guardar segredos
Nunca selecione palavras-passe, chaves de acesso ou cadeias de ligação no controlo de origem. Se esses valores forem necessários, proteja-os e implante-os usando as técnicas apropriadas.
Se um aplicativo lógico exigir valores confidenciais que você não pode criar em um conector, armazene esses valores no Cofre da Chave do Azure e faça referência a eles a partir de um modelo do Gerenciador de Recursos. Use parâmetros de modelo de implantação e arquivos de parâmetros para cada ambiente. Para obter mais informações, consulte Proteger parâmetros e entradas em um fluxo de trabalho.
O Gerenciamento de API gerencia segredos usando objetos chamados valores nomeados ou propriedades. Esses objetos armazenam com segurança valores que você pode acessar por meio de políticas de Gerenciamento de API. Para obter mais informações, consulte Como usar valores nomeados em políticas de gerenciamento de API do Azure.
Excelência operacional
A excelência operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Visão geral do pilar de excelência operacional.
DevOps
Crie grupos de recursos separados para ambientes de produção, desenvolvimento e teste. A utilização de grupos de recursos separados torna mais fácil gerir as implementações, eliminar as implementações de teste e atribuir direitos de acesso.
Ao atribuir recursos a grupos de recursos, considere estes fatores:
Ciclo de vida. Em geral, coloque os recursos com o mesmo ciclo de vida no mesmo grupo de recursos.
Acesso. Para aplicar políticas de acesso aos recursos em um grupo, você pode usar o controle de acesso baseado em função do Azure (Azure RBAC).
Faturação. Você pode exibir os custos de rollup para o grupo de recursos.
Nível de preço para Gerenciamento de API. Utilize o escalão Programador para ambientes de desenvolvimento e teste. Para minimizar os custos durante a pré-produção, implemente uma réplica do seu ambiente de produção, execute os testes e, em seguida, encerre.
Implementação
Use os modelos do Azure Resource Manager para implantar os recursos do Azure, siga a infraestrutura como Processo de Código (IaC). Os modelos facilitam a automação de implantações usando os Serviços de DevOps do Azure ou outras soluções de CI/CD.
Processo de teste
Considere preparar suas cargas de trabalho, o que significa implantar em vários estágios e executar validações em cada estágio antes de passar para o próximo. Se você usar essa abordagem, poderá enviar atualizações por push para seus ambientes de produção de forma altamente controlada e minimizar problemas de implantação imprevistos. A implantação azul-verde e as versões Canary são estratégias de implantação recomendadas para atualizar ambientes de produção ao vivo. Considere também ter uma boa estratégia de reversão para quando uma implantação falhar. Por exemplo, você pode reimplantar automaticamente uma implantação anterior bem-sucedida a partir do seu histórico de implantação. O --rollback-on-error parâmetro flag na CLI do Azure é um bom exemplo.
Isolamento de cargas de trabalho
Coloque o Gerenciamento de API e quaisquer aplicativos lógicos individuais em seus próprios modelos separados do Gerenciador de Recursos. Usando modelos separados, você pode armazenar os recursos em sistemas de controle do código-fonte. Você pode implantar os modelos juntos ou individualmente como parte de um processo de CI/CD.
Versões
Sempre que você altera a configuração de um aplicativo lógico ou implanta uma atualização por meio de um modelo do Gerenciador de Recursos, o Azure mantém uma cópia dessa versão e mantém todas as versões que têm um histórico de execução. Você pode usar essas versões para controlar alterações históricas ou promover uma versão como a configuração atual do aplicativo lógico. Por exemplo, você pode reverter um aplicativo lógico para uma versão anterior.
O Gerenciamento de API suporta dois conceitos de controle de versão distintos, mas complementares:
As versões permitem que os consumidores de API escolham uma versão de API com base em suas necessidades, por exemplo, v1, v2, beta ou produção.
As revisões permitem que os administradores de API façam alterações contínuas em uma API e implantem essas alterações, juntamente com um log de alterações para informar os consumidores da API sobre as alterações.
Você pode fazer uma revisão em um ambiente de desenvolvimento e implantar essa alteração em outros ambientes usando modelos do Gerenciador de Recursos. Para obter mais informações, consulte Publicar várias versões da API
Você também pode usar revisões para testar uma API antes de tornar as alterações atuais e acessíveis aos usuários. No entanto, esse método não é recomendado para testes de carga ou testes de integração. Em vez disso, use ambientes de teste ou pré-produção separados.
Diagnóstico e monitorização
Use o Azure Monitor para monitoramento operacional em Gerenciamento de API e Aplicativos Lógicos. O Azure Monitor fornece informações com base nas métricas configuradas para cada serviço e é habilitado por padrão. Para obter mais informações, consulte:
- Monitorizar as APIs publicadas
- Monitorizar o estado, configurar o registo de diagnósticos e ativar alertas para o Azure Logic Apps
Cada serviço também tem estas opções:
Para análises e painéis mais profundos, envie logs de Aplicativos Lógicos para o Azure Log Analytics.
Para monitoramento de DevOps, configure o Azure Application Insights for API Management.
O Gerenciamento de API dá suporte ao modelo de solução do Power BI para análise de API personalizada. Você pode usar este modelo de solução para criar sua própria solução de análise. Para usuários corporativos, o Power BI disponibiliza relatórios.
Eficiência de desempenho
Eficiência de desempenho é a capacidade da sua carga de trabalho para dimensionar para satisfazer as exigências que os utilizadores lhe colocam de forma eficiente. Para obter mais informações, consulte Visão geral do pilar de eficiência de desempenho.
Para aumentar a escalabilidade do Gerenciamento de API, adicione políticas de cache quando apropriado. O cache também ajuda a reduzir a carga nos serviços back-end.
Para oferecer maior capacidade, você pode expandir as camadas Basic, Standard e Premium do Azure API Management em uma região do Azure. Para analisar o uso do seu serviço, selecione Métrica de capacidade no menu Métricas e, em seguida, aumente ou diminua a escala conforme apropriado. A aplicação do processo de atualização ou dimensionamento pode demorar entre 15 e 45 minutos.
Recomendações para dimensionar um serviço de Gerenciamento de API:
Considere os padrões de tráfego ao dimensionar. Clientes com padrões de tráfego mais voláteis precisam de mais capacidade.
Uma capacidade consistente superior a 66% pode indicar a necessidade de aumentar a escala.
Uma capacidade consistente inferior a 20% pode indicar uma oportunidade de redução.
Antes de habilitar a carga na produção, sempre teste o serviço de Gerenciamento de API com uma carga representativa.
Com a camada Premium, você pode dimensionar uma instância de Gerenciamento de API em várias regiões do Azure. Isso torna o Gerenciamento de API elegível para um SLA mais alto e permite provisionar serviços próximos a usuários em várias regiões.
O modelo sem servidor dos Aplicativos Lógicos significa que os administradores não precisam planejar a escalabilidade do serviço. O serviço é dimensionado automaticamente para atender à demanda.
Otimização de custos
No geral, utilize a calculadora de preços do Azure para prever os custos. Aqui estão algumas outras considerações.
Gestão de API
Você será cobrado por todas as instâncias de Gerenciamento de API quando elas estiverem em execução. Se você tiver aumentado a escala e não precisar desse nível de desempenho o tempo todo, reduza manualmente ou configure o dimensionamento automático.
Aplicações Lógicas
O Logic Apps usa um modelo sem servidor. O faturamento é calculado com base na ação e na execução do conector. Para obter mais informações, veja os preços do Logic Apps.
Para obter mais informações, veja a secção de custos Well-Architected Framework do Microsoft Azure.
Próximos passos
Recursos relacionados
Para maior confiabilidade e escalabilidade, use filas de mensagens e eventos para desacoplar os sistemas de back-end. Essa arquitetura é mostrada no próximo artigo desta série:
Você também pode estar interessado nestes artigos do Centro de Arquitetura do Azure: