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

  • Artigo

O termo computação refere-se ao modelo de hospedagem para os recursos de computação em que seu aplicativo é executado. Para uma arquitetura de microsserviços, duas abordagens são especialmente populares:

  • Um orquestrador de serviços que gerencia serviços em execução em nós dedicado (VMs).
  • Uma arquitetura sem servidor que funciona como um serviço (FaaS).

Embora essas não sejam as únicas opções, são abordagens comprovadas para criação de microsserviços. Um aplicativo pode incluir ambas as abordagens.

Orquestradores de serviço

Um orquestrador manipula tarefas relacionadas à implantação e ao gerenciamento de um conjunto de serviços. Essas tarefas incluem a colocação de serviços em nós, monitoramento da integridade dos serviços, reinicialização de serviços não íntegros, balanceamento de carga de tráfego de rede em instâncias de serviço, descoberta de serviço, dimensionamento do número de instâncias de um serviço e aplicação das atualizações de configuração. Entre os orquestradores populares estão Kubernetes, DC/OS, Docker Swarm e Service Fabric.

Na plataforma do Azure, considere as seguintes opções:

  • O AKS (Serviço de Kubernetes do Azure) é um serviço Kubernetes gerenciado. O AKS provisiona Kubernetes e expõe os pontos de extremidade da API Kubernetes, mas hospeda e gerencia o plano de controle Kubernetes, realizando atualizações automatizadas, patches automatizados, dimensionamento automático e outras tarefas de gerenciamento. Pense em AKS como "API Kubernetes como um serviço".

  • Os Aplicativos de Contêiner do Azure são um serviço gerenciado criado no Kubernetes que abstrai as complexidades da orquestração de contêiner e de outras tarefas de gerenciamento. Os Aplicativos de Contêiner simplificam a implantação e o gerenciamento de aplicativos e microsserviços em contêineres em um ambiente sem servidor, ao mesmo tempo em que fornece os recursos do Kubernetes.

  • Service Fabric é uma plataforma de sistemas distribuídos para empacotamento, implantação e gerenciamento de microsserviços. Os microsserviços podem ser implantados no Service Fabric como contêineres, executáveis binários ou Reliable Services. Usando o modelo de programação de Reliable Services, os serviços podem usar diretamente as APIs de programação do Service Fabric para consultar o sistema, informar sobre integridade, receber notificações sobre alterações na configuração e no código e descobrir outros serviços. Uma diferencial importante do Service Fabric é o seu forte foco na criação de serviços com estado, usando Coleções Confiáveis.

  • Outras opções, como o Docker Enterprise Edition, podem ser executadas em um ambiente IaaS no Azure. Você pode encontrar os modelos de implantação no Microsoft Azure Marketplace.

Contêineres

Às vezes, as pessoas falam sobre contêineres e microsserviços como se fossem a mesma coisa. Embora isso não seja verdade, você não precisa de contêineres para criar microsserviços: os contêineres têm alguns benefícios particularmente relevantes para microsserviços, como:

  • Portabilidade. Uma imagem de contêiner é um pacote autônomo, que é executado sem a necessidade de instalar bibliotecas ou outras dependências. Isso facilita a implantação. Contêineres podem ser iniciados e interrompidos rapidamente, portanto, você pode criar novas instâncias para lidar com mais carga ou para se recuperar de falhas de nó.

  • Densidade. Contêineres são leves em comparação com a execução de uma máquina virtual, porque eles compartilham os recursos do sistema operacional. Isso possibilita empacotar vários contêineres em um único nó, o que é especialmente útil quando o aplicativo é composto por muitos pequenos serviços.

  • Isolamento de recurso. Você pode limitar a quantidade de memória e a CPU disponível para um contêiner, o que ajuda a garantir que um processo sem controle não esgote os recursos do host. Confira o padrão de Bulkhead para obter mais informações.

Sem Servidor (Funções como um serviço)

Com uma arquitetura sem servidor, não é possível administrar VMs nem a infraestrutura de rede virtual. Em vez disso, você implanta o código, e o serviço de hospedagem coloca esse código em uma VM e o executa. Essa abordagem tende a favorecer pequenas funções granulares que sejam coordenadas usando gatilhos baseados em eventos. Por exemplo, uma mensagem colocada em uma fila pode disparar uma função que lê da fila e processa a mensagem.

Azure Functions é um serviço de computação sem servidor, compatível com vários gatilhos de função, incluindo solicitações de HTTP, filas de barramento de serviço e eventos de Hubs de Eventos. Para obter uma lista completa, consulte Gatilhos e conceitos de ligação do Azure Functions. Além disso, considere a Grade de Eventos do Azure, que é um serviço de roteamento de eventos gerenciados no Azure.

Orchestrator ou sem servidor?

Aqui estão alguns fatores a considerar ao escolher entre uma abordagem de orquestrador e uma abordagem sem servidor.

Capacidade de gerenciamento um aplicativo sem servidor é fácil de gerenciar, porque a plataforma gerencia todos os de recursos de computação por você. Um orquestrador abstrai alguns aspectos de gerenciamento e configuração de um cluster, mas ele não oculta completamente as VMs subjacentes. Com um orquestrador, você terá de pensar sobre problemas como, balanceamento de carga, uso de CPU e de memória e rede.

Flexibilidade e controle. Um orquestrador fornece muito controle sobre como configurar e gerenciar seus serviços e o cluster. A desvantagem é a complexidade adicional. Com uma arquitetura sem servidor, você perde um pouco do controle porque esses detalhes são abstraídos.

Portabilidade. Todos os orquestradores listados aqui (Kubernetes, DC/OS, Docker Swarm e Service Fabric) podem ser executados localmente ou em várias nuvens publicas.

Integração de aplicativos. Pode ser um desafio criar um aplicativo complexo usando uma arquitetura sem servidor devido à necessidade de coordenar, implantar e gerenciar muitas pequenas funções independentes. Uma opção no Azure é usar Aplicativos Lógicos do Azure para coordenar um conjunto do Azure Functions. Para um exemplo dessa abordagem, consulte Criar uma função que se integre aos Aplicativos Lógicos do Azure.

Custo. Com um orquestrador, você paga pelas VMs em execução no cluster. Com um aplicativo sem servidor, você paga apenas pelos recursos de computação real consumidos. Em ambos os casos, você precisa considerar o custo dos serviços adicionais, como armazenamento, bancos de dados e serviços de mensagens.

Escalabilidade. O Azure Functions é dimensionado automaticamente para atender à demanda, com base no número de eventos recebidos. Com um orquestrador, você pode escalar horizontalmente, aumentando o número de instâncias de serviço em execução no cluster. Você também pode dimensionar adicionando VMs ao cluster.

Nossa implementação da referência usa principalmente Kubernetes, mas nós usamos o Azure Functions para um serviço, ou seja, o serviço de histórico de entrega. O Azure Functions foi uma boa opção para esse serviço em particular, pois é uma carga de trabalho baseada em eventos. Usando um gatilho de Hubs de Eventos para chamar a função, o serviço precisou de uma quantidade mínima de código. Além disso, o serviço de Histórico de Entrega não faz parte do fluxo de trabalho principal, portanto, executá-lo fora do cluster Kubernetes não afeta a latência ponta a ponta de operações iniciadas pelo usuário.

Próximas etapas

Comunicação entre serviços