Melhores práticas de design de aplicativos do Azure Service Fabric

  • Artigo

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

Familiarize-se com o 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 comunica com os serviços de back-end que podem ser escalados horizontalmente. Os serviços de gateway de API mais comuns usados são:

Serviços sem estado

Recomendamos que você sempre comece criando serviços sem estado usando o Reliable Services e armazenando o estado em um banco de dados do Azure, no Azure Cosmos DB ou no Armazenamento do Azure. O estado exteriorizado é a abordagem mais familiar para a maioria dos desenvolvedores. Essa abordagem também permite que você aproveite os recursos de consulta no repositório.

Quando usar serviços com estado

Considere os serviços com estado quando você 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êmeo digital do IoT, estado de jogo, estado de sessão, cache de dados de um banco de dados e fluxos de trabalho de longa duraçã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 estado como seu cache de dados ou considere o uso do Cache Distribuído do SoCreate Service Fabric que é open-source. Nesse cenário, você não precisa se preocupar se perder todos os dados no cache.
  • Dados associados ao tempo. Nesse cenário, você precisa manter os dados próximos para serem computados por um período de latência, mas pode 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 nos ú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, normalmente, você não se preocupa em fazer backup dos pontos de dados individuais. Você faz backup somente dos valores médios computados que são gravados periodicamente no armazenamento externo.
  • Dados de longo prazo. As coletas confiáveis podem armazenar seus dados permanentemente. Mas, nesse caso, você precisa se preparar para a recuperação de desastre, incluindo a configuração de políticas de backup periódicos para seus clusters. Na verdade, você configura o que acontece se o cluster for destruído em um desastre, onde você precisaria criar um novo cluster e como implantar novas instâncias de aplicativo e recuperar-se a partir do backup mais recente.

Economize e melhore a disponibilidade:

  • Você pode reduzir os custos usando serviços com estado porque não incorre em custos de transações e acesso a dados do repositório remoto e porque não precisa usar outro serviço, como o Cache do Azure para Redis.
  • Não recomendamos usar serviços com estado para armazenamento em vez de computação, pois fica muito caro. Pense nos serviços com estado 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 de estado com HA no cluster isola você de outros problemas de latência e tempo de inatividade do serviço.

Como trabalhar com o Reliable Services

O Reliable Services do Service Fabric permite que você crie facilmente serviços com e sem estado. Para saber mais, confira Introdução ao Reliable Services.

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

Como trabalhar com o Reliable Actors

O Reliable Actors do Service Fabric permite que você crie facilmente atores com estado e virtual. Para saber mais, confira Introdução ao Reliable Actors.

  • Considere seriamente o uso de mensagens de publicação/assinatura entre seus atores para dimensionar seu aplicativo. As ferramentas que fornecem esse serviço incluem a publicação/assinatura do SoCreate Service Fabric que é open-source e o Barramento de Serviço do Azure.
  • Faça o estado do ator tão granular quanto possível.
  • Gerencie o ciclo de vida do ator. Exclua os atores se você não for usá-los novamente. Excluir atores desnecessários é especialmente importante quando você está usando o provedor de estado volátil, pois todo o estado é armazenado na memória.
  • Devido à sua simultaneidade baseada em turnos, os atores são usados melhor como objetos independentes. Não crie grafos de chamadas de método síncronas de vários atores (cada uma provavelmente se tornará uma chamada de rede separada) ou crie solicitações de ator circular. Isso afetará significativamente o desempenho e a escala.
  • Nunca misture o código síncrono com o código assíncrono. Use o assíncrono de forma consistente para evitar problemas de desempenho.
  • Não faça chamadas de longa execução nos atores. Chamadas de longa execuçã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 de ator e não no nível de ator.

Diagnóstico de aplicativo

Seja minucioso na adição de log de aplicativo em chamadas de serviço. Ele o ajudará a diagnosticar cenários nos quais os serviços se ligam. Por exemplo, quando A chama B chama C chama D, a chamada pode falhar em qualquer lugar. Se você não tiver registro em log suficiente, será difícil diagnosticar as falhas. Se os serviços estiverem registrando muito em log devido aos volumes de chamada, registre pelo menos os avisos e erros de log.

Diretrizes de design no Azure