Guia para converter Funções Web e de Trabalho em serviços sem estado do Service Fabric

Este artigo descreve como migrar o seu Serviços Cloud Funções Web e de Trabalho para serviços sem estado do Service Fabric. Este é o caminho de migração mais simples de Serviços Cloud para o Service Fabric para aplicações cuja arquitetura geral vai permanecer aproximadamente igual.

Projeto do Serviço Cloud para o projeto de aplicação do Service Fabric

Um projeto do Serviço Cloud e um projeto de Aplicação do Service Fabric têm uma estrutura semelhante e ambos representam a unidade de implementação da sua aplicação, ou seja, cada um deles define o pacote completo implementado para executar a sua aplicação. Um projeto do Serviço Cloud contém uma ou mais Funções Web ou de Trabalho. Da mesma forma, um projeto de Aplicação do Service Fabric contém um ou mais serviços.

A diferença é que o projeto do Serviço Cloud associa a implementação da aplicação a uma implementação de VM e, portanto, contém as definições de configuração da VM no mesmo, enquanto o projeto da Aplicação do Service Fabric define apenas uma aplicação que será implementada num conjunto de VMs existentes num cluster do Service Fabric. O cluster do Service Fabric só é implementado uma vez, seja através de um modelo de Resource Manager ou através do portal do Azure, e podem ser implementadas várias aplicações do Service Fabric no mesmo.

Comparação de projetos do Service Fabric e Serviços Cloud

Função de Trabalho para serviço sem estado

Conceptualmente, uma Função de Trabalho representa uma carga de trabalho sem estado, o que significa que cada instância da carga de trabalho é idêntica e os pedidos podem ser encaminhados para qualquer instância em qualquer altura. Não é esperado que cada instância memorize o pedido anterior. O estado em que a carga de trabalho funciona é gerida por um arquivo de estado externo, como o Armazenamento de Tabelas do Azure ou o Azure Cosmos DB. No Service Fabric, este tipo de carga de trabalho é representado por um Serviço Sem Estado. A abordagem mais simples para migrar uma Função de Trabalho para o Service Fabric pode ser feita ao converter o Código da Função de Trabalho num Serviço Sem Estado.

Função de Trabalho para Serviço Sem Estado

Função Web para serviço sem estado

Semelhante à Função de Trabalho, uma Função Web também representa uma carga de trabalho sem estado e, por isso, conceptualmente também pode ser mapeada para um serviço sem estado do Service Fabric. No entanto, ao contrário das Funções Web, o Service Fabric não suporta o IIS. Para migrar uma aplicação Web de uma Função Web para um serviço sem estado, é necessário mover primeiro para uma arquitetura Web que possa ser autoalojada e não dependa do IIS ou do System.Web, como ASP.NET Core 1.

Aplicação Suportado Caminho da migração
ASP.NET Web Forms No Converter em ASP.NET Core 1 MVC
ASP.NET MVC Com a Migração Atualizar para ASP.NET Core 1 MVC
API Web ASP.NET Com a Migração Utilizar o servidor autoalojado ou ASP.NET Core 1
ASP.NET Core 1 Yes N/D

API de ponto de entrada e ciclo de vida

As APIs de função de trabalho e serviço do Service Fabric oferecem pontos de entrada semelhantes:

Ponto de Entrada Função de Trabalho Serviço Service Fabric
Em processamento Run() RunAsync()
Início da VM OnStart() N/D
Paragem da VM OnStop() N/D
Abrir o serviço de escuta para pedidos de cliente N/D
  • CreateServiceInstanceListener() para sem estado
  • CreateServiceReplicaListener() para com estado

Função de Trabalho


using Microsoft.WindowsAzure.ServiceRuntime;

namespace WorkerRole1
{
    public class WorkerRole : RoleEntryPoint
    {
        public override void Run()
        {
        }

        public override bool OnStart()
        {
        }

        public override void OnStop()
        {
        }
    }
}

Serviço Sem Estado do Service Fabric


using System.Collections.Generic;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.ServiceFabric.Services.Communication.Runtime;
using Microsoft.ServiceFabric.Services.Runtime;

namespace Stateless1
{
    public class Stateless1 : StatelessService
    {
        protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
        {
        }

        protected override Task RunAsync(CancellationToken cancelServiceInstance)
        {
        }
    }
}

Ambos têm uma substituição principal de "Executar" para iniciar o processamento. Os serviços do Service Fabric combinam Run, Starte Stop num único ponto de entrada, RunAsync. O seu serviço deve começar a funcionar quando RunAsync iniciar e deve deixar de funcionar quando o RunAsync CancellationToken do método for sinalizado.

Existem várias diferenças fundamentais entre o ciclo de vida e a duração das Funções de Trabalho e dos serviços do Service Fabric:

  • Ciclo de vida: A maior diferença é que uma Função de Trabalho é uma VM e, por isso, o ciclo de vida está associado à VM, que inclui eventos para quando a VM é iniciada e para. Um serviço do Service Fabric tem um ciclo de vida separado do ciclo de vida da VM, pelo que não inclui eventos para quando a VM ou o computador anfitrião é iniciado e parado, uma vez que não estão relacionados.
  • Duração: Uma instância de Função de Trabalho será reciclada se o Run método sair. No RunAsync entanto, o método num serviço do Service Fabric pode ser executado até à conclusão e a instância de serviço permanecerá atualizada.

O Service Fabric fornece um ponto de entrada de configuração de comunicação opcional para serviços que escutam pedidos de cliente. Tanto o RunAsync como o ponto de entrada de comunicação são substituições opcionais nos serviços do Service Fabric - o seu serviço pode optar por apenas ouvir pedidos de cliente, ou apenas executar um ciclo de processamento, ou ambos - razão pela qual o método RunAsync tem permissão para sair sem reiniciar a instância de serviço, uma vez que pode continuar a escutar pedidos de cliente.

API de aplicação e ambiente

A API de ambiente de Serviços Cloud fornece informações e funcionalidades para a instância de VM atual, bem como informações sobre outras instâncias de função de VM. O Service Fabric fornece informações relacionadas com o seu runtime e algumas informações sobre o nó em que um serviço está atualmente em execução.

Tarefa de Ambiente Serviços em Nuvem Service Fabric
Definições de Configuração e notificação de alteração RoleEnvironment CodePackageActivationContext
Armazenamento Local RoleEnvironment CodePackageActivationContext
Informações do Ponto Final RoleInstance
  • Instância atual: RoleEnvironment.CurrentRoleInstance
  • Outras funções e instâncias: RoleEnvironment.Roles
  • NodeContext para o endereço de Nó atual
  • FabricClient e ServicePartitionResolver para deteção de pontos finais de serviço
Emulação do Ambiente RoleEnvironment.IsEmulated N/D
Evento de alteração simultânea RoleEnvironment N/D

Definições de configuração

As definições de configuração no Serviços Cloud são definidas para uma função de VM e aplicam-se a todas as instâncias dessa função de VM. Estas definições são pares chave-valor definidos em ficheiros ServiceConfiguration.*.cscfg e podem ser acedidos diretamente através de RoleEnvironment. No Service Fabric, as definições aplicam-se individualmente a cada serviço e a cada aplicação, em vez de a uma VM, porque uma VM pode alojar vários serviços e aplicações. Um serviço é composto por três pacotes:

  • Código: contém os executáveis de serviço, binários, DLLs e quaisquer outros ficheiros que um serviço precise de executar.
  • Configuração: todos os ficheiros de configuração e definições de um serviço.
  • Dados: ficheiros de dados estáticos associados ao serviço.

Cada um destes pacotes pode ser versado e atualizado de forma independente. Tal como Serviços Cloud, um pacote de configuração pode ser acedido programaticamente através de uma API e os eventos estão disponíveis para notificar o serviço de uma alteração de pacote de configuração. Um ficheiro Settings.xml pode ser utilizado para configuração chave-valor e acesso programático semelhante à secção de definições da aplicação de um ficheiro de App.config. No entanto, ao contrário Serviços Cloud, um pacote de configuração do Service Fabric pode conter quaisquer ficheiros de configuração em qualquer formato, seja XML, JSON, YAML ou um formato binário personalizado.

Aceder à configuração

Serviços Cloud

As definições de configuração de ServiceConfiguration.*.cscfg podem ser acedidas através de RoleEnvironment. Estas definições estão globalmente disponíveis para todas as instâncias de função na mesma implementação do Serviço Cloud.


string value = RoleEnvironment.GetConfigurationSettingValue("Key");

Service Fabric

Cada serviço tem o seu próprio pacote de configuração individual. Não existe nenhum mecanismo incorporado para definições de configuração global acessíveis por todas as aplicações num cluster. Ao utilizar o ficheiro de configuração Settings.xml especial do Service Fabric num pacote de configuração, os valores no Settings.xml podem ser substituídos ao nível da aplicação, o que possibilita definições de configuração ao nível da aplicação.

As definições de configuração são acessos em cada instância de serviço através do CodePackageActivationContext.


ConfigurationPackage configPackage = this.Context.CodePackageActivationContext.GetConfigurationPackageObject("Config");

// Access Settings.xml
KeyedCollection<string, ConfigurationProperty> parameters = configPackage.Settings.Sections["MyConfigSection"].Parameters;

string value = parameters["Key"]?.Value;

// Access custom configuration file:
using (StreamReader reader = new StreamReader(Path.Combine(configPackage.Path, "CustomConfig.json")))
{
    MySettings settings = JsonConvert.DeserializeObject<MySettings>(reader.ReadToEnd());
}

Eventos de atualização de configuração

Serviços Cloud

O RoleEnvironment.Changed evento é utilizado para notificar todas as instâncias de função quando ocorre uma alteração no ambiente, como uma alteração de configuração. Isto é utilizado para consumir atualizações de configuração sem reciclar instâncias de função ou reiniciar um processo de trabalho.


RoleEnvironment.Changed += RoleEnvironmentChanged;

private void RoleEnvironmentChanged(object sender, RoleEnvironmentChangedEventArgs e)
{
   // Get the list of configuration changes
   var settingChanges = e.Changes.OfType<RoleEnvironmentConfigurationSettingChange>();
foreach (var settingChange in settingChanges) 
   {
      Trace.WriteLine("Setting: " + settingChange.ConfigurationSettingName, "Information");
   }
}

Service Fabric

Cada um dos três tipos de pacote num serviço – Código, Configuração e Dados – tem eventos que notificam uma instância de serviço quando um pacote é atualizado, adicionado ou removido. Um serviço pode conter vários pacotes de cada tipo. Por exemplo, um serviço pode ter vários pacotes de configuração, cada um com versões individuais e atualizável.

Estes eventos estão disponíveis para consumir alterações nos pacotes de serviço sem reiniciar a instância de serviço.


this.Context.CodePackageActivationContext.ConfigurationPackageModifiedEvent +=
                    this.CodePackageActivationContext_ConfigurationPackageModifiedEvent;

private void CodePackageActivationContext_ConfigurationPackageModifiedEvent(object sender, PackageModifiedEventArgs<ConfigurationPackage> e)
{
    this.UpdateCustomConfig(e.NewPackage.Path);
    this.UpdateSettings(e.NewPackage.Settings);
}

Tarefas de arranque

As tarefas de arranque são ações executadas antes do início de uma aplicação. Normalmente, uma tarefa de arranque é utilizada para executar scripts de configuração com privilégios elevados. Tanto o Serviços Cloud como o Service Fabric suportam tarefas de arranque. A principal diferença é que, no Serviços Cloud, uma tarefa de arranque está associada a uma VM porque faz parte de uma instância de função, enquanto no Service Fabric uma tarefa de arranque está associada a um serviço, que não está associada a nenhuma VM específica.

Service Fabric Serviços Cloud
Localização da configuração ServiceDefinition.csdef
Privilégios "limitado" ou "elevado"
Sequenciação "simple", "background", "foreground"

Serviços Cloud

No Serviços Cloud é configurado um ponto de entrada de arranque por função em ServiceDefinition.csdef.


<ServiceDefinition>
    <Startup>
        <Task commandLine="Startup.cmd" executionContext="limited" taskType="simple" >
            <Environment>
                <Variable name="MyVersionNumber" value="1.0.0.0" />
            </Environment>
        </Task>
    </Startup>
    ...
</ServiceDefinition>

Service Fabric

No Service Fabric, é configurado um ponto de entrada de arranque por serviço no ServiceManifest.xml:


<ServiceManifest>
  <CodePackage Name="Code" Version="1.0.0">
    <SetupEntryPoint>
      <ExeHost>
        <Program>Startup.bat</Program>
      </ExeHost>
    </SetupEntryPoint>
    ...
</ServiceManifest>

Uma nota sobre o ambiente de desenvolvimento

Tanto o Serviços Cloud como o Service Fabric estão integrados no Visual Studio com modelos de projeto e suporte para depuração, configuração e implementação localmente e no Azure. Tanto o Serviços Cloud como o Service Fabric também fornecem um ambiente de runtime de desenvolvimento local. A diferença é que, embora o runtime de desenvolvimento do Serviço Cloud emula o ambiente do Azure no qual é executado, o Service Fabric não utiliza um emulador. Utiliza o runtime completo do Service Fabric. O ambiente do Service Fabric que executa no seu computador de desenvolvimento local é o mesmo ambiente que é executado na produção.

Passos seguintes

Leia mais sobre o Service Fabric Reliable Services e as diferenças fundamentais entre Serviços Cloud e arquitetura de aplicações do Service Fabric para compreender como tirar partido do conjunto completo de funcionalidades do Service Fabric.