Esta arquitetura de referência utiliza o 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 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 em que a empresa implementou ou depende. Estes sistemas podem incluir sistemas SaaS, outros serviços do Azure ou serviços Web que expõem pontos finais REST ou SOAP.
Azure Logic Apps. Nesta arquitetura, as aplicações lógicas são acionadas por pedidos HTTP. Também pode aninhar fluxos de trabalho para orquestração mais complexa. O Logic Apps utiliza conectores para integrar com serviços utilizados frequentemente. O Logic Apps oferece centenas de conectores e pode criar conectores personalizados.
Azure Gestão de API. Gestão de API consiste em dois componentes relacionados:
Gateway de API. O gateway de API aceita chamadas HTTP e encaminha-as para o back-end.
Portal do programador. Cada instância do Azure Gestão de API fornece acesso a um portal de programador. Este portal dá aos programadores acesso à documentação e exemplos de código para chamar as APIs. Também pode testar APIs no portal do programador.
DNS do Azure. O DNS do Azure oferece resolução de nomes através da infraestrutura do Azure. Ao alojar os seus domínios no Azure, pode gerir os seus registos DNS com as mesmas credenciais, APIs, ferramentas e faturação que utiliza para os seus outros serviços do Azure. Para utilizar um nome de domínio personalizado, como contoso.com, crie registos DNS que mapeiem o nome de domínio personalizado para o endereço IP. Para obter mais informações, veja Configurar um nome de domínio personalizado no Gestão de API.
Azure Active Directory (Azure AD). Utilize Azure AD para autenticar clientes que chamam o gateway de API. Azure AD suporta o protocolo OpenID Connect (OIDC). Os clientes obtêm um token de acesso a partir de Azure AD e o Gateway de API valida o token para autorizar o pedido. Se utilizar o escalão Standard ou Premium de Gestão de API, Azure AD também pode ajudar a proteger o acesso ao portal do programador.
Componentes
- O Integration Services é uma coleção de serviços que pode utilizar para integrar aplicações, dados e processos.
- O Logic Apps é uma plataforma sem servidor para criar fluxos de trabalho empresariais que integram aplicações, dados e serviços.
- Gestão de API é um serviço gerido para publicar catálogos de APIs HTTP. Pode utilizá-lo para promover a reutilização e deteção das SUAS APIs e para implementar um gateway de API em pedidos de API proxy.
- O DNS do Azure é um serviço de alojamento para domínios DNS.
- Azure AD é um serviço de gestão de identidades e acessos baseado na cloud. Os colaboradores empresariais podem utilizar Azure AD para aceder a recursos externos e internos.
Detalhes do cenário
O Integration Services é uma coleção de serviços que pode utilizar para integrar aplicações, dados e processos para a sua empresa. Esta arquitetura utiliza dois desses serviços: o Logic Apps para orquestrar fluxos de trabalho e Gestão de API para criar catálogos de APIs.
Nesta arquitetura, as APIs compostas são criadas ao importar aplicações lógicas como APIs. Também pode importar serviços Web existentes ao importar especificações openAPI (Swagger) ou importar APIs SOAP de especificações WSDL.
O gateway de API ajuda a desassociar os clientes de front-end do back-end. Por exemplo, pode reescrever URLs ou transformar pedidos antes de chegarem ao back-end. Também lida com muitas preocupações cruzadas, como autenticação, suporte de partilha de recursos entre origens (CORS) e colocação em cache de respostas.
Potenciais casos de utilização
Esta arquitetura é suficiente para cenários de integração básicos em que o fluxo de trabalho é acionado por chamadas síncronas para serviços de back-end. Uma arquitetura mais sofisticada com filas e eventos baseia-se nesta arquitetura básica.
Recomendações
Os seus requisitos específicos podem ser diferentes da arquitetura genérica apresentada aqui. Utilize as recomendações nesta secção como um ponto de partida.
Gestão de API
Utilize os escalões Gestão de API Básico, Standard ou Premium. Estes escalões oferecem um contrato de nível de serviço de produção (SLA) e um aumento horizontal do suporte na região do Azure. A capacidade de débito para Gestão de API é medida em unidades. Cada escalão de preço tem um aumento horizontal máximo. O escalão Premium também suporta o aumento horizontal em várias regiões do Azure. Escolha o seu escalão com base no conjunto de funcionalidades e no nível de débito necessário. Para obter mais informações, veja Gestão de API preços e Capacidade de uma instância do Azure Gestão de API.
Cada instância do Azure Gestão de API tem um nome de domínio predefinido, que é um subdomínio de azure-api.net, por exemplo, contoso.azure-api.net. Considere configurar um domínio personalizado para a sua organização.
Logic Apps
O Logic Apps funciona melhor em cenários que não requerem baixa latência para uma resposta, como chamadas de API assíncronas ou semi-longas. Se for necessária baixa latência, por exemplo, numa chamada que bloqueia uma interface de utilizador, utilize uma tecnologia diferente. Por exemplo, utilize Funções do Azure ou uma API Web implementada para Serviço de Aplicações do Azure. Utilize Gestão de API para fazer frente à API aos consumidores de API.
Região
Para minimizar a latência de rede, coloque Gestão de API e Logic Apps na mesma região. Em geral, selecione a região mais próxima dos seus utilizadores (ou mais próxima dos seus serviços de back-end).
Considerações
Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que pode utilizar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, veja Microsoft Azure Well-Architected Framework.
Fiabilidade
A fiabilidade garante que a sua aplicação pode cumprir os compromissos que assumiu com os seus clientes. Para obter mais informações, veja Descrição geral do pilar de fiabilidade.
Reveja o SLA para cada serviço:
Se implementar Gestão de API em duas ou mais regiões com o escalão Premium, é elegível para um SLA superior. Veja Gestão de API preços.
Cópias de segurança
Faça uma cópia de segurança regular da configuração do Gestão de API. Armazene os ficheiros de cópia de segurança numa localização ou região do Azure diferente da região onde o serviço é implementado. Com base no SEU RTO, escolha uma estratégia de recuperação após desastre:
Num evento de recuperação após desastre, aprovisione uma nova instância Gestão de API, restaure a cópia de segurança para a nova instância e volte a indicar os registos DNS.
Mantenha uma instância passiva do serviço Gestão de API noutra região do Azure. Restaure regularmente cópias de segurança para essa instância, para mantê-la sincronizada com o serviço ativo. Para restaurar o serviço durante um evento de recuperação após desastre, só precisa de repointar os registos DNS. Esta abordagem implica custos adicionais porque paga a instância passiva, mas reduz o tempo de recuperação.
Para aplicações lógicas, recomendamos uma abordagem de configuração como código para criar cópias de segurança e restaurar. Uma vez que as aplicações lógicas não têm servidor, pode recriá-las rapidamente a partir de modelos do Azure Resource Manager. Guarde os modelos no controlo de origem, integre os modelos com o processo de integração/implementação contínua (CI/CD). Num evento de recuperação após desastre, implemente o modelo numa nova região.
Se implementar uma aplicação lógica numa região diferente, atualize a configuração no Gestão de API. Pode atualizar a propriedade Back-end da API com um script básico do PowerShell.
Segurança
A segurança fornece garantias contra ataques deliberados e abuso dos seus valiosos dados e sistemas. Para obter mais informações, veja Descrição geral do pilar de segurança.
Embora esta lista não descreva completamente todas as melhores práticas de segurança, seguem-se algumas considerações de segurança que se aplicam especificamente a esta arquitetura:
O serviço Gestão de API do Azure tem um endereço IP público fixo. Restringir o acesso para chamar pontos finais do Logic Apps apenas para o endereço IP do Gestão de API. Para obter mais informações, veja Restringir endereços IP de entrada.
Para garantir que os utilizadores têm níveis de acesso adequados, utilize o controlo de acesso baseado em funções do Azure (RBAC do Azure).
Proteja os pontos finais da API pública no Gestão de API com o OAuth ou o OpenID Connect. Para proteger pontos finais de API públicos, configure um fornecedor de identidade e adicione uma política de validação JSON Web Token (JWT). Para obter mais informações, veja Proteger uma API com o OAuth 2.0 com o Azure Active Directory e Gestão de API.
Ligue-se a serviços de back-end a partir de Gestão de API através de certificados mútuos.
Impor HTTPS nas APIs de Gestão de API.
Armazenar segredos
Nunca selecione palavras-passe, chaves de acesso ou cadeias de ligação no controlo de origem. Se estes valores forem necessários, proteja e implemente estes valores com as técnicas adequadas.
Se uma aplicação lógica exigir valores confidenciais que não pode criar num conector, armazene esses valores no Azure Key Vault e faça referência aos mesmos a partir de um modelo de Resource Manager. Utilize parâmetros de modelo de implementação e ficheiros de parâmetros para cada ambiente. Para obter mais informações, veja Secure parameters and inputs within a workflow (Proteger parâmetros e entradas num fluxo de trabalho).
Gestão de API gere segredos com objetos denominados valores ou propriedades nomeados. Estes objetos armazenam de forma segura valores aos quais pode aceder através de políticas de Gestão de API. Para obter mais informações, veja How to use Named Values in Azure Gestão de API policies (Como utilizar Valores Nomeados nas políticas de Gestão de API do Azure).
Excelência operacional
A excelência operacional abrange os processos de operações que implementam uma aplicação e a mantêm em execução em produção. Para obter mais informações, veja Descriçã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.
Quando 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.
Access. Para aplicar políticas de acesso aos recursos num grupo, pode utilizar o controlo de acesso baseado em funções do Azure (RBAC do Azure).
Faturação. Pode ver os custos de rollup do grupo de recursos.
Escalão de preço para Gestão 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
Utilize modelos do Azure Resource Manager para implementar os recursos do Azure e siga a infraestrutura como Processo de Código (IaC). Os modelos facilitam a automatização de implementações com os Serviços de DevOps do Azure ou outras soluções CI/CD.
Processo de teste
Considere testar as cargas de trabalho, o que significa implementar em várias fases e executar validações em cada fase antes de avançar para a próxima. Se utilizar esta abordagem, pode emitir atualizações para os seus ambientes de produção de forma altamente controlada e minimizar problemas de implementação inesperados. A implementação azul-verde e as versões Canary são estratégias de implementação recomendadas para atualizar ambientes de produção em direto. Considere também ter uma boa estratégia de reversão para quando uma implementação falhar. Por exemplo, pode reimplementar automaticamente uma implementação anterior e bem-sucedida do histórico de implementações. O --rollback-on-error parâmetro de sinalizador na CLI do Azure é um bom exemplo.
Isolamento de cargas de trabalho
Coloque Gestão de API e quaisquer aplicações lógicas individuais nos seus próprios modelos de Resource Manager separados. Ao utilizar modelos separados, pode armazenar os recursos em sistemas de controlo de origem. Pode implementar os modelos em conjunto ou individualmente como parte de um processo de CI/CD.
Versões
Sempre que alterar a configuração de uma aplicação lógica ou implementar uma atualização através de um modelo de Resource Manager, 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ções. Pode utilizar estas versões para controlar as alterações históricas ou promover uma versão como a configuração atual da aplicação lógica. Por exemplo, pode reverter uma aplicação lógica para uma versão anterior.
Gestão de API suporta dois conceitos de controlo de versões distintos mas complementares:
As versões permitem que os consumidores de API escolham uma versão da API com base nas suas necessidades, por exemplo, v1, v2, beta ou produção.
As revisões permitem que os administradores de API façam alterações não interruptivas numa API e implementem essas alterações, juntamente com um registo de alterações para informar os consumidores de API sobre as alterações.
Pode fazer uma revisão num ambiente de desenvolvimento e implementar essa alteração noutros ambientes com Resource Manager modelos. Para obter mais informações, consulte Publicar várias versões da sua API
Também pode utilizar revisões para testar uma API antes de tornar as alterações atuais e acessíveis aos utilizadores. No entanto, este método não é recomendado para testes de carga ou testes de integração. Em vez disso, utilize ambientes de teste ou pré-produção separados.
Diagnóstico e monitorização
Utilize o Azure Monitor para monitorização operacional no Gestão de API e no Logic Apps. O Azure Monitor fornece informações com base nas métricas configuradas para cada serviço e está ativada por predefiniçã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 dashboards mais aprofundados, envie registos do Logic Apps para o Azure Log Analytics.
Para a monitorização do DevOps, configure o Aplicação Azure Insights para Gestão de API.
Gestão de API suporta o modelo de solução do Power BI para análise de API personalizada. Pode utilizar este modelo de solução para criar a sua própria solução de análise. Para utilizadores empresariais, 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, veja Descrição geral do pilar Eficiência do desempenho.
Para aumentar a escalabilidade do Gestão de API, adicione políticas de colocação em cache, sempre que adequado. A colocação em cache também ajuda a reduzir a carga nos serviços de back-end.
Para oferecer uma maior capacidade, pode aumentar horizontalmente Gestão de API os escalões Básico, Standard e Premium do Azure numa região do Azure. Para analisar a utilização do seu serviço, selecione Métrica de Capacidade no menu Métricas e, em seguida, aumente verticalmente ou reduza verticalmente conforme adequado. 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 Gestão 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.
Uma capacidade consistente superior a 66% pode indicar a necessidade de aumentar verticalmente.
Uma capacidade consistente inferior a 20% pode indicar uma oportunidade para reduzir verticalmente.
Antes de ativar a carga na produção, teste sempre o Gestão de API serviço com uma carga representativa.
Com o escalão Premium, pode dimensionar uma instância Gestão de API em várias regiões do Azure. Isto torna Gestão de API elegíveis para um SLA superior e permite-lhe aprovisionar serviços perto de utilizadores em várias regiões.
O modelo sem servidor do Logic Apps significa que os administradores não têm de planear a escalabilidade do serviço. O serviço dimensiona automaticamente para satisfazer a procura.
Otimização de custos
Em geral, utilize a calculadora de preços do Azure para estimar os custos. Seguem-se outras considerações.
Gestão de API
São-lhe cobradas todas as instâncias Gestão de API quando estão em execução. Se tiver aumentado verticalmente e não precisar sempre desse nível de desempenho, reduza verticalmente manualmente ou configure o dimensionamento automático.
Logic Apps
O Logic Apps utiliza um modelo sem servidor . A faturação é calculada com base na execução da ação e do conector. Para obter mais informações, veja Preços do Logic Apps.
Para obter mais informações, veja a secção de custos Well-Architected Framework do Microsoft Azure.
Passos seguintes
Recursos relacionados
Para maior fiabilidade e escalabilidade, utilize filas de mensagens e eventos para desassociar os sistemas de back-end. Esta arquitetura é apresentada no próximo artigo desta série:
Também poderá estar interessado nestes artigos do Centro de Arquitetura do Azure: