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

  • Artigo

O termo computação refere-se ao modelo de alojamento dos recursos de computação em que a aplicação é executada. Para uma arquitetura de microsserviços, duas abordagens são especialmente populares:

  • Um orquestrador de serviços que gere serviços em execução em nós dedicados (VMs).
  • Uma arquitetura sem servidor com funções como um serviço (FaaS).

Embora estas não sejam as únicas opções, ambas são abordagens comprovadas para a criação de microsserviços. Uma aplicação pode incluir ambas as abordagens.

Orquestradores de serviços

Um orquestrador processa tarefas relacionadas com a implementação e gestão de um conjunto de serviços. Estas tarefas incluem a colocação de serviços em nós, a monitorização do estado de funcionamento dos serviços, o reinício de serviços em mau estado de funcionamento, o balanceamento de carga do tráfego de rede entre instâncias de serviço, a deteção de serviços, o dimensionamento do número de instâncias de um serviço e a aplicação de atualizações de configuração. Os orquestradores populares incluem Kubernetes, Service Fabric, DC/OS e Docker Swarm.

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

  • O Azure Kubernetes Service (AKS) é um serviço Kubernetes gerido. O AKS aprovisiona o Kubernetes e expõe os pontos finais da API do Kubernetes, mas aloja e gere o plano de controlo do Kubernetes, realiza atualizações automatizadas, aplicação de patches automatizada, dimensionamento automático e outras tarefas de gestão. Pode considerar o AKS como "APIs do Kubernetes como um serviço".

  • O Azure Container Apps é um serviço gerido criado no Kubernetes que abstrai as complexidades da orquestração de contentores e de outras tarefas de gestão. O Container Apps simplifica a implementação e gestão de aplicações e microsserviços em contentores num ambiente sem servidor, ao mesmo tempo que fornece as funcionalidades do Kubernetes.

  • O Service Fabric é uma plataforma de sistemas distribuídos para empacotar, implementar e gerir microsserviços. Os microsserviços podem ser implementados no Service Fabric como contentores, como executáveis binários ou como Reliable Services. Com o modelo de programação reliable Services, os serviços podem utilizar diretamente AS APIs de programação do Service Fabric para consultar o sistema, comunicar o estado de funcionamento, receber notificações sobre alterações de configuração e código e descobrir outros serviços. Uma diferenciação fundamental com o Service Fabric é o seu forte foco na criação de serviços com estado através de Reliable Collections.

  • Outras opções, como o Docker Enterprise Edition, podem ser executadas num ambiente IaaS no Azure. Pode encontrar modelos de implementação no Azure Marketplace.

Contentores

Por vezes, as pessoas falam de contentores e microsserviços como se fossem a mesma coisa. Embora isso não seja verdade , não precisa de contentores para criar microsserviços, os contentores têm algumas vantagens que são particularmente relevantes para os microsserviços, tais como:

  • Portabilidade. Uma imagem de contentor é um pacote autónomo que é executado sem ter de instalar bibliotecas ou outras dependências. Isto torna-os mais fáceis de implementar. Os contentores podem ser iniciados e parados rapidamente, para que possa criar novas instâncias para lidar com mais carga ou recuperar de falhas de nós.

  • Densidade. Os contentores são leves em comparação com a execução de uma máquina virtual, porque partilham recursos do SO. Isto permite colocar vários contentores num único nó, o que é especialmente útil quando a aplicação consiste em muitos serviços pequenos.

  • Isolamento de recursos. Pode limitar a quantidade de memória e CPU que está disponível para um contentor, o que pode ajudar a garantir que um processo em fuga não esgota os recursos do anfitrião. Veja o padrão bulkhead para obter mais informações.

Sem servidor (Funções como um Serviço)

Com uma arquitetura sem servidor , não gere as VMs ou a infraestrutura de rede virtual. Em vez disso, implementa código e o serviço de alojamento processa colocar esse código numa VM e executá-lo. Esta abordagem tende a favorecer pequenas funções granulares coordenadas com acionadores baseados em eventos. Por exemplo, uma mensagem que está a ser colocada numa fila pode acionar uma função que lê a partir da fila e processa a mensagem.

Funções do Azure é um serviço de computação sem servidor que suporta vários acionadores de funções, incluindo pedidos HTTP, filas do Service Bus e eventos dos Hubs de Eventos. Para obter uma lista completa, veja Funções do Azure conceitos de acionadores e enlaces. Considere também Azure Event Grid, que é um serviço de encaminhamento de eventos gerido no Azure.

Orquestrador ou sem servidor?

Seguem-se alguns fatores a considerar ao escolher entre uma abordagem do orquestrador e uma abordagem sem servidor.

Capacidade de gestão Uma aplicação sem servidor é fácil de gerir, porque a plataforma gere todos os recursos de computação por si. Embora um orquestrador abstraia alguns aspetos da gestão e configuração de um cluster, não oculta completamente as VMs subjacentes. Com um orquestrador, terá de pensar em problemas como o balanceamento de carga, a utilização da CPU e da memória e a rede.

Flexibilidade e controlo. Um orquestrador dá-lhe um grande controlo sobre como configurar e gerir os seus serviços e o cluster. A troca é uma complexidade adicional. Com uma arquitetura sem servidor, desiste de algum grau de controlo porque estes detalhes são abstratos.

Portabilidade. Todos os orquestradores listados aqui (Kubernetes, DC/OS, Docker Swarm e Service Fabric) podem ser executados no local ou em várias clouds públicas.

Integração de aplicações. Pode ser difícil criar uma aplicação complexa com uma arquitetura sem servidor, devido à necessidade de coordenar, implementar e gerir muitas pequenas funções independentes. Uma opção no Azure é utilizar o Azure Logic Apps para coordenar um conjunto de Funções do Azure. Para obter um exemplo desta abordagem, veja Criar uma função que se integra no Azure Logic Apps.

Custo. Com um orquestrador, paga as VMs que estão em execução no cluster. Com uma aplicação sem servidor, paga apenas pelos recursos de computação reais consumidos. Em ambos os casos, tem de considerar o custo de quaisquer serviços adicionais, como armazenamento, bases de dados e serviços de mensagens.

Escalabilidade. Funções do Azure dimensiona automaticamente para satisfazer a procura, com base no número de eventos recebidos. Com um orquestrador, pode aumentar horizontalmente ao aumentar o número de instâncias de serviço em execução no cluster. Também pode dimensionar ao adicionar VMs adicionais ao cluster.

A nossa implementação de referência utiliza principalmente o Kubernetes, mas utilizámos Funções do Azure para um serviço, nomeadamente o serviço Histórico de Entregas. Funções do Azure foi uma boa opção para este serviço específico, porque é uma carga de trabalho condicionada por eventos. Ao utilizar um acionador dos Hubs de Eventos para invocar a função, o serviço precisava de uma quantidade mínima de código. Além disso, o serviço Histórico de Entregas não faz parte do fluxo de trabalho principal, pelo que executá-lo fora do cluster do Kubernetes não afeta a latência ponto a ponto das operações iniciadas pelo utilizador.

Passos seguintes

Comunicação entre serviços