Escolha uma opção de computação do Azure para microsserviços

Este artigo ajuda-o a escolher uma plataforma de computação Azure para uma carga de trabalho construída numa arquitetura de microserviços. Uma arquitetura de microserviços consiste em pequenos serviços implantáveis de forma independente que comunicam através da rede. A sua plataforma de computação precisa de suportar escalabilidade independente, implementação independente e comunicação interserviços fiável entre muitos serviços.

Para fatores de decisão que se aplicam a qualquer carga de trabalho, como competências de equipa, networking e portabilidade, veja Escolher um serviço de computação Azure. Este artigo foca-se nos fatores que importam especificamente para os microserviços.

Plataformas de computação Azure para microserviços

As seguintes plataformas Azure suportam cargas de trabalho de microserviços. Diferem na quantidade de orquestração, comunicação entre serviços e comportamento de escalabilidade que proporcionam.

Serviço de Kubernetes do Azure (AKS)

O Azure Kubernetes Service (AKS) é um serviço Kubernetes gerido que fornece acesso direto às APIs Kubernetes e ao plano de controlo. AKS fornece gestão de nós, aplicação de patches e atualizações automáticas opcionais. Configuras o cluster, as políticas de rede e de escalabilidade.

Para microserviços, o AKS suporta malhas de serviço como o Istio para gestão de tráfego e Segurança da Camada de Transporte Mútua (mTLS), escalabilidade em cada deployment através do Horizontal Pod Autoscaler (HPA) e Kubernetes Autoscaling Impulsionada por Eventos (KEDA) e estratégias de implementação nativas do Kubernetes como atualizações em sequência e lançamentos canários.

AKS Automatic é um modo de AKS que pré-configura a gestão, escalabilidade, segurança e observabilidade dos nós com base em recomendações bem arquitetadas do AKS, para que as equipas obtenham um cluster pronto para produção sem configuração por capacidade.

Azure Container Apps

Azure Container Apps é um serviço gerido construído sobre Kubernetes que abstrai a gestão de clusters.

O Container Apps oferece funcionalidades integradas para microserviços, incluindo descoberta de serviços, integração Dapr para invocação de serviço a serviço com mTLS, mensagens entre editores e subscritores e gestão de estados. A escalabilidade automática baseada em KEDA permite escalabilidade orientada por eventos, incluindo escala até zero. As Aplicações Container também suportam a divisão de tráfego entre revisões para implementações canário e tarefas para tarefas sob demanda, agendadas ou orientadas a eventos.

O Container Apps não expõe APIs do Kubernetes. Se a sua ferramenta de implementação ou configuração da malha de serviço depender de primitivas Kubernetes, use AKS em vez disso.

Funções do Azure

O Azure Functions é um serviço de computação serverless e orientado por eventos, adequado para microserviços que respondem a gatilhos como pedidos HTTP, mensagens em fila ou temporizadores. O Functions escala cada aplicação de funções de forma independente e pode escalar até zero. Para microserviços, implemente cada serviço como uma aplicação de função própria.

O Functions não fornece descoberta de serviços ao nível da plataforma nem comunicação interserviços. Implemente essas capacidades no código da aplicação ou através de serviços externos como o Azure API Management.

O Functions suporta múltiplas linguagens de programação. Também pode executar o modelo de programação de Funções nas Aplicações Container, que combina gatilhos e ligações de Funções com funcionalidades de rede e escalabilidade das Aplicações Container.

Serviço de Aplicações do Azure

O Azure App Service adequa-se a microserviços baseados em HTTP, como APIs web. O App Service suporta a implementação como código ou como um único contentor. Fornece escalonamento automático incorporado, espaços de implementação para implementações azul-verde e roteamento de tráfego baseado em percentagem, e integração com ciclos de integração contínua e entrega contínua (CI/CD). App Service não fornece descoberta de serviço, por isso adequa-se a microsserviços que comunicam através de mensagens externas ou de um gateway de API, em vez de dependerem da comunicação interserviços ao nível da plataforma.

Azure Red Hat OpenShift

O Azure Red Hat OpenShift fornece clusters OpenShift totalmente geridos e estende o Kubernetes com uma experiência de programador opinativa. A Red Hat e a Microsoft projetam, operam e apoiam conjuntamente o serviço. Use o Azure Red Hat OpenShift quando a sua organização padronizar o OpenShift.

Compare plataformas para microserviços

A tabela seguinte compara como cada plataforma suporta as capacidades que importam para uma arquitetura de microserviços. Para uma comparação mais detalhada das plataformas de alojamento de contentores Azure e as suas capacidades, consulte Escolha um serviço de contentor Azure.

Funcionalidade AKS Container Apps Funções Serviço de Aplicações
Descoberta de serviços Sistema de Nomes de Domínio Kubernetes (DNS), malha de serviço Incorporado, Dapr Nenhum (nível de app) Nenhum (nível de app)
Comunicação entre serviços Malha de serviço (Service mesh) (Istio) Dapr, nível de ambiente Nenhum (nível de app) Nenhum (nível da aplicação)
Mensagens publicador-assinante App-level (como Azure Service Bus, Azure Event Hubs) Dapr pub/sub Ligações Nível do aplicativo
Dimensionamento independente Por cada implementação (HPA, KEDA) Por aplicação (KEDA) Aplicação por função (por função no Flex) Plano de serviço Per-App
Reduzir para zero Parcial (apenas agrupamentos de nós de utilizador) Yes Sim (Planos de Consumo ou Consumo Flexível) No
Mitigação do arranque a frio Número mínimo de nós, réplicas mínimas de pods Número mínimo de réplicas Instâncias pré-aquecidas ou sempre prontas (Premium ou Flex Consumption) Não aplicável (Sempre Ligado)
Divisão de tráfego e implantações de canários Kubernetes-native, malha de serviço Baseado em revisões Espaços de implantação (Premium/Dedicado) Espaços de implementação que incluem o encaminhamento de tráfego
Rastreio distribuído OpenTelemetry, ferramentas de código aberto Rastreamento Dapr incorporado Informações sobre aplicativos Informações sobre aplicativos
Serviços com estado Volumes persistentes, StatefulSets Montagens de volume, estado Dapr Funções Duráveis Montagem Azure Files
Identidade específica para serviço Identidade da carga de trabalho Identidade gerenciada Identidade gerenciada Identidade gerenciada
Acesso à API do Kubernetes Yes No No No
Implantabilidade independente Sim (por pod ou por implantação) Sim (aplicação por contentor individual) Sim (aplicação por função) Sim (por aplicação ou por slot de implantação)
Executa contentores Yes Yes Yes Yes
Executa código sem contentores No No Yes Yes

Nível de aplicação nesta tabela significa que a plataforma não fornece esta capacidade como uma funcionalidade incorporada. Implementa-se no código da aplicação através de um SDK ou de um serviço externo, o que introduz uma dependência desse serviço.

Note

Esta tabela não inclui o Azure Red Hat OpenShift. Fornece a API completa do Kubernetes, pelo que as suas capacidades principais de microserviços, como escalonamento por implementação, descoberta de serviços e atualizações contínuas, são comparáveis ao AKS.

As plataformas diferem nas suas ferramentas operacionais, não nas suas capacidades centrais de microserviços. Por exemplo, o AKS fornece Dapr e KEDA como complementos geridos, mas no OpenShift, instala-os e mantém-nos tu próprio. Para mais informações, consulte a documentação Azure Red Hat OpenShift.

Escolher a plataforma

  • Comece com Aplicações Container quando quiser primitivas de microserviços integradas, como descoberta de serviços, DAPR e escalabilidade por aplicação que inclui escalar até zero, sem gestão de clusters.

  • Escolha AKS quando precisar de acesso direto à API Kubernetes, configuração personalizada de malhas de serviços ou controlo detalhado sobre infraestruturas de cluster, como pools de nós, políticas de rede ou restrições de agendamento.

  • Use Funções para microserviços orientados por eventos que tenham padrões de tráfego esporádicos ou de picos súbitos que beneficiam de faturação escalável para zero e execução baseada em gatilhos.

  • Use App Service para serviços simples baseados em HTTP que não necessitam de descoberta de serviços a nível de plataforma ou comunicação entre serviços.

A carga de trabalho dos seus microserviços não precisa de correr numa única plataforma. Por exemplo, pode executar serviços principais em AKS ou Aplicações Container enquanto o Functions gere cargas de trabalho orientadas a eventos. Compare cada serviço na sua composição em função do seu próprio padrão de tráfego, necessidades de escalabilidade e necessidades de comunicação. Escolha a plataforma que se encaixa nesse serviço em vez de forçar o serviço a encaixar na plataforma.

Principais fatores de decisão

A tabela comparativa mostra o que cada plataforma suporta. As secções seguintes ajudam-no a ponderar essas capacidades com base nas preocupações dos microserviços que mais importam para a sua carga de trabalho.

Comunicação entre serviços

Os microserviços dependem de uma comunicação fiável entre serviços, com capacidades como descoberta de serviços, reintentos e mTLS.

Se a sua arquitetura depende de chamadas de serviço a serviço síncronas em vários serviços, priorize uma plataforma que tenha primitivas de comunicação incorporadas. O Container Apps fornece estas primitivas através do Dapr sem infraestrutura adicional. O AKS fornece-os através de malhas de serviço como o Istio, que te dão controlo sobre políticas de tráfego, tentativas e quebras de circuito ao nível da malha. Geres o ciclo de vida da malha, a configuração e as atualizações.

Se os seus serviços comunicam principalmente através de mensagens assíncronas como filas ou fluxos de eventos, as funcionalidades de comunicação incorporadas da plataforma importam menos porque precisa de interagir com esses serviços através de um SDK ou de uma abstração. Utilize o padrão de Pedido-Resposta assíncrono para operações de longa duração, uma vez que os limites de tempo da plataforma podem tornar-se problemáticos. Por exemplo, o Functions e o App Service impõem um tempo de resposta HTTP de 230 segundos devido aos limites do Azure Load Balancer.

Dimensionamento independente

Cada microserviço numa composição tem características de carga diferentes.

Se os seus serviços tiverem tráfego altamente variável ou com picos súbitos, as Aplicações de Contentores e Funções escalam individualmente por serviço e podem reduzir serviços inativos a zero. Esta abordagem evita cobranças de capacidade não utilizadas. Para Funções, cada aplicação de funções é a unidade de escalabilidade, por isso implementa cada microserviço como uma aplicação de funções própria. O AKS fornece escalabilidade por implantação. Gere conjuntos de nós partilhados que permanecem provisionados e os conjuntos de nós de utilizador podem escalar para zero.

Plataformas escaláveis para zero introduzem latência de arranque frio quando um serviço inativo recebe o seu primeiro pedido. Numa arquitetura de microserviços, um único pedido de utilizador pode atravessar múltiplos serviços. Se vários serviços na cadeia de chamadas estiverem frios, a latência aumenta. Para chamadas interserviços síncronas que requerem baixa latência, utilize as funcionalidades de mitigação de arranques a frio da plataforma ou pague o custo para manter as instâncias mínimas ativas para evitar arranques a frio.

Se os seus serviços tiverem uma carga constante e previsível, o AKS ou o App Service podem reduzir custos porque paga por capacidade reservada em vez de faturação baseada no consumo.

Implantabilidade independente

É necessário implementar, atualizar e reverter microserviços individuais sem afetar o resto do sistema. As quatro plataformas suportam implantabilidade independente, mas diferem na forma como validas as alterações. Aplicações de Contentores e AKS fornecem a divisão de tráfego de forma nativa para implementações graduais. O App Service suporta o encaminhamento de tráfego baseado em percentagem entre os slots de implementação. O Functions suporta slots de implantação em planos Premium e Dedicados.

Observabilidade distribuída

Um único pedido de utilizador pode atravessar muitos serviços. Se precisar de rastreios correlacionados ao longo de toda a cadeia de chamadas, verifique se as ferramentas de observabilidade da sua plataforma se integram com a sua estratégia de rastreamento. O Container Apps fornece observabilidade integrada com rastreamento Dapr. O AKS integra-se com o OpenTelemetry e ferramentas de rastreamento open-source, que permitem escolher o seu back-end de rastreamento (como Jaeger, Zipkin ou Azure Monitor), mas exige que implemente e configure o pipeline de recolha. Functions e App Service integram-se com o Application Insights para rastreamento de transações de ponta a ponta com configuração mínima.

Certifique-se de que cada serviço na composição expõe métricas por serviço como taxa de pedido, taxa de erro e latência. Estas métricas ajudam-no a identificar qual o serviço que se degrada sem correlacionar os registos ao longo de toda a cadeia de chamadas.

Gestão do Estado

Numa arquitetura de microserviços, cada serviço normalmente detém os seus dados e externaliza o estado para uma base de dados ou cache dedicada. Este padrão mantém os serviços independentemente implantáveis, e as quatro plataformas suportam-no igualmente porque o armazenamento de dados é um recurso Azure separado.

As plataformas diferem quando um serviço necessita de abstrações de estado geridas pela plataforma, como padrões baseados em atores, orquestração de fluxos de trabalho ou armazenamento dedicado por instância:

  • O AKS oferece a maior flexibilidade através de volumes persistentes e StatefulSets, que suportam armazenamentos de dados dentro do cluster e identidade estável por instância.

  • As Aplicações de Contentores suportam montagens de volume e gestão de estado do Dapr, incluindo atores do Dapr.

  • O Functions suporta orquestrações e entidades com estado através de Funções Duradouras.

  • O App Service suporta armazenamento partilhado através de montagens Azure Files, mas não fornece armazenamento por instância nem abstrações de estado ao nível da plataforma.

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 Well-Architected Framework.

Fiabilidade

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

Numa arquitetura de microserviços, o principal risco de fiabilidade é a falha em cascata. Um serviço pouco saudável faz com que os chamadores acumulem timeouts, e o problema propaga-se pela cadeia de chamadas. A escolha da sua plataforma afeta a forma como mitiga este risco.

  • As aplicações AKS e Container fornecem sondas de saúde ao nível da plataforma que detetam instâncias não saudáveis e removem-nas automaticamente da rotação.

  • Funções tentam novamente execuções falhadas com base no tipo de gatilho.

Independentemente da plataforma, implemente disjuntores, políticas de retentativa com recuo e tempos de espera na sua comunicação entre serviços para evitar que uma única falha de serviço se torne numa falha em todo o sistema.

Implemente cada serviço entre zonas de disponibilidade para proteger contra falhas ao nível do centro de dados. Numa composição de plataforma mista, verifique se todas as plataformas em uso suportam redundância de zona na sua região de implantação.

Para orientações específicas de fiabilidade por plataforma, consulte as secções de fiabilidade dos guias de serviço do Well-Architected Framework para AKS, Aplicações de Container e Funções.

Segurança

A segurança fornece garantias contra ataques deliberados e o uso indevido de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.

Os microserviços aumentam a superfície de ataque porque cada chamada de serviço para serviço cruza uma fronteira de rede. Trate todo o tráfego interserviços como não confiável e encripte-o através de mTLS. O AKS suporta mTLS através de malhas de serviço como o Istio. O Container Apps fornece mTLS através de Dapr ou configuração ao nível do ambiente. Azure Functions e App Service não fornecem mTLS ao nível da plataforma. Se essas plataformas alojarem serviços na sua composição, garanta a segurança do transporte através de HTTPS na camada de aplicação, políticas de gateway API, ou isolamento de rede virtual.

Numa composição de vários serviços, cada serviço deve autenticar-se apenas aos recursos que necessita. Atribuir identidades por serviço em vez de partilhar uma única identidade ao longo da carga de trabalho. Para mecanismos específicos de plataforma, consulte a linha de identidade por serviço na tabela de comparação.

Para orientações de segurança específicas da plataforma, consulte as secções de segurança dos guias de serviço do Well-Architected Framework para AKS,Aplicações de Contentores e Funções.

Otimização de Custos

A Otimização de Custos concentra-se em formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design para otimização de custos.

Uma arquitetura de microserviços pode incluir dezenas de serviços, e cada serviço gere diferentes volumes de tráfego. Adapte cada serviço ao modelo de faturação que se adapte ao seu padrão de tráfego. Plataformas baseadas no consumo como Aplicações e Funções de Contentores escalam os serviços inativos a zero, mas computação dedicada como o AKS pode ser mais rentável para serviços com carga sustentada. Numa composição de plataforma mista, a flexibilidade de faturação por serviço é uma das principais vantagens de custo. No entanto, tenha em conta a sobrecarga de manter pipelines de implementação separados, monitorizar configurações e a experiência da equipa em várias plataformas.

Para orientações sobre custos específicas da plataforma, consulte as secções de otimização de custos dos guias de serviço do Well-Architected Framework para AKS, Container Apps e Funções.

Arquiteturas de referência

Reduza as suas opções a uma ou duas plataformas aplicando os critérios de comparação apresentados neste artigo. Execute uma prova de conceito implementando um subconjunto representativo dos seus serviços e testando a comunicação interserviços, o comportamento de escalabilidade e os fluxos de trabalho de implementação com base nos seus requisitos. Confirme que a plataforma cumpre as expectativas operacionais da sua equipa antes de se comprometer com a produção. As seguintes arquiteturas fornecem pontos de partida prontos para produção:

Próximo passo

Projetar comunicação entre serviços para microsserviços

  • Last updated on