Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
O Flex Consumption é um plano de hospedagem do Azure Functions baseado em Linux que se baseia no modelo de cobrança Consumo pago pelo que você usa sem servidor. Ele oferece mais flexibilidade e personalização, introduzindo redes privadas, seleção de tamanho de memória de instância e recursos de expansão rápida/grande ainda baseados em um modelo sem servidor .
Você pode revisar amostras de ponta a ponta que apresentam o plano Flex Consumption no repositório de amostras do plano Flex Consumption.
Benefits
O plano Flex Consumption baseia-se nos pontos fortes do plano de Consumo sem servidor, que incluem dimensionamento dinâmico e faturamento baseado em execução. Com o Flex Consumption, você também obtém estes recursos extras:
- Tempos de arranque a frio reduzidos: permita que instâncias sempre prontas obtenham tempos de arranque a frio mais rápidos em comparação com o plano de consumo.
- Suporte de rede virtual: a integração de rede virtual permite que seu aplicativo sem servidor seja executado em uma rede virtual.
- Dimensionamento por Função: cada função na sua aplicação escala de forma independente com base na carga de trabalho, potencialmente resultando numa alocação de recursos mais eficiente.
- Manipulação de simultaneidade aprimorada: melhor manuseio de execuções simultâneas com configurações configuráveis de simultaneidade por função.
- Configuração flexível de memória: o Flex Consumption oferece várias opções de tamanho de memória de instância , permitindo que você otimize para seus requisitos específicos de carga de trabalho.
Esta tabela ajuda você a comparar diretamente os recursos do Flex Consumption com o plano de hospedagem Consumption:
Feature | Consumo | Consumo Flexível |
---|---|---|
Reduzir para zero | ✅ Sim | ✅ Sim |
Comportamento de escalonamento | Impulsionado por eventos | Orientado por eventos (rápido) |
Redes virtuais | ❌ Não suportado | ✅ Suportado |
Computação dedicada (atenuar arranques a frio) | ❌ Nenhum | ✅ Instâncias sempre disponíveis (opcional) |
Billing | Apenas tempo de execução | Tempo de execução + instâncias sempre prontas |
Instâncias de expansão (máx.) | 200 | 1000 |
Para uma comparação completa do plano Flex Consumption com o plano Consumo e todos os outros tipos de plano e hospedagem, veja escala de funções e opções de hospedagem.
Integração da rede virtual
O Flex Consumption expande os benefícios tradicionais do plano Consumption adicionando suporte para integração de rede virtual. Quando seus aplicativos são executados em um plano Flex Consumption, eles podem se conectar a outros serviços do Azure protegidos em uma rede virtual. Tudo isso, permitindo-lhe ainda tirar partido do faturamento e da escalabilidade sem servidor, bem como dos benefícios de escala e taxa de transferência do plano de Consumo Flexível. Para obter mais informações, consulte Habilitar integração de rede virtual.
Memória de instância
Ao criar seu aplicativo de função em um plano Flex Consumption, você pode selecionar o tamanho da memória das instâncias nas quais seu aplicativo é executado. Consulte Faturamento para saber como os tamanhos de memória da instância afetam os custos do seu aplicativo funcional.
Atualmente, o Flex Consumption oferece estas opções de tamanho de memória de instância: 512 MB, 2.048 MB e 4.096 MB.
Ao decidir qual tamanho de memória de instância usar com seus aplicativos, aqui estão algumas coisas a considerar:
- O tamanho da memória da instância de 2.048 MB é o padrão e deve ser usado para a maioria dos cenários. Os tamanhos de memória de instância de 512 MB e 4.096 MB estão disponíveis para cenários que melhor se adequam aos requisitos de simultaneidade ou de poder de processamento do seu aplicativo. Para obter mais informações, consulte Configurar a memória da instância.
- Você pode alterar o tamanho da memória da instância a qualquer momento. Para obter mais informações, consulte Configurar a memória da instância.
- Os recursos da instância são compartilhados entre o código da função e o host Functions.
- Quanto maior o tamanho da memória da instância, mais cada instância pode lidar com execuções simultâneas ou cargas de trabalho de CPU ou memória mais intensivas. As decisões de escala específicas são específicas da carga de trabalho.
- A simultaneidade padrão de gatilhos HTTP depende do tamanho da memória da instância. Para obter mais informações, consulte Simultaneidade de disparador HTTP.
- As CPUs disponíveis e a largura de banda da rede são fornecidas proporcionalmente a um tamanho de instância específico.
Dimensionamento por função
A simultaneidade é um fator-chave que determina como as aplicações de função Flex Consumption são dimensionadas. Para melhorar o desempenho de escala de aplicativos com vários tipos de gatilho, o plano Flex Consumption fornece uma maneira mais determinística de dimensionar seu aplicativo por função.
Esse comportamento de dimensionamento por função faz parte da plataforma de hospedagem, portanto, você não precisa configurar seu aplicativo ou alterar o código. Para obter mais informações, consulte Dimensionamento por função no artigo Dimensionamento controlado por eventos.
No dimensionamento por função, as decisões são tomadas para determinados gatilhos de função com base em agregações de grupo. Esta tabela mostra o conjunto definido de grupos de escala de funções:
Grupos de escala | Gatilhos em grupo | Valor das configurações |
---|---|---|
Gatilhos HTTP |
Gatilho HTTP Gatilho SignalR |
http |
Gatilhos de armazenamento de blobs (Baseado em grade de eventos) |
Gatilho de armazenamento Blob | blob |
Durable Functions |
Disparador de orquestração Disparador de atividade Disparador de entidades |
durable |
Todas as outras funções no aplicativo são dimensionadas individualmente em seu próprio conjunto de instâncias, que são referenciadas usando a convenção function:<NAMED_FUNCTION>
.
Instâncias sempre prontas
O Flex Consumption inclui um recurso sempre pronto que permite escolher instâncias que estão continuamente a funcionar e atribuídas a cada um dos grupos de escala por função ou funções individuais. Sempre pronto é uma ótima opção para cenários em que você precisa ter um número mínimo de instâncias sempre pronto para lidar com solicitações. Por exemplo, para reduzir a latência de arranque a frio da sua aplicação. O padrão é 0 (zero).
Por exemplo, se você definir sempre pronto como 2 para seu grupo de funções HTTP, a plataforma manterá duas instâncias sempre em execução e atribuídas ao seu aplicativo para suas funções HTTP no aplicativo. Essas instâncias estão a processar as suas execuções de função, mas dependendo das configurações de concorrência, a plataforma pode expandir além dessas duas instâncias com instâncias sob demanda.
Pelo menos duas instâncias sempre prontas podem ser configuradas por função ou grupo de funções enquanto a redundância de zona está ativada.
Para saber como configurar instâncias sempre prontas, consulte Definir contagens de instâncias sempre prontas.
Concurrency
Simultaneidade refere-se ao número de execuções paralelas de uma função em uma instância do seu aplicativo. Você pode definir um número máximo de execuções simultâneas que cada instância deve manipular a qualquer momento. A simultaneidade tem um efeito direto sobre a forma como seu aplicativo é dimensionado porque, em níveis mais baixos de simultaneidade, você precisa de mais instâncias para lidar com a demanda orientada por eventos para uma função. Embora você possa controlar e ajustar a simultaneidade, fornecemos padrões que funcionam para a maioria dos casos.
Para saber como definir limites de simultaneidade para funções de gatilho HTTP, consulte Definir limites de simultaneidade HTTP. Para saber como definir limites de simultaneidade para funções de gatilho não-HTTP, consulte Target Base Scaling.
Deployment
As implantações no plano Flex Consumption seguem um único caminho e não há mais a necessidade de as configurações do aplicativo influenciarem o comportamento da implantação. Depois de o código do projeto ser construído e comprimido em um pacote de aplicação, é implementado num contentor de armazenamento de blobs. Na inicialização, seu aplicativo obtém o pacote e executa seu código de função a partir desse pacote. Por padrão, a mesma conta de armazenamento usada para armazenar metadados de host interno (AzureWebJobsStorage) também é usada como contêiner de implantação. No entanto, você pode usar uma conta de armazenamento alternativa ou escolher seu método de autenticação preferido definindo as configurações de implantação do seu aplicativo.
Billing
Há dois modos pelos quais seus custos são determinados ao executar seus aplicativos no plano Flex Consumption. Cada modo é determinado por instância.
Modo de faturação | Description |
---|---|
Sob Demanda | Ao executar no modo sob demanda , você é cobrado apenas pela quantidade de tempo que o código da função está sendo executado em suas instâncias disponíveis. No modo sob demanda, nenhuma contagem mínima de instâncias é necessária. Você é cobrado por: • A quantidade total de memória provisionada enquanto cada instância sob demanda está executando ativamente funções (em GB-segundos), menos uma concessão gratuita de GB-s por mês. • O número total de execuções, menos uma isenção gratuita (número) de execuções por mês. |
Sempre pronto | Você pode configurar uma ou mais instâncias, atribuídas a tipos de gatilho específicos (HTTP/Durable/Blob) e funções individuais, que estão sempre disponíveis para lidar com solicitações. Quando tiver instâncias sempre disponíveis habilitadas, será cobrado por: • A quantidade total de memória provisionada em todas as suas instâncias sempre prontas, conhecida como linha de base (em GB-segundos). • A quantidade total de memória provisionada durante o tempo em que cada instância sempre pronta está executando ativamente funções (em GB-segundos). • O número total de execuções. Na faturação sempre pronta, não há subvenções gratuitas. |
Para obter as informações mais up-tosobre preços de execução, custos de linha de base sempre prontos e concessões gratuitas para execuções sob demanda, consulte a página de preços do Azure Functions.
O período mínimo de execução faturável para ambos os modos de execução é de 1.000 ms. Passado isso, o período de atividade faturável é arredondado para os 100 ms mais próximos. Você pode encontrar detalhes sobre os medidores de faturamento do plano Flex Consumption na referência Monitoramento.
Para obter detalhes sobre como os custos são calculados quando você executa em um plano Flex Consumption, incluindo exemplos, consulte Custos baseados no consumo.
Versões de pilha de idiomas suportadas
Esta tabela mostra as versões do stack de linguagem atualmente suportadas para aplicações Flex Consumption.
Pilha de idiomas | Versão necessária |
---|---|
C# (modo de processo isolado)1 | .NET 82, .NET 93 |
Java | Java 11, Java 17, Java 21 |
Node.js | Node.js 20, Node.js 22 |
PowerShell | PowerShell 7.4 |
Python | Python 3.10, Python 3.11, Python 3.12 |
- O modo em processo C# não é suportado. Em vez disso, você precisa migrar seu projeto de código .NET para ser executado no modelo de trabalho isolado.
- Requer a versão
1.20.0
ou posterior do Microsoft.Azure.Functions.Worker e a versão1.16.2
ou posterior do Microsoft.Azure.Functions.Worker.Sdk. - Requer a versão
2.0.0
ou posterior de Microsoft.Azure.Functions.Worker e Microsoft.Azure.Functions.Worker.Sdk.
Cotas regionais de memória de assinatura
O plano Flex Consumption tem uma cota baseada em memória que limita a quantidade de computação que todos os seus aplicativos Flex Consumption podem usar ao mesmo tempo em uma região e assinatura específicas. Imagine que você tem um bucket de memória medido em GB para toda a sua assinatura em uma região. Todos os seus aplicativos Flex Consumption nessa região compartilham esse bucket. Se seus aplicativos Flex Consumption tentarem usar mais do que a cota permite, algumas execuções poderão ser atrasadas ou limitadas no dimensionamento, mas você não será impedido de criar ou implantar aplicativos.
Atualmente, cada região em uma determinada assinatura tem uma cota de limite de memória padrão para 512,000 MB
todas as instâncias de aplicativos executados em planos Flex Consumption. Essa cota significa que, em uma determinada assinatura e região, você pode ter qualquer combinação de tamanhos e contagens de memória de instância, desde que permaneçam abaixo do limite de cota. Por exemplo, cada um dos exemplos a seguir significaria que a cota seria atingida e os aplicativos parariam de dimensionar:
- Você tem um aplicativo de 512 MB dimensionado para 250 instâncias e um segundo aplicativo de 512 MB dimensionado para 750 instâncias.
- Você tem um aplicativo de 512 MB dimensionado para 1.000 instâncias.
- Você tem um aplicativo de 2.048 MB dimensionado para 100 e um segundo aplicativo de 2.048 MB dimensionado para 150 instâncias
- Você tem um aplicativo de 2.048 MB que foi expandido para 250 instâncias
- Você tem um aplicativo de 4.096 MB que foi expandido para 125 instâncias
- Você tem um aplicativo de 4.096 MB dimensionado para 100 e um aplicativo de 2.048 MB dimensionado para 50 instâncias
Os aplicativos Flex Consumption reduzidos a zero ou instâncias marcadas para serem reduzidas e excluídas não contam para o limite. Essa cota pode ser aumentada para permitir que seus aplicativos Flex Consumption sejam dimensionados ainda mais, dependendo de suas necessidades. Se os seus aplicativos necessitarem de uma quota maior, crie um pedido de suporte.
Propriedades e configurações preteridas
No plano Flex Consumption, muitas das configurações padrão da aplicação e das propriedades de configuração do site foram descontinuadas ou movidas e não devem ser usadas ao automatizar a criação de recursos de aplicações em funções. Para obter mais informações, consulte Descontinuações do plano Flex Consumption.
Considerations
Tenha estas outras considerações em mente ao usar o plano Flex Consumption:
- Aplicativos por plano: apenas um aplicativo é permitido por plano Flex Consumption.
- Host: há um tempo limite de 30 segundos para a inicialização do aplicativo. Quando a sua app de funções leva mais de 30 segundos para iniciar, pode ver entradas relacionadas ao gRPC registadas. No momento, não é possível configurar esse tempo limite. Para obter mais informações, consulte este item de trabalho do host.
- Funções duráveis: o Armazenamento do Azure é atualmente o único provedor de armazenamento com suporte para Funções Duráveis quando hospedado no plano Flex Consumption. Veja as recomendações ao hospedar Funções Duráveis no plano Flex Consumption.
-
Integração de rede virtual Certifique-se de que o provedor de recursos do Azure esteja habilitado
Microsoft.App
para sua assinatura seguindo estas instruções. A delegação de sub-rede exigida pelas aplicações Flex Consumption éMicrosoft.App/environments
. -
Triggers: Embora todos os triggers sejam totalmente suportados num plano Flex Consumption, o trigger de Blob Storage suporta apenas a origem do Event Grid. Os aplicativos de função não-C# devem usar a versão
[4.0.0, 5.0.0)
do pacote de extensão ou uma versão posterior. - Regiões: Nem todas as regiões são suportadas atualmente. Para saber mais, consulte Exibir regiões atualmente suportadas.
- Implantações: Atualmente, não há suporte para slots de implantação.
-
Escala: A escala máxima mais baixa é atualmente
40
. O valor mais alto suportado atualmente é1000
. - Dependências gerenciadas: as dependências gerenciadas no PowerShell não são suportadas pelo Flex Consumption. Em vez disso, você deve carregar módulos com conteúdo do aplicativo.
- Certificados: o carregamento de certificados com a configuração WEBSITE_LOAD_CERTIFICATES aplicativo, certificados gerenciados, certificados de serviço de aplicativo e outros recursos baseados em certificados de plataforma, como endToEndEncryptionEnabled, não são suportados no momento.
-
Fusos horários:
WEBSITE_TIME_ZONE
eTZ
as definições da aplicação não são atualmente suportadas quando executadas no plano Flex Consumption.
Artigos relacionados
Opções de hospedagem do Azure FunctionsCriar e gerenciar aplicativos de função no plano Flex Consumption