Partilhar via

Melhores práticas de conceção de aplicações do Azure Service Fabric

  • Artigo

Este artigo fornece orientações de práticas recomendadas para a criação de aplicativos e serviços no Azure Service Fabric.

Familiarize-se com o Service Fabric

  • Leia o artigo Então você quer saber mais sobre o Service Fabric?
  • Leia sobre cenários de aplicativos do Service Fabric.
  • Entenda as opções de modelo de programação lendo Visão geral do modelo de programação do Service Fabric.

Diretrizes de design de aplicativos

Familiarize-se com a arquitetura geral dos aplicativos do Service Fabric e suas considerações de design.

Escolha um gateway de API

Use um serviço de gateway de API que se comunique com serviços back-end que podem ser expandidos. Os serviços de gateway de API mais comuns usados são:

Serviços apátridas

Recomendamos que você sempre comece criando serviços sem monitoração de estado usando Serviços Confiáveis e armazenando o estado em um banco de dados do Azure, Azure Cosmos DB ou Armazenamento do Azure. O estado externalizado é a abordagem mais familiar para a maioria dos desenvolvedores. Essa abordagem também permite que você aproveite os recursos de consulta na loja.

Quando usar serviços com monitoração de estado

Considere serviços com monitoração de estado quando tiver um cenário de baixa latência e precisar manter os dados próximos à computação. Alguns cenários de exemplo incluem dispositivos gêmeos digitais IoT, estado do jogo, estado da sessão, armazenamento em cache de dados de um banco de dados e fluxos de trabalho de longa execução para rastrear chamadas para outros serviços.

Decida sobre o período de retenção de dados:

  • Dados armazenados em cache. Use o cache quando a latência para armazenamentos externos for um problema. Use um serviço com monitoração de estado como seu próprio cache de dados ou considere usar o SoCreate Service Fabric Distributed Cache de código aberto. Nesse cenário, você não precisa se preocupar se perder todos os dados no cache.
  • Dados com limite de tempo. Nesse cenário, você precisa manter os dados próximos à computação por um período de tempo para latência, mas pode se dar ao luxo de perder os dados em um desastre. Por exemplo, em muitas soluções de IoT, os dados precisam estar próximos da computação, como quando a temperatura média dos últimos dias está sendo calculada, mas se esses dados forem perdidos, os pontos de dados específicos registrados não são tão importantes. Além disso, nesse cenário, você normalmente não se preocupa com o backup dos pontos de dados individuais. Você só faz backup de valores médios computados que são gravados periodicamente no armazenamento externo.
  • Dados a longo prazo. Coleções confiáveis podem armazenar seus dados permanentemente. Mas, nesse caso, você precisa se preparar para a recuperação de desastres, incluindo a configuração de políticas de backup periódicas para seus clusters. Na verdade, você configura o que acontece se o cluster for destruído em um desastre, onde precisaria criar um novo cluster e como implantar novas instâncias de aplicativos e se recuperar do backup mais recente.

Poupe custos e melhore a disponibilidade:

  • Você pode reduzir custos usando serviços com monitoração de estado porque não incorre em custos de acesso a dados e transações do repositório remoto e porque não precisa usar outro serviço, como o Cache do Azure para Redis.
  • Usar serviços com monitoração de estado principalmente para armazenamento e não para computação é caro, e não recomendamos isso. Pense em serviços stateful como computação com armazenamento local barato.
  • Ao remover dependências de outros serviços, você pode melhorar a disponibilidade do serviço. O gerenciamento do estado com HA no cluster isola você de outros tempos de inatividade de serviço ou problemas de latência.

Como trabalhar com serviços confiáveis

O Service Fabric Reliable Services permite que você crie facilmente serviços sem monitoração de estado e com monitoração de estado. Para obter mais informações, consulte a introdução aos Serviços confiáveis.

  • Sempre honre o token de cancelamento no RunAsync() método para serviços com monitoração de estado e com monitoração de estado e no ChangeRole() método para serviços com monitoração de estado. Caso contrário, o Service Fabric não sabe se o serviço pode ser fechado. Por exemplo, se você não honrar o token de cancelamento, podem ocorrer tempos de atualização de aplicativos muito maiores.
  • Abra e feche os ouvintes de comunicação em tempo hábil e honre os tokens de cancelamento.
  • Nunca misture código de sincronização com código assíncrono. Por exemplo, não use .GetAwaiter().GetResult() em suas chamadas assíncronas. Use assíncrono durante toda a pilha de chamadas.

Como trabalhar com atores confiáveis

O Service Fabric Reliable Actors permite que você crie facilmente atores virtuais com monitoração de estado. Para obter mais informações, consulte a introdução a Reliable Actors.

  • Considere seriamente o uso de mensagens pub/sub entre seus atores para dimensionar seu aplicativo. As ferramentas que fornecem esse serviço incluem o SoCreate Service Fabric Pub/Sub de código aberto e o Barramento de Serviço do Azure.
  • Torne o estado do ator o mais granular possível.
  • Gerir o ciclo de vida do ator. Exclua atores se não for usá-los novamente. A exclusão de atores desnecessários é especialmente importante quando você está usando o provedor de estado volátil, porque todo o estado é armazenado na memória.
  • Devido à sua simultaneidade baseada em turnos, os atores são melhor usados como objetos independentes. Não crie gráficos de chamadas de método síncronas com vários atores (cada uma das quais provavelmente se torna uma chamada de rede separada) ou crie solicitações de atores circulares. Isso afetará significativamente o desempenho e a escala.
  • Não misture código de sincronização com código assíncrono. Use assíncrono consistentemente para evitar problemas de desempenho.
  • Não faça chamadas de longa duração em atores. Chamadas de longa duração bloquearão outras chamadas para o mesmo ator, devido à simultaneidade baseada em turnos.
  • Se você estiver se comunicando com outros serviços usando a comunicação remota do Service Fabric e estiver criando um ServiceProxyFactory, crie a fábrica no nível de serviço do ator e não no nível do ator.

Diagnóstico de aplicativos

Seja minucioso ao adicionar o log de aplicativos em chamadas de serviço. Ele irá ajudá-lo a diagnosticar cenários em que os serviços chamam uns aos outros. Por exemplo, quando A chama B chama C chama D, a chamada pode falhar em qualquer lugar. Se você não tiver registro suficiente, as falhas são difíceis de diagnosticar. Se os serviços estiverem registrando muito devido a volumes de chamadas, certifique-se de pelo menos registrar erros e avisos.

Diretrizes de design no Azure