Essa arquitetura de referência usa os Azure Integration Services para orquestrar chamadas para sistemas de back-end empresariais. Os sistemas de back-end podem incluir sistemas SaaS (software como serviço), serviços do Azure e serviços da Web existentes em sua empresa.
Arquitetura
Baixe um Arquivo Visio dessa arquitetura.
Workflow
Application. O aplicativo é um cliente que chama o gateway de API depois de autenticar com o Microsoft Entra. O aplicativo pode ser um aplicativo Web, um aplicativo móvel ou qualquer outro cliente que possa fazer solicitações HTTP.
Microsoft Entra ID. É usado para autenticar o aplicativo cliente. O aplicativo cliente obtém um token de acesso da ID do Microsoft Entra e o inclui na solicitação para o gateway de API.
Gerenciamento de API do Azure. O Gerenciamento de API é formado por dois componentes relacionados:
Gateway de API. O gateway de API aceita a chamada HTTP do aplicativo cliente, valida o token da ID do Microsoft Entra e encaminha a solicitação para o serviço de back-end. O gateway de API também pode transformar solicitações e respostas e respostas em cache.
Portal do desenvolvedor. O portal do desenvolvedor é usado pelos desenvolvedores para descobrir e interagir com as APIs. O portal do desenvolvedor pode ser personalizado para corresponder à identidade visual da sua organização.
Aplicativos Lógicos do Azure. Os Aplicativos Lógicos são usados para orquestrar as chamadas para os serviços de back-end. Os Aplicativos Lógicos podem ser disparados por uma variedade de eventos e podem chamar uma variedade de serviços. Nesta solução, os Aplicativos Lógicos são usados para chamar os serviços de back-end e fornecer conectividade fácil por meio de conectores reduzindo a necessidade de código personalizado.
serviços de back-end. Os serviços de back-end podem ser qualquer serviço ou aplicativo de linha de negócios, como um banco de dados, um serviço Web ou um aplicativo SaaS. Os serviços de back-end podem ser hospedados no Azure ou localmente.
Componentes
- Os Serviços de integração é uma coleção de serviços que você pode usar para integrar aplicativos, dados e processos. Nesta solução, dois desses serviços são usados: Aplicativos Lógicos e Gerenciamento de API. Os Aplicativos Lógicos são usados para facilitar a integração baseada em mensagens entre sistemas e facilitar a conectividade com conectores. O Gerenciamento de API é usado para fornecer uma fachada para os serviços de back-end, permitindo uma interface consistente com a qual os clientes interajam.
- Os Aplicativos Lógicos são uma plataforma sem servidor para compilar fluxos de trabalho corporativos que integram aplicativos, dados e serviços. Nesta solução, os Aplicativos Lógicos são usados para orquestrar as chamadas para os serviços de back-end e fornecer conectividade fácil por meio de conectores, reduzindo a necessidade de código personalizado.
- O Gerenciamento de API é um serviço gerenciado para publicar catálogos de APIs HTTP. Você pode usá-lo para promover a reutilização e a descoberta de suas APIs e implantar um gateway de API para solicitações de API de proxy. Nesta solução, o Gerenciamento de API fornece recursos adicionais, como limitação de taxa, autenticação e cache para os serviços de back-end. Além disso, o Gerenciamento de API fornece um portal de desenvolvedor para que os clientes descubram e interajam com as APIs.
- O DNS do Azure é um serviço de hospedagem para domínios DNS. O DNS do Azure está hospedando os registros DNS públicos para o serviço de Gerenciamento de API. Isso permite que os clientes resolvam o nome DNS para o endereço IP do serviço de Gerenciamento de API.
- Microsoft Entra ID é um serviço de gerenciamento de identidade e acesso baseado em nuvem. Os funcionários da empresa podem usar Microsoft Entra ID para acessar recursos externos e internos. Aqui, a ID do Entra é usada para proteger o serviço de Gerenciamento de API usando OAuth 2.0 e o portal do desenvolvedor usando Entra B2C.
Detalhes do cenário
Os Serviços de integração é 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 de composição são compiladas pela importação de aplicativos lógicos como APIs. Você também pode importar os serviços Web existentes importando especificações da OpenAPI (Swagger) ou importando APIs do SOAP a partir das especificações de WSDL.
O gateway de API ajuda a separar clientes front-end do back-end. Por exemplo, ele pode reescrever URLs ou transformar as solicitações antes que elas atinjam o back-end. Ele também lida com muitas questões transversais, como autenticação, suporte a CORS (compartilhamento de recurso entre origens) e armazenamento em cache da resposta.
Possíveis casos de uso
Essa arquitetura é suficiente para cenários de integração básica em que o fluxo de trabalho é disparado por chamadas síncronas para serviços de back-end. Uma arquitetura mais sofisticada que usa filas e eventos aproveita essa arquitetura básica.
Recomendações
Seus requisitos específicos podem ser diferentes da arquitetura genérica exibida aqui. Use as recomendações nesta seção como um ponto inicial.
Gerenciamento da API
Use as camadas de gerenciamento de API básica, Standard ou Premium. Essas camadas oferecem um SLA (Contrato de Nível de Serviço) de produção e são compatíveis com escala horizontal dentro da região do Azure. A capacidade de taxa de transferência para o Gerenciamento de API é medida em unidades. Cada tipo de preço tem uma expansão máxima. A camada Premium também dá suporte à expansão em várias regiões do Azure. Escolha sua camada com base no conjunto de recursos e o nível de taxa de transferência necessário. Para saber mais, confira Preços do Gerenciamento de API e Capacidade de uma instância de Gerenciamento de API do Azure.
A camada de Consumo de Gerenciamento de API não é recomendada para essa solução porque ela não dá suporte ao portal do desenvolvedor que é necessário para essa arquitetura. A Camada de Desenvolvedor é especificamente para ambientes de não produção e não é recomendada para cargas de trabalho de produção. Uma matriz de recursos que detalha as diferenças entre as camadas pode ser encontrada aqui.
Cada instância de Gerenciamento de API do Azure tem um nome de domínio padrão, que é um subdomínio do azure-api.net, por exemplo, contoso.azure-api.net. Considere a configuração de um domínio personalizado para a sua organização.
Aplicativos Lógicos
Os Aplicativos Lógicos funcionam melhor em cenários que não exigem baixa latência para uma resposta, por exemplo, chamadas à API de execução semi-longa ou assíncronas. Se for necessário ter 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 administrar a API para seus consumidores de API.
Region
Para minimizar a latência de rede, coloque o Gerenciamento de API e os Aplicativos Lógicos na mesma região. Em geral, escolha a região mais próxima dos 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, um conjunto de princípios orientadores que você pode usar para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.
Confiabilidade
A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você deve assumir com seus clientes. Para obter mais informações, confira Visão geral do pilar de confiabilidade.
Examine os SLAs para cada de serviço aqui
Se você implantar o Gerenciamento de API em duas ou mais regiões com o tipo Premium, ele se tornará qualificado para um SLA mais alto. Confira Preços de Gerenciamento de API
Backups
Faça backups regularmente da configuração do seu Gerenciamento de API. Armazene seus arquivos de backup em um local ou região do Azure diferente da região onde o serviço está implantado. Com base em seu RTO, escolha uma estratégia de recuperação de desastres:
No caso de 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 reordene os registros de DNS.
Mantenha uma instância passiva do serviço de Gerenciamento de API em outra região do Azure. Restaure regularmente backups nessa instância, para mantê-la em sincronia com o serviço ativo. Para restaurar o serviço durante um evento de recuperação de desastre, será preciso apenas reordenar os registros DNS. Essa abordagem incorre em custos adicionais, pois 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 restauração. Como os aplicativos lógicos são sem servidor, você pode recriá-los rapidamente em modelos do Azure Resource Manager. Salve os modelos no controle do código-fonte, integre os modelos ao seu processo de CI/CD (integração/implantação contínua). No caso de um evento de recuperação de desastres, 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. É possível atualizar a propriedade de Back-end da API usando um script básico do PowerShell.
Segurança
A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.
Embora essa lista não descreva completamente todas as práticas recomendadas de segurança, vejas essas considerações de segurança que se aplicam especificamente a esta 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 de Aplicativos Lógicos apenas para o endereço IP do Gerenciamento de API. Para saber mais, confira Restringir endereços IP de entrada.
Para garantir que os usuários tenham níveis de acesso apropriados, use o RBAC (controle de acesso baseado em função) do Azure.
Proteja os pontos de extremidade de API públicos no Gerenciamento de API usando OAuth ou OpenID Connect. Para proteger os pontos de extremidade de API públicos, configure um provedor de identidade e adicione uma política de validação de JWT (JSON Web Token). Para saber mais, consulte Proteger uma API usando OAuth 2.0 com o Microsoft Entra ID e o Gerenciamento de API.
Conecte-se aos serviços de back-end do Gerenciamento de API usando certificados mútuos.
Impor HTTPS sobre as APIs de Gerenciamento de API.
Armazenar segredos
Nunca verifique senhas, chaves de acesso ou cadeias de conexão no controle do código-fonte. Se tais valores forem necessários, proteja e implante-os usando as técnicas apropriadas.
Se um aplicativo lógico funcionar com dados confidenciais, consulte Acesso seguro e dados para fluxos de trabalho nos Aplicativos Lógicos do Azure para obter diretrizes detalhadas.
O Gerenciamento de API administra os segredos usando objetos chamados valores ou propriedades nomeadas. Esses objetos armazenam com segurança valores que podem ser acessados por meio das políticas de Gerenciamento de API. Para saber mais, confira Como usar valores nomeados nas políticas de Gerenciamento de API do Azure.
Excelência operacional
A excelência operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, confira Visão geral do pilar de excelência operacional.
DevOps
Crie grupos de recursos separados para ambientes de produção, desenvolvimento e teste. Ter grupos de recursos separados facilita o gerenciamento de implantações, a exclusão de implantações de teste a atribuição de direitos de acesso.
Ao atribuir recursos a grupos de recursos, considere os seguintes fatores:
Ciclo de vida. Em geral, coloque recursos com o mesmo ciclo de vida no mesmo grupo de recursos.
Acesso. Para aplicar políticas de acesso aos recursos em um grupo, use o RBAC (controle de acesso baseado em função) do Azure.
Cobrança. Você pode exibir os custos acumulados para o grupo de recursos.
Tipo de preço para o gerenciamento de API. Use o tipo Desenvolvedor para ambientes de desenvolvimento e teste. Para minimizar os custos durante a pré-produção, implante uma réplica do seu ambiente de produção, execute os testes e desligue.
Implantação
Use modelos do Azure Resource Manager para implantar os recursos do Azure. Siga o processo de IaC (Infraestrutura como Código). Os modelos facilitam a automatização de implantações usando o Azure DevOps Services ou outras soluções de CI/CD.
Staging
Considere a preparação de cargas de trabalho. Isso significa executar uma implantação em vários estágios, depois executar validações em cada estágio antes de avançar para o próximo. Se você usar essa abordagem, é possível efetuar push de atualizações para ambientes de produção de maneira altamente controlada, além de minimizar problemas de implantação inesperados.
A implantação azul-verde e as versões Canary são estratégias de implantação recomendadas para atualizar ambientes de produção dinâmicos. Considere também ter uma boa estratégia de reversão para quando uma implantação falhar. Por exemplo, você poderia reimplantar automaticamente uma implantação anterior bem-sucedida com base em seu histórico de implantações. O parâmetro do sinalizador --rollback-on-error na CLI do Azure é um bom exemplo.
Isolamento de carga de trabalho
Coloque o Gerenciamento de API e os aplicativos lógicos individuais em seus próprios modelos do Resource Manager separados. Usando modelos separados, é possível 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ê fizer uma alteração na configuração do aplicativo lógico ou implantar uma atualização por meio do modelo do Resource Manager, o Azure manterá uma cópia dessa versão, e todas as versões que tiverem uma execução de histórico serão mantidas. Você pode usar essas versões para controlar as 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 oferece suporte a dois conceitos de controle de versão distintos, mas complementares:
Versões permitem que os consumidores escolham uma versão de API com base nas necessidades, por exemplo, v1, v2, beta ou produção.
Revisões permitem que os administradores de API façam alterações sem interrupções em uma API e implantem essas alterações, juntamente com um log de alterações para informar aos consumidores da API sobre as alterações.
É possível fazer uma revisão em um ambiente de desenvolvimento e implantar essa alteração em outros ambientes usando os modelos do Resource Manager. Para saber mais, confira Publicar várias versões de sua API
Você também pode usar as 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 teste de carga ou teste de integração. Use ambientes de pré-produção ou teste separados.
Diagnóstico e monitoramento
Use o Azure Monitor para monitoramento operacional tanto no Gerenciamento de API quanto nos Aplicativos Lógicos. O Azure Monitor fornece informações com base nas métricas que configuradas para cada serviço e é habilitado por padrão. Para saber mais, veja:
- Monitorar APIs publicadas
- Monitorar status, configurar log de diagnósticos e ativar alertas para os Aplicativos Lógicos do Azure
Cada serviço também tem essas opções:
Para análise e painéis mais aprofundados, envie os logs dos Aplicativos Lógicos para o Azure Log Analytics.
Para monitoramento de DevOps, configure o Azure Application Insights para Gerenciamento de API.
O Gerenciamento de API é compatível com o modelo de solução do Power BI para análise de APIs personalizadas. Use esse modelo de solução para criar sua própria solução de análise. Para usuários empresariais, o Power BI disponibiliza relatórios.
Eficiência de desempenho
A eficiência do desempenho é a capacidade de dimensionar sua carga de trabalho para atender às demandas colocadas por usuários de maneira eficiente. Para obter mais informações, consulte Visão geral do pilar de eficiência de desempenho.
Para elevar a escalabilidade do Gerenciamento de API, adicione políticas de cache conforme apropriado. Armazenamento em cache também ajuda a reduzir a carga nos serviços de back-end.
Para oferecer maior capacidade, escale horizontalmente as camadas Básica, Standard e Premium do Gerenciamento de API em uma região do Azure. Para analisar o uso para seu serviço, selecione Métrica de capacidade, no menu Métricas e aumente ou reduza, conforme apropriado. O processo de atualização ou escala pode levar de 15 a 45 minutos para ser aplicado.
Recomendações para colocação em escala de um serviço de Gerenciamento de API:
Considere os padrões de tráfego ao dimensionar. Os clientes com padrões de tráfego mais voláteis precisam de mais capacidade.
Capacidade consistente acima de 66% pode indicar a necessidade de expansão.
Capacidade consistente abaixo de 20% pode indicar uma oportunidade para reduzir verticalmente.
Antes de habilitar a carga em produção, sempre realize teste de carga no seu serviço do Gerenciamento de API com uma carga representativa.
Com o tipo Premium, você pode dimensionar uma instância do Gerenciamento de API em várias regiões do Azure. Isso qualifica o Gerenciamento de API para um SLA mais alto e permite que você provisione serviços próximos aos usuários em várias regiões.
Em modelos sem servidor dos Aplicativos Lógicos, os administradores não precisam planejar a escalabilidade do serviço. O serviço é dimensionado automaticamente para atender à demanda.
Otimização de custo
Em geral, use a calculadora de preços do Azure para estimar os custos. Confira outras considerações.
Gerenciamento da API
Você será cobrado por todas as instâncias de Gerenciamento de API quando estiverem em execução. Se você tiver escalado verticalmente e não precisar desse nível de desempenho o tempo todo, reduza verticalmente de forma manual ou configure o dimensionamento automático.
Aplicativos Lógicos
Os Aplicativos lógicos usam um modelo sem servidor. A cobrança é calculada com base na ação e execução do conector. Para obter mais informações, consulte Preços de Aplicativos Lógicos.
Para obter mais informações, confira a seção de custo em Estrutura Bem Projetada do Microsoft Azure.
Próximas etapas
Recursos relacionados
Para obter mais confiabilidade e escalabilidade, use filas de mensagens e eventos para separar os sistemas de back-end. Essa arquitetura é exibida no próximo artigo desta série:
Você também pode se interessar nestes artigos do Centro de Arquitetura do Azure: